What Is a CMDB?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Rarely can an IT operations or management tool discussion occur today without someone inevitably bringing the conversation around to the Configuration Management Database (CMDB). It is a term that is intimately intertwined with the IT Infrastructure Library (ITIL) and any other IT operations concept. In fact, the whole notion of operational excellence is a panacea without a robust CMDB serving as its foundation.
When you think about it, every function performed in IT requires accurate information to drive decisions. Indeed, this relationship between information and decisions spans far beyond IT. With no information, decisions are based on mere guesswork. It is no wonder that these decisions are so frequently erroneous. To make informed decisions, you need to gather the necessary information first. This information is most effective if it is available from a known, trusted source. That trusted source is, in theory, the CMDB, and this is the ultimate goal of the CMDB.
Information is the key to all decisions, and information is constructed from building blocks of raw data. This data is encapsulated in the CMDB. To derive information from the data, one must have an application in mind. These applications of the CMDB are covered in Chapter 9, “Leveraging the CMS,” but first, we must define the CMDB and how it is evolving into something we call the CMS. In Chapter 3, “Planning for the CMS,” we walk you through all the different steps you need to take to transition from the CMDB to the CMS. The definition of the CMDB is not as straightforward as you might think and certainly not what many prevailing definitions would suggest. This chapter discusses the true definition of a CMDB.
The Birth of the CMDB
As long as there have been complex IT systems (since the 1950s and 1960s), there has been a need for some form of CMDB. Early implementations were likely paper and pencil (or even stored in some person’s brain!) because life was so much simpler then. Few called them CMDBs, but this is precisely what they were.
The CMDB term did not come into use until after the 1989 arrival of ITIL. Indeed, the advent of ITIL was necessitated because of the hyperbolic expansion of complexity. IT systems were no longer isolated, simple machines. They had grown to encompass multiple computers across networks and distributed software components. The only way to keep track of the complex nature of these systems was through technology. This technology came in the form of a CMDB, or what most people called an asset database.
More notably, these complex systems had become inextricably bound to business execution. Prior to the 1990s, computers were either isolated, well-defined islands that ran the back office of the business or they were intellectual tools. By the late 1990s, it became clear that the state of IT had a direct impact on the state of the business, and the state of IT was not good. The 1990s saw the rise of distributed computing as the central nervous system of the business, and a mechanism was needed to bring discipline to the operation of this wily beast.
Along came ITIL. Although it grew across Europe in the late 1990s, its worldwide appeal finally exploded on the scene in 2004 when North American adoptions reached critical mass. The chart in Figure 2.1 shows how ITIL hit its inflection point in 2004, followed by the latent impact on membership in the U.S. branch of the IT Service Management Forum (itSMF),1 the international organization dedicated to the development and promotion of ITIL and IT service management.
)
Figure 2.1 ITIL growth
Because CMDB is threaded throughout the ITIL literature, the CMDB phenomenon has grown along with ITIL, albeit more slowly than the general adoption of ITIL. This relationship also consolidated the function around common terminology, so CMDB is now the prevailing term for the trusted data source.
The Configuration Management process in ITIL was inspired by the early work by the U.S. Department of Defense and by the newer Software Configuration Management (SCM) process used in software engineering. Because of this heritage, you will notice many similarities across the two process models. Among these are the concept of a Configuration Item (CI) and a CMDB. In SCM, a type of CMDB is called the Definitive Software Library (DSL). It is not a full CMDB in the context of modern ITIL taxonomy, but it is a good first step toward true CMDB. As you will see in Chapter 4, “The Federated CMS Architecture,” the DSL has been preserved to play a role in a broader federated CMDB, employing multiple CMDBs in what is now called a Configuration Management System (CMS) in the language of ITIL v3.