Dirty Little Secrets of Application Dependency Mapping
Automating your CMDB discovery process is a little more complicated than buying fancy tools — although that helps too, writes ITSM Watch columnist Michael LeChance of The Travelers Companies.
PRINT
COMMENTNo sooner have CMDB offerings matured to the point of real usability that vendors discovered a way to lock customers into their BSM and systems management strategies and a whole new revenue source with application dependency mapping tools. ITSM practitioners quickly learn that the real value of a CMDB is housing information about relationships amongst CIs (configuration item). The big questions facing practitioners are deciding what relationships are needed and how to manage them; questions that are just as difficult to address even with the latest mapping and discovery tools.
If that wasn’t enough, vendors invariably preach how their solution coupled with their systems management offerings enables “true” BSM and splash up colorful portal based dashboards indicating that slow response in some fictional foreign exchange application is costing your company millions of dollars in lost revenue. Vendors typically close by referencing how your peers are (purportedly) using their products and implying you’ll be a competitive disadvantage if you don’t write them a big fat check.
Such a cynical view is familiar to anyone who’s seen a few hype cycles over the years. Real IT professionals do their homework and are not easily swayed by vendor promises. And, when time is of the essence, IT executives look to early adopters while considering if new technology is a good fit for their organization.
Virtually every leading ITSM vendor now has discovery capabilities. Architecturally these tools are amazingly similar. Basically, take your smartest Wintel, Unix and IP system admins and give them unlimited time and access privileges. Then ask them to sit down at an IP workstation and query every device on the network, learning as much as they can about its configuration and, here’s the good part, what other devices that device is communicating with over an open IP port, then rinse and repeat. Oh, and by the way, ask them to develop a class model to store all this information in a database.
Not All That
Application mapping tools automate these tasks and perform such interrogations very frequently and store all this data very efficiently. But data isn’t always information. What these tools can’t discover are those important things like applications and business processes. You’ll have to create these logical entities and describe to the tool how to discover their components. That’s a particular challenge when there are hundreds of applications in an organization’s applications portfolio as this work requires a great deal of effort, on the part of application architects, developers and infrastructure support personnel. This can easily amount to hundreds of hours of effort per application!
Remember the problem we’re trying to solve is how to populate good CI relationship information into the CMDB. Prior to implementation of discovery tools, early CMDBs typically held thousands of CIs and maybe some relationship info, for example application X runs on these three servers. Now, it’s not at all unusual to find new “universal” CMDBs containing millions of objects, where 70-to-80 percent of those objects are relationships populated via the discovery tool.
The pendulum has now swung to the other end of the spectrum, from not enough relationship information to far more than we could ever hope to manage. The introduction of these tools don’t help with the fundamental questions of determining which CIs, attributes and relationships are important enough to place under the control change management. Such determinations need to be made whether or not without application dependency mapping tools are employed.