1) The document discusses the differences between a CMDB and a CMS, noting that a CMDB is a misnomer and organizations should migrate to a configuration management system (CMS) as described in ITILv3. 2) A CMS contains multiple "CMDBs" or management data repositories (MDRs) that are linked through federation to provide an accurate view of IT services, infrastructure, and configurations. 3) Achieving an accurate unified CMDB is difficult, but a federated CMS that leverages discovery tools and change management can provide pockets of accurate data across different MDRs to support IT decisions better than ambiguous unified data.

1. Glenn O’Donnell Senior Analyst Forrester Research February 19, 2009 Cracking The CMDB Enigma Hint: There is no “CMDB”

2. CMDB

3. CMS

4. Questions to be Answered What is the difference between CMDB and CMS? What’s feasible; what’s not? What is federation? What good is the CMDB? How will the CMS evolve?

5. What IS this thing we call a CMDB? The source of information for IT decisions “CMDB” is a misnomer A critical element of operational discipline Popularized by ITIL Migrate to the ITILv3 configuration management system (CMS) Change Configuration Release Incident Problem Availability Service Level Capacity Financial Continuity Use Service Delivery Service Support Discovery Changes Use Use Use Use Use Use Use CMDB CMDB

6. The Configuration Management System The CMS contains MANY “CMDBs” Management Data Repositories (MDRs) Linked by federation Accuracy is ensured by discovery & change mgmt Heavy use of metadata Captures all data about IT services and infrastructure HR DB Servers Network Service Catalog Storage Virtual Servers CMS Known Errors Incidents Apps Data Whse

7. CMDB: What’s possible and what’s not? Federation is coming Infrastructure discovery Application discovery Attack small bites Multi-vendor CMDB CMS (but it’ll take time) Federation is coming Accuracy in “old world” Accuracy in “new world” Single-Vendor CMDB “ One” CMDB “ Big Bang” CMDB Possible Difficult / Impossible Isolated pockets of the truth are better than unified ambiguity!

8. A simple federated CMDB example local data Service Catalog service A service B service C Service MDR customer service owner application A Customer MDR organization ID contact person IT_customer_rep HR DB employee ID name organization ID Application MDR client network server Server MDR manufacturer model storage Client MDR manufacturer model user Network MDR manufacturer model num_ports Storage MDR manufacturer model capacity 100% metadata mix of metadata and local data

9. The CMDB “Butterfly Effect” All decisions are based on configuration information! Good information = good decisions Bad information = bad decisions Decisions compound Delays will prove devastating Punitive Outsourcing Operational Excellence Process Refinement Status Quo CMS “ Nudge” Disadvantage Delayed Start Collapse The very future of the organization rides on trustworthy information!

10. Discovery Yields the Truth CMDB population is a big problem Solution: discovery and change mgmt Complexity is beyond comprehension … and getting MUCH worse Verify documented systems; trust no current data Automated technologies discover the truth e.g., network, server, storage, apps, … Beware of blind faith, but tools discover complex environments (the truth) better than humans can Difference

11. CMDB process maturity 1 2 3 4 5 Knowledge of IT is almost entirely in human minds Verifying configuration is heavily manual Simple CMDB is assembled, but data is stale Limited discovery is in use Heavy use of discovery, but data unification is weak Most discovery data is unified into a federated model Early process integration is happening Most discovery data is unified into a federated model Broad process integration is accelerating execution

12. CMDB becomes the CMS Federation will grow through 2011 Process integration becomes the focus by late 2009 CMS technologies become infused in mgmt tools Vendors will focus on CMS use, not the CMS itself Service design, visualization and reporting will emerge as important tools/functions based on CMS CMS elements will be decoupled from other tools Modular MDR integration will be the feed Active adaptation will derive intelligence from the CMS and will update CMS immediately (mandatory!)

13. Prepare for the new CMDB (the CMS) Beware CMDB misinformation The “new CMDB” follows a federated model Understand how tools will evolve and which foundation tools are available today Much of the CMDB will change Determine HOW the CMDB will be used Ensure a thriving future with trustworthy information Information is not just data, it is useful data with intelligence! 1 0 1 1 1 1 1 1 1 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 0 0 0 0 1 0 1 0 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 0 1 1 1 0 0 1 1 1 0 0 1 1 1 0 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 0 0 0 0 1 1 1 0 0 0 0 1 1 0 1 0 1 0 1 0

14. How to do CMDB right! Start now Appoint and empower a strong CMDB leader Leverage discovery and incumbent tools Expect to do some integration yourself Unify service-level definitions with metadata models Migrate thinking to align more with ITILv3 Avoid the monolith! There can be no single CMDB!

15. Thank you Glenn O’Donnell +1 617.613.8826 [email_address] www.forrester.com