Configuration Management and CMDB: Top-Down or Bottom-Up?

[David Thigpen]

Not considering Discovery for a bit, most organizations seem to take one of two basic approaches to build out their configuration management capabilities: top-down or bottom-up.   Let's talk about each of them.

We didn't define "IT Services" in our first post, so lets do so now.   IT Services are those capabilities provided and supported by IT that enable their users to accomplish business goals.   ITIL goes into considerable depth discussing costs and risks, service hierarchies, IT vs. business services, etc. but we can dispense with that complexity for now.   Service CIs are the upper, logical layer of the CMDB and a top-down approach means first understanding the services IT provides to the business (and sometimes external customers), and then looking at where those services "link" to the physical infrastructure. If, for example,   we define   "Communication via Email" as a service IT provides to the business, then the likely link point between the service and the infrastructure would be the Exchange or Notes application.   As we build out our understanding of the IT services provided, we can start to link things like incidents and changes to those services.  

A bottom-up approach flips this understanding.   We first identify and categorize all the IT infrastructure we can including hardware, software, etc. Then we eventually use that information as the starting point to define the services provided.   That discussion frequently focuses on software applications supported, as once again they are the interface between IT and the business.   So for example, I learn all about the server that SAP runs on, and I then can define the SAP Human Resources "service" that it supports. Similarly, as we build our understanding of the IT infrastructure, we learn how it supports those services.   In our example, that might be databases or web servers that enable Notes or Exchange.

In both cases, it is considered good practice to build a future model of the expected CMDB class structure (services and infrastructure) in order to understand "where we want to be" when the CMDB is mature.   The model will almost certainly change over time.   ServiceNow's CMDB structure is a good starting point, and for some customers requires very little, if any, modification.   Also, either approach is severely limited without a thorough understanding of the relationships between the configuration items, whether services or infrastructure.   A CMDB without relationships is only a list.

Listed are some pros and cons of each approach:

	Pro	Con
Top-down	Builds awareness of how IT supports the business and the value provided Usually brings the business into the discussion sooner Can be done initially at a high level with details over time	Initially not as helpful in troubleshooting incidents & evaluating change risk IT is not used to defining it's work using service terminology   Can be time consuming to reach consensus
Bottom-up	IT usually already has a good handle on the managed infrastructure Especially when enabled by Discovery, can sometimes be done simultaneous with Services definition Can gain lots of information quickly and uncover previously unknown infrastructure	Initially, no understanding of business outcomes impacted by changes and incidents Amount of data may be overwhelming Organizations often stop here and don't take the important next step of defining IT services

There is, however a third option.   We'll discuss that in the next blog post when we revisit "Scope."