Myths of the CMDB

IT Editorial

Wednesday, 06 February 2008 14:28

Written by Michele Hudnall

Ironically, the confusion over what a CMDB is hasn’t stopped the growth.  For example, Forrester Research predicted that the change and configuration management market, which includes CMDBs, would grow 28 percent from $2.099 billion in 2006 to $2.687 billion in 2007.   Another research firm, IDC, wrote in early 2007 that CMDB deployments would accelerate over the next three years as more companies extend their current work on process standardization via ITIL and other capability maturity models.  

While the CMDB has grown in global notoriety, there is anecdotal evidence to indicate that CMDB adoption rates in Europe are outpacing those in North America.  This may seem to defy conventional wisdom at first, but when one considers the fact ITIL originated in Europe, it is quite logical.  The rest of the world still struggles with sprawling technology infrastructure but with an increasing global drive towards IT and business alignment, it’s catching up in a hurry.

Regardless of where the growth is occurring, it’s the pace of the growth itself that is impressive and explains why both vendors and IT organizations alike are increasingly paying more attention.  Yet this begs the question – what is the business pain that’s driving this growth?

Painful change

The answer to that question can be summarized in one word:  change.  The complexity of today’s IT infrastructure places enterprises at great risk of prolonged and frequent IT outages as a result of change.  For example, market research has found that upwards of 80 percent of IT outages are caused by human error that stems from both planned and unplanned IT changes, as well as shortfalls in testing and process inadequacies. 

Yet simply avoiding change is not possible.  Things break.  Software needs patches.  Servers will always need memory upgrades.   IDC Research wrote that a typical Global 2000 IT organization averages 500 to 600 manual configuration changes a month to its IT infrastructure.   Other analysts have publicized similar findings; for example, Forrester Research wrote that on average, large organizations make approximately 500 changes per month to their IT infrastructures.   

Change is also necessary, in fact, pivotal, if IT is to have the agility to respond to ever-shifting business needs.  Agility in IT means responding to business needs when a company builds, buys, divests or merges lines of business.  It is defined by the ability to quickly deploy and manage new services for example, a Web application that the business launches in order to pursue an emerging market opportunity and stay ahead of the competition.  IT’s role as a strategic business partner stems from its ability to make changes quickly – and less risk.

If change is mandatory, then IT organizations need a means to control change and manage the impact of change when it does occur.  This is the value proposition of a CMDB.

CMDB’s purpose

A CMDB visually models information about IT infrastructure components in order to understand the interdependencies among these components in the context of IT service.   If IT understands the relationships among its IT components – if it has the ability to map components to applications to the business – then IT can control change and manage impact.  A contractor wouldn’t knock down walls of a kitchen during remodeling project without blueprints to understand how that action might affect the structural integrity of the home.  Likewise, IT needs to understand the impact of change prior to implementing changes in their house – the production environment.

For example, IT needs to understand impact the installation of a new O/S software patch to a single box in a server farm will have on a business service – such as online trading – and can take proactive steps to mitigate the risk of an outage.  Similarly, should outages arise from unplanned changes or for any other reason, such as fault failures, the relationships the CMDB maps allows IT operations to quickly find the root cause of IT outages or degradations – often before performance, availability or end-user satisfaction are adversely affected.

So why all the confusion?

CMDB is shorthand for configuration management database – which is where people get tripped up right away. The fact it is called a database is something of a misnomer, which the IT Infrastructure Library’s (ITIL) third version aims to clarify by classifying the concept as a configuration management system or CMS.  Compounding the issue, analysts, vendors and even customers have all weighed in with modified definitions. ITIL defines a CMDB as a database used to store configuration items (CI) – the physical or logical items that comprise an IT infrastructure – throughout their lifecycle.

Semantics aside, notice the example in paragraphs above provide a purpose for a CMDB, rather than a definition. A CMDB project shouldn’t be about collecting and consolidating massive amounts of data for data’s sake – it should be about what IT is able to do with the data, which ought to be to improve service quality for the business.  This is the first and perhaps the biggest stumbling block to a successful CMDB project:  an over-focus on definition. The project needs a vision and purpose, not a definition. 

