Home    ITIL  Index

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.
Dec 26, 2007
By

Michael LaChance





Anyone examining ITSM automation solutions better prepare for an onslaught of vendor sales pitches for BSM (business system management), federated CMDBs (configuration management database) and discovery tools—even if all you need is to upgrade your older, “pre-ITIL” service desk and change management systems.

No 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.

Slick road shows demonstrate how state-of-the-art application mapping tools easily discover configuration items and relationships and automatically populate the CMDB. Only after significant due diligence do you realize how much such capabilities cost, how much staff it takes to implement and support it, how long it takes to deploy and, for some customers, how little value is achieved.

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.


    1 2 >> Last Page


Comments  (click to add your comment)

Comments

    Name or nickname

    Email address

    Website

    Write comment
    You have characters left. (Maximum characters: 1200).

     


    IT Management Daily Newsletter




    Related Articles

    Most Popular