Iterating on IT Service

At CA World last month, I participated in a round table with a group of CA partners - including Accenture, BearingPoint, and Cap Gemini-where we discussed significant problems in IT. We talked about how we, as software vendors and service providers, could help meet these problems by improving our products and services.

The discussion was open and ranged widely.

We talked about many technologies, and CMDB was at the forefront of our discussions. Of course, since I am deeply involved in CMDB product development, CMDB is always on my mind. But I still had to ask myself: Why CMDB now?

CMDBs are hot, but they're not new. In fact, we were implementing CMDBs for European ITIL-savvy clients a decade ago. Outside of ITIL, definitive databases of configuration items and their relationships have been in use for a long time. (See Why CMDBf Matters - IT's not a solution in search of a problem," Iterating on IT Service, April 20, 2007.) Visualization, reconciliation, synchronization, dependency discovery, and federation are all features of commercial CMDBs, but a CMDB still requires an IT department that understands and is committed to configuration management.

ITIL and CMDB

A CMDB is the foundation for many ITIL practices, to the point that a CMDB is almost a symbol of ITIL itself. But the popularity of ITIL does not explain the popularity of CMDBs. It merely raises the question: why has ITIL become so important?

There is no simple answer. Compliance is a factor. A decade ago, IT was relatively free of compliance issues, but the list of IT regulations today has become long and continues to grow: SOX, HIPAA, Graham-Leach-Bliley, Basel II and so on. SOX compliance, for example, is not a one-time investment. Controls must be reviewed and revised when the infrastructure changes, increasing costs throughout project lifecycles. Ad hoc processes increase the difficulty and expense.

Consequently, IT departments have been forced to systematize their processes by turning toward practice frameworks like ITIL. CMDBs are one of the components that can improve a wide range of ITIL processes-including change, incident, problem, availability and capacity management.

Risk is a factor.

In addition to regulatory pressures, risk has driven corporate boards and executive management to become more aware of the role of IT in the enterprise. When something like a Blackberry crash disrupts business, non-IT executives begin to think of technology risk assessment and abatement. CIOs and IT managers ask how their practices could minimize consequences. At these times, ITIL practice is seized upon as an antidote to IT risks.

But I suspect that sustained interest in best practices does not come from IT crashes.

ITIL and CMDB help blunt the effects of technology failures, but they are really aimed at the biggest technology failure of all: technology that fails to serve the business that funds it. ITIL will not suddenly align business goals and IT services, nor will an isolated ITIL CMDB implementation reverse decade-long configuration management habits.

Thankfully, IT is becoming more introspective and instead of trying to solve problems with more technology, the goal has become to apply technology more carefully.

Both IT departments and IT professionals are stepping up the maturity ladder. CMDBs have been around for a long time, but real news is that IT has matured to the point that it is ready for them. The buzz around CMDB is a symptom, not a cause, of this professional growth.