CMDB "Scope"

[David Thigpen]

Recall our last post regarding "Top Down or Bottom Up" approaches to developing a CMDB. We were in a way discussing the starting boundaries of our scope. Either starting with infrastructure bits and limiting the services piece, or vice versa.   But that still implies that we would include all infrastructure bits.

"Scope", with respect to a CMDB,   generally refers to the portion of the infrastructure currently contained in the database.   It does not have to mirror the existing model of the infrastructure, as that may be broader in anticipation of scope increases over time. (We'll touch on modeling in a future post.)   Scope can be bounded by infrastructure type (Servers), location (Americas; a data center), organization structure (all HR systems), combinations of these, and probably in other ways. So we can set our initial scope for the CMDB to be, for example,   "windows servers in the Americas", Discover or load that information into the CMDB, and begin to use it in support of other ITSM processes. It isn't our final destination, but it gets us started and lets the CMDB start adding value now, while we increase our scope and effectiveness over time, and without having to know everything at the beginning.   Note the expectation is that CMDB scope will be expanding, and so we are following a plan that's been developed to do exactly that.

There is another option however, and like top down, it too takes a services approach: set the initial scope of the CMDB to encompass what the business considers to be the most important services IT provides.   In many organizations that list already exists imbedded in business continuity plans. Pick a critical service, define it well, then drive down into the infrastructure that supports it. That will include hardware, software, networking, printers, etc. as well as mapping the relationships between them. If we go back to our "Communication via Email" service example we used in the previous blog post, then the supporting infrastructure might include Exchange software, the server it resides on, connected databases and their servers, network hardware, support teams, software licenses, and so on.   Now we have a full top-to-bottom understanding of a service the business deems important, and its entire supporting infrastructure.   Begin using this information in the incident, change, and other service management processes with respect to "Communication via Email" and move on to the next item on the important services list.  

This method has a few advantages:   it forces IT to engage with the business to find out what the business deems most critical, it will expose gaps in the CMDB model as the service is documented, and will provide very effective support of the most important IT services sooner than otherwise.

Each of these approaches to scoping contain some compromises though.   Just remember they are temporary limitations we self impose while our CMDB maturity grows to its final level.   But by doing so and following a scope expansion plan, we enable the CMDB to add value sooner, educate IT in its use and management, plan big, and hopefully, prevent it from being loaded with lots of data that will end up being unused