The complex software applications that run modern businesses are often referred to as "mission-critical" and must be kept running 24x7. Unfortunately, the complexity of these applications is often so great that keeping them in a healthy state can be challenging, to say the least.

The Configuration Management Database, or CMDB, was conceived a few years back as a way to discover and maintain a repository of all components on which an application is dependent, along with information about their relationships. Apart from its use in asset management, the thought was that combining the CMDB with real-time monitoring metrics obtained from the underlying components could provide insight into the health state of complex applications, with early warning of incipient problems, and guidance to root cause when incidents do occur.

This is a powerful vision with potentially far-reaching benefits. It is a bit like the internal monitoring system in a modern automobile which relies on a complete and well-defined database of all the components on which the vehicle's operation is dependent and how a failure of any one component might affect the mission-critical operation of the vehicle. A soft female voice might warn you, for example, that your tire pressure is low — and she didn't have to "learn" that low tire pressure can cause a blowout by having one first.

Similarly, today's large, complex, mission-critical business applications can have a huge number of moving parts and underlying software components — with lots of things that can go wrong.

Is it possible to identify and maintain a database of all the internal dependencies of a complex application and create a warning system like that in a modern automobile that is highly deterministic and reliable and can prevent incidents from ever happening in the first place?

Sounds like a really great idea. Why then, has the CMDB seen only limited adoption and little commercial success?

Weaknesses of Conventional Configuration Management Tools

We have seen many products in recent years designed to create and maintain such a Configuration Management Database. However, practical challenges have prevented this vision from becoming reality, and the CMDB seems to have lost favor as a realistic contributor to a monitoring solution.

While successful to some extent, the general consensus seems to be that these products have been simply too limited in functionality or too difficult to use for maintaining reliable content. For some detailed criticism, see "IT Skeptic" Rob England's blog: CMDB: What Does It Really Mean?.

Monitoring a complex multi-tiered application involves the collection of data from many different sources, including infrastructure data (host cpu and memory), middleware service data (message flows, session counts), and application data like log file content or data exposed through JMX. Typically, this can include a dozen or more specific types of data for any platform you build.

Using a traditional CMDB or service model a user would either:

1. manually define the dependency relationships between these components and each application that uses them, or

2. use a tool to auto-discover the relationships using some form of heuristic algorithm.

Both of these methods have serious drawbacks. It is impractical to manually maintain a service model when components are continually being added or the system is modified. The heuristic method seems promising but the drawbacks are just as severe although more subtle; minor flaws and inaccuracies constantly plague the system and can cause mysterious errors that go undetected for a long time.

Automobile manufacturers gradually figured out how to manage the information needed to effectively maintain the health and safety of a moving vehicle. In a similar way, developers of complex applications are slowly discovering ways to make monitoring these systems more automatic and reliable. Fundamental changes in the IT landscape are helping as well.

The CMDB of the Future - Part 2

ABOUT Tom Lubinski

Tom Lubinski is President and CEO, and Board Chairman, of SL Corporation, which he founded in 1983.