This ComputerWorld article written by Michele Hudnall (Former META Group analyst now Director of Service Management at Managed Objects) just didn’t sit right with me. It didn’t sit right with the ITIL Skeptic either as discussed here.
What didn’t feel right was the stretching and mashing up of at least three separate concepts from what I can see: the CMDB, the Service Catalog, and Business Service Management. There’s nothing wrong with creating a new and innovative solution, but one should really understand what’s behind the sales and marketing and make sure that it fits for your environment first.
Managed Object’s has positioned themselves as a BSM play for some time now and with success. In order to have a successful BSM solution, one needs to be able to collect information from many disparate sources across the enterprise. From what I have personally heard, they’ve done a good job at this, especially with some of their network and systems management solution integrations. They must have a capable architectural framework that allows them to perform ETL like activities on these data sources and run the data through their processing, analytic and visualization components. Expanding on this capability to include storing of this data and information, creating relationships and containment models, etc. wouldn’t be that difficult. I have a feeling that this is what makes up the upcoming CMDB360* solution. Micromuse certainly did the same thing with our concept for a “virtual CMDB” prior to our acquisition by IBM.
This is where things get off on the wrong track for me personally when I think of what is generally accepted as a CMDB. What will this “just-enough” CMDB allow one to do? What’s “just-enough” change or configuration management? Will “just-enough” change and configuration management improve IT? What happens when “just-enough” isn’t enough? Who or what group determines what “just-enough” is?
“A just-enough approach delivers near-term value by focusing the CMDB definitions only on services critical to the business, such as e-commerce systems, product distribution or customer service. And by proving the business value of the CMDB by concentrating on critical services, you will in fact enable a wider implementation ultimately.
A just-enough CMDB should provide a full picture of the following:
1. All technology components related to the specific service.
2. The relationships and interdependencies among those components, including relationships between logical and physical components.
3. Context from a service perspective — role-based views of the technology that consider the requirements of the audience.
4. State, in terms of availability, business performance and technology performance.
5. Governance — automated management of what is currently running versus what should be running and was last approved.
6. Management of service through defined, monitored and automatically managed service levels.
It is important to note that a just-enough CMDB must include definitions of services and information on state and automated governance/management, all frequently updated. Without such information, you can’t have accurate and effective root-cause and impact analysis of IT issues before changes are made to the production IT infrastructure.”
“Two things need to be in place before getting started on your CMDB project. The first is an understanding of key performance indicators (KPI) for the critical business services selected. These are clearly defined, measurable determinants of success. For example, for a business service such as online ordering, a good KPI might be “average length of time to place the order” or “number/value of orders per hour.” In the end, the purpose of a good KPI is to define success by a volume measure for a particular type of business transaction.”
I guess the closest things here that resemble a generally accepted CMDB is the service topology and governance bits. This speaks of configuration and change management. Item 3 is more of a presentation layer concept and can be very vendor specific in terms of reporting, GUIs and role based access.
This rest really speaks of a Service Catalog or Business Service Management (BSM) solution to me more so than a CMDB. I see this type of information stored in what I’ve called a Service Management Database (SMDB) or Operational Support System for Service Management (OSSSM) in the past. The idea here is that you’ve collected “just-enough” information from all of your key data sources, management and monitoring solutions, etc. to fully understand the services from an end-to-end management and monitoring perspective. You know what the impact on your business and customers is, what the KPI/KPM’s are (metrics catalog or data dictionary), you know how each critical component is managed and monitored (management/monitoring OLAs), you know what events are generated (events catalog or data dictionary), etc. Sure, all of this can be stored in a CMDB, but I’m not sure it should be.
“It is important to maintain a broad and shallow approach to building the just-enough CMDB — avoid the urge to get into the weeds and attempt to inventory and catalog everything. You should keep in mind your goal — to create this from a top-down service approach, focusing on what matters to the business most, not on technology minutiae.”
This point may be useful for something that underpins a BSM solution, but I’m not sure how far this will go towards underpinning the key IT process areas in an IT organization such as change, release, and configuration management. The guys and gals in the trenches will need some level of minutiae that the business will never care about. I have always remembered one key point about the CMDB from my ITIL training – only put in the CMDB what you intent to apply change control policies to. Again, who or what group determines what “just-enough” is? That will certainly lead towards some lively discussions!
I look forward to learning more about the Managed Objects CMDB360* solution as it is developed and released. I was sent an email from their PR firm after posting this a few weeks back, so I expect they’re following the blogosphere and may jump into these conversations. I encourage them to do so!