Application Dependency Mapping Tools

Medium to large businesses are rapidly discovering the value of Application Dependency Mapping (ADM) tools and services. As corporate sites and eCommerce companies have grown, merged, and added to their infrastructures, their topologies and applications have turned into bloated spaghetti factories that become increasingly more difficult to troubleshoot and enhance.

Enter ADM. Many companies have been producing application dependency mapping solutions and tools for a few years now, and while these tools initially produced ambiguous results, many have now matured into solid and accurate discovery moles that will produce valuable time savings for IT architects and systems administrators.

One of the most difficult and important tasks in any enterprise is establishing and updating logical and physical network documentation and diagrams. Despite the best efforts in any documentation group, large scale networks will almost always have overlooked components. When applications fail and recovery is too slow, it is often due to these unknown components.

With a proven ADM tool, those hidden components can be discovered and documented, and all the dependencies for a given application can be mapped. That allows IT architects and administrators to identify missed opportunities for monitoring and enhancements.

I have heard stories and even had personal experience with network applications that failed or had mysterious issues that took days to resolve because of undocumented or forgotten dependencies. Very early in my career, I remember an IT manager touring a data center and seeing a PC in the server cabinet labeled "OS2 Warp Bridge". The manager was aware that all the OS2 Warp machines in the infrastructure had been decommissioned several weeks earlier, so he shut it off.

Unknown to me or that manager, what followed was three days of troubleshooting at a data center 800 miles away to determine why certain mainframe applications were no longer working for the end users. By chance on the third day of this outage a senior systems admin was in our data center and noticed the "OS2 Warp Bridge" machine was powered off. "How long has this thing been down?" he asked me (I was a server operator at the time). I told him it had been shut down by his manager three days earlier. He spouted a colorful adjective and punched the power button on the machine, then rushed off to call the other data center to tell them the problem was resolved. It turned out that the "OS2 Warp Bridge" machine had actually been re-purposed as an SNA gateway.

The manager who failed to follow change control procedure was reprimanded, but while he was the one who shut the server down and started the incident, the root cause of the entire problem was not entirely his fault. Had the server been properly relabeled and documented when it was redeployed with its new mission, there would never have been a mistake and he would not have turned it off.

Of course, back then there were no automated discovery tools, and everyone had to rely on proper manual documentation when components were added, removed, or changed. With today's massive enterprise networks, manual documentation is a near impossibility. In today's world, with the proper ADM tools employed, this sort of incident could be avoided.

Application Dependency Mapping tools are expensive, but in a large enterprise they are still worth the cost when you consider the army of documentation specialists you would have to employ to manually track and diagram your critical application environments.