This chapter is from the book
This chapter is from the book
This chapter is from the book
The CMS Arrives
In June 2007, the UK Office of Government Commerce (OGC)—the official ITIL caretakers—released ITIL version 3 (ITIL v3). In this book, we do not expand on the many improvements in ITIL v3, but the most significant change to configuration data is the emergence of the CMS.
A CMS is a vast improvement over a simple CMDB for many reasons. A few of the more prominent benefits of CMS are the following:
- CMS implies distributed data in line with, but beyond, the historical notion of a CMDB. The CMS is inherently federated, whereas the CMDB required a dramatic new twist. As you will see, the new concept of a federated CMDB is really a CMS.
- ITIL v3 more clearly articulates practical applications for configuration data and endorses references to and from the broader CMS, rather than direct integration to a CMDB. The distinction between federation and integration is important, and we describe this difference in detail in Chapter 4.
- The genesis of the CMS marks the beginning of the end of the CMDB term. CMDB is a misleading term, but its ubiquity will make it persistent for years. Still, it is much more fruitful to shift many of the CMDB discussions to CMS instead. Even in the CMS description in the ITIL v3 literature, the CMDB term remains, but it is redefined into what is essentially an MDR. We believe that the CMDB Federation Working Group’s concept of the MDR will prevail in the long run and that “CMDB” eventually will fade away from the vernacular.
- CMS is richer in its inclusion of applications and services. Prior notions of the CMDB were vague and fragmented beyond simple infrastructure characteristics. Because the CMS is inherently object-oriented, it can make use of behavioral information to make the structural information more accurate and more useful.
- Relationships are at the heart of the CMS. CMDB was often viewed as just a repository of attributes. Linking and federating these attributes were usually limited by technology solutions that were in fact designed according to these misguided, restrictive attribute-centric requirements. CMS is a force to break this cycle by mandating the relationships necessary to make raw data meaningful.
Throughout the remainder of this book, we use the MDR, CMDB, and CMS terms. As much as we dislike the CMDB term, it remains relevant for now. A CMDB in the newer order represents a specialized repository, usually targeted at a specific technology domain. We prefer to call this an MDR, and we will usually do that. Note that the two are nearly interchangeable in the new order of the CMS. It is also important to sometimes refer to CMDB in its historical context. To properly convey the meaning and value of the CMS, we must address, and in many cases overturn, common CMDB perceptions.