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. 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.
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.
Here are few areas requiring close attentions during your assessment of these tools.

Application Boundaries

Application mapping tools create a visualization of the infrastructure components associated with an application. They can also display software components and dependencies on other application or even software components. However they provide little or no visibility into relationships between value networks, business processes, content, and other applications.

Defining the boundaries of applications are often gray areas that need to be hammered out with application owners and architects. One particular troubling aspect of discovered topologies is that they represent the configuration at a particular point in time. Discovery schedules need to be carefully thought out because if a TCP port isn’t open at time of discovery then the map won’t depict the partnering CI.

Class Model

Application dependency mapping tools interrogate the infrastructure and these results are stored in a database whose object-oriented class structure is loosely based on an emerging industry models, such as DMTF, CIM and others. Because there isn’t an industry standard, federating CIs, attributes and relationships across multi-vendor environments is exceedingly difficult especially as vendors are apt to interpret these emerging standards differently while applying their own extensions.

Carefully investigate the integration requirement if your application mapping tool is from vendor X but your ITSM automation solution uses CMDB technology from vendor Y. Otherwise, you may be looking at a rather large professional service integration effort.

Security

Because application mapping tools need to first learn about the infrastructure, they must be taught some basics about the environment like IP address ranges, subnets and SNMP communities before they can start trolling for CI, attributes and relationships. These tools are efficient so network bandwidth consumption is rarely an issue, however intrusion detection systems need to be forewarned about this activity. And firewalls ports may need to be opened.

Discovery technologies leverage IP protocols such as ICMP, SSH, JDBC, and others to probe the network. Operating systems credentials across the server population are needed to probe further. Once that level of security is in place, you’ll then need to provide even deeper access for all your Oracle and SQL databases, Websphere and BEA environments, etc. so discovery tools can interrogate the real details of your application’s configuration. Simply providing authentication and access rights across the infrastructure for the discovery tool can take months in a large organization with thousands of servers.

Start Small

So, should these and other implementation challenges put you off investigating application dependency mapping tools? Absolutely not. The accuracy provided by these discovery tools is incredible and beyond the reach of manual methods but should only be acquired by organization with a fairly high level of maturity with change and configuration management.

Look for a sweet spot for application dependency mapping and BSM technologies. Start small and focus on a limited set of key application and business process. Engage your customers early as they’re best placed to tell you what those key applications are or perhaps check with your organization business resiliency office (if one exists) as they’re typically pretty good at assessing and assigning risk.

These tools are not inexpensive so prospective buyers should examine these offerings very carefully in light of their own maturity and scrutinize the cost benefits of such technology in the context of their own infrastructure and application environments. Above all, develop a solid business case and prove its value before attempting an enterprise deployment.