The debate over CMDB definitions is complicated by the fact that IT’s functional disciplines are divided by each organizational role’s own unique view of the world.    Financial types see a CMDB project through the lens of asset management systems; change managers might have an affinity for discovery; and help desk staff see the service desk, a customer facing tool, as the most logical basis for a CMDB.  In truth, they are all partly right – quite literally.  Each functional discipline has a federated piece of the truth that needs to be synchronized and reconciled to become a trusted single source.

Much like the tools they use, these siloed views have married semantics and give rise to a host of myths about CMDBs.
 

Myths of the CMDB

Myth #1:  If we build it, they will come
A CMDB is not just an IT project.  The purpose of the CMDB should not be solely focused inwardly on the efficiency of the IT organization.  A CMDB should focus on a service that is consumed by the business or external users and it should provide benefits to a service that directly impacts the business.

Myth #2:  Process before technology
Process is important – it’s so important that it’s nearly a religion some parts.  Yet on the same note, the effort and energy spent perfecting a process before automation can be overkill.  Even ITIL is talking tools now.  To some degree, every IT organization has at least some sort of process by virtue of commodity tools such as service desks and discovery tools.   Since it exists, there’s a tangible benefit to be gained by integrating data from these tools into a service oriented CMDB.

Myth #3:  Asset management is my CMDB
This myth comes in a variety of flavors such as ‘service desk is my CMDB’ or ‘discovery is my CMDB.’  But these tools each only hold one piece of the puzzle.  Asset management contains physical data about components in your infrastructure – but provides nothing in terms of relationships and dependencies.  The mechanism to uncover relationships and dependency mapping is discovery – also commonly referred to as application dependency mapping. Yet both of these tools still do not furnish data associated with problem and change, which are most often kept in the service desk.  Each of these tools contain repositories of information each sometimes referred to individually as a ‘CMDB.’ But in reality, truly actionable information is derived only when data from these tools are tied together.  This is why ITIL’s effort to rename the concept CMS is perhaps a better choice.

Myth #4:  CMDBs must be centralized
A CMDB does not have to be centralized; it should have a centralized service view.   Some CMDB products require IT to extract, transform and load (ETL) data from their existing tools (asset management, discovery, and service desk) into a centralized database but the challenge here is multi-faceted:  1) it’s expensive, 2) the minute you extract the data its accuracy becomes dated, and 3) the amount of data being jammed into a centralized repository quickly becomes unmanageable.  A better solution is federated model with application-interface (API) level integration that “points” to the original source in real time or near-real time. 

Myth #5:  Every attribute should also be a CI
Some CMDB project managers argue that every IT component should be included in the CMDB as a configuration item (CI).  Here too the CMDB can quickly become unmanageable – and can end up including data of little business value.  A quick litmus test for including a proposed CI is to ask two questions:  1) do I manage this CI through change? and 2) should I manage and measure it?  For example, a memory card in a workstation may not be worth monitoring and may not be included as a CI, but a patch release for a server that hosts all or part of a SAP application is certainly a more logical consideration.  

Myth #6:  A CMDB is a colossal undertaking
Some CMDB projects are too broad and too deep when it should be just enough to manage the service.  IT can take a “just enough” approach.   Here’s how:  1) identify the purpose of the CMDB, 2) choose an application or service, 3) model the service, 4) integrate federated data, 5) define rules and analyses, 6) create analytics and reporting, 7) define role-based views and, 8) repeat as desired.  When a CMDB project is created in a top-down manner with a just-enough orientation in mind, design and implementation can be easier – especially when approached with a service-oriented perspective.

Conclusion

Interest and public discourse on CMDBs have grown exponentially in the last 12-18 months because CMDBs can solve two very real business pains:  controlling change and managing impact.  The line between business and IT has blurred to the extent that in many ways, technology has become the business.  To this end, CMDB projects are no longer optional, but rather a business imperative.  While interest has grown, so too has confusion, which tends to arise from esoteric definitions that center on theory, when IT really needs a pragmatic approach;  the best advice might be to avoid letting perfection get in the way of a good start.

------------

About the Author: Michele Hudnall is a former-META Group analyst and is currently the director of service management for BSM vendor Managed Objects, which is one of five vendors in the industry that meet Gartner’s functional requirements to be classified as a CMDB.  She also sits on the board for the US-chapter of the IT Service Management Forum – itSMF.

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed