This chapter is from the book
This chapter is from the book
This chapter is from the book
Frequently Asked Questions
|
Question: |
What are the Citizen CMDB and Core CMDB? You do not mention these here, but many others do. |
|
Answer: |
The Citizen and Core CMDBs are relics of the monolithic model of the CMDB. The premise is that the core CMDB is the “master” CMDB that holds the unified expanse of all data. The Citizen CMDB “feeds” data into the Core. It implies, in most cases, a two-tier hierarchy. We already mentioned that a true CMS will be multiple levels, built upon a chain of Management Data Repositories and liberal use of relationships. You can view the Citizen as the MDR at the lower level of a link in the chain and the Core as the higher level of that same link. As you traverse the chain, Cores become Citizens at the next higher link, and the inverse is true as you move lower. It is admittedly rather confusing, but we explain this more suitable structural chain in Chapter 4. |
|
Question: |
Why did the early asset databases fail to deliver the promise of the CMDB? |
|
Answer: |
There are two major reasons, among others. First, the asset databases did not generally contain relationships rich enough to support the navigation of dependencies between assets and the services they support. Second, the data itself was difficult to populate and therefore inaccurate. As we mentioned in this chapter, inaccurate data is not just useless—it is harmful! |
|
Question: |
The CMDB appears to be very similar to a data warehouse. Can we use a data warehouse as a CMDB? |
|
Answer: |
Technically, the CMDB is similar in many philosophical ways to a data warehouse. Where they differ is in the actual delivery of the technology and how the whole system of data is used within an ITIL-based organization. As a CMS with federation, the parts (the MDRs) are linked differently than a data warehouse, and the tools that produce and consume the data are aligning with the CMS direction. It is certainly conceivable—and indeed expected—that data warehouses will play some role in the CMS, just as traditional relational databases will. The overall system that brings all of these parts together is the CMS. |
|
Question: |
I would love to include my applications in my CMDB, but it is too difficult. How can I do this? |
|
Answer: |
The majority of CMDB efforts are now aimed at infrastructure. Applications are indeed more difficult because of the lack of instrumentation to tell us the real structure of the applications. New discovery tools are now available to help. We explore how these tools work in Chapter 4. |
|
Question: |
How can you advocate extending the CMDB to such high-level concepts as business processes, documents, and the human element when we are still struggling with the basic infrastructure? Isn’t this an overly aggressive “boil the ocean” approach that is bound to fail? |
|
Answer: |
A “big bang” attempt at a CMDB/CMS is almost guaranteed to fail. Like any other ambitious journey, you make progress one step at a time. We do advocate building the higher layers of abstraction, but infrastructure is a necessary foundation that supports these higher layers. Get the lower levels to a reasonable state of maturity before moving “up the stack,” and your journey will be easier. A growing number of organizations are now in a position to make this move, as their infrastructure layer is in a more capable state. |
|
Question: |
I have implemented a CMDB, but my people spend too much time populating and reconciling the data. The overhead is diminishing the value of the CMDB so much that many intended beneficiaries are revolting. How can I minimize this work and save the CMDB effort? |
|
Answer: |
Automation is the key to simplifying ongoing CMDB/CMS maintenance, including initial mapping and ongoing population updates. The category of automation products is discovery tools. We explain discovery in detail in Chapter 4. A CMS without discovery is doomed, so it is wise to implement discovery as soon as you can. |
|
Question: |
You imply that ITIL v3 is the end of the CMDB, but it too references a CMDB. What is the truth here? |
|
Answer: |
On page 68 of the ITIL v3 Service Transition book, the CMS diagram contains an “Integrated CMDB” and Physical CMDBs within the mix of parts. Note that the diagram is just an example of a CMS, not a definitive description. Also note that this section of the book on Service Asset and Configuration Management (SACM) is rather vague on CMDB. This is intentional, as the ITIL v3 authors share our critical view of the CMDB term. They talk extensively about CIs and their interrelationships, which is all good. The ambiguity about CMDB is also good because it marks the beginning of the end of the CMDB, not the instant death of the term. We continue to foretell that the end is coming, but it will take a while. The CMDB portions of the CMS diagram can be more effectively represented in the view taken by the CMDBf Working Group. Both CMDBf and ITIL v3 were developed simultaneously and a bit isolated from one another. This question is related to the next one, so please read on. |
|
Question: |
If the proper, forward-looking term is CMS—and not CMDB—why does the groundbreaking CMDB Federation Working Group even call it a CMDB? |
|
Answer: |
The CMDBf Working Group began its work long before the release of ITIL v3. During this period, CMDB was still the prevalent term and gaining momentum. ITIL v3 outlines the overarching purpose and principles of the CMS, whereas CMDBf clarifies the technology needed to make the CMS work. They both address the same challenge and align very well with each other. Each is an important innovation that together drives us forward from the CMDB of yore and the CMS of the future. One major intent of this book is to bridge the gap between these two brilliant developments. The CMS is an evolution and will continue to be. Neither CMDBf nor ITIL v3 is perfect, nor is this book, but all are forward steps in the ongoing continuum of the CMS. |
|
To eliminate confusion, we encourage a simplification that generalizes the “CMDB” parts of both initiatives according to the hierarchical structure presented by the CMDBf. We call each individual part an MDR, and the whole system is the CMS. We expand on this structure much more in Chapter 4. |
|
|
We prefer to euthanize the CMDB term, but we realize that will take time. A growing number of other influential members of the IT service management community agree, including authors of both CMDBf and ITIL v3. It is indeed uncanny how many people enthusiastically agree when we express our disdain for the CMDB term! |