CMDB Systems

Making Change Work in the Age of Cloud and Agile

Dennis Drogseth, Rick Sturm, Dan Twing

• Publisher: Morgan Kaufmann
• Year: 2015
• ISBN:
  9780128013731
• Topic: Computer Science
• Subtopic: Databases
• Index: Computer Science

CMDB Systems: Making Change Work in the Age of Cloud and Agile shows you how an integrated database across all areas of an organization's information system can help make organizations more efficient reduce challenges during change management and reduce total cost of ownership (TCO). In addition, this valuable reference provides guidelines that will enable you to avoid the pitfalls that cause CMDB projects to fail and actually shorten the time required to achieve an implementation of a CMDB. Drawing upon extensive experience and using illustrative real world examples, Rick Sturm, Dennis Drogseth and Dan Twing discuss:

• Unique insights from extensive industry exposure, research and consulting on the evolution of CMDB/CMS technology and ongoing dialog with the vendor community in terms of current and future CMDB/CMS design and plans
• Proven and structured best practices for CMDB deployments
• Clear and documented insights into the impacts of cloud computing and other advances on CMDB/CMS futures

• Discover unique insights from industry experts who consult on the evolution of CMDB/CMS technology and will show you the steps needed to successfully plan, design and implement CMDB
• Covers related use-cases from retail, manufacturing and financial verticals from real-world CMDB deployments
• Provides structured best practices for CMDB deployments
• Discusses how CMDB adoption can lower total cost of ownership, increase efficiency and optimize the IT enterprise

Section 1

Failure is Not an Option

Chapter 1

The Odds Are Against You

Abstract

Failures in Configuration Management Database (CMDB) initiatives have been both rampant and notorious, and yet, the values of new and emerging CMDB-related technologies are greater than ever. This chapter provides a sobering set of insights into how and why CMDB initiatives fail, but it also takes a fresh look at how the classic CMDB is evolving into a far more successful paradigm—the “CMDB System.”

Keywords

CMDB failures

CMS

CMDB system

issues

ITIL

organization

communication

stakeholder

John was looking to leave his legacy for George Washington Surgical Manufacturing (GWSM)—a mid-range company headquartered in the Midwest struggling to keep pace with dramatic changes in the healthcare industry. The IT organization and the manufacturing organization were closely intertwined with sometimes disastrous results, as changes made to a suite of in-house-developed applications turned out to cause disruptions on the manufacturing line. Even worse, ineffective change management was seriously degrading the performance of the wholesale access application supporting partners and suppliers—the very heart of GWSM’s business!

In his role of Change Process Manager, John wanted to deploy a CMDB—unifying change management across IT with insights into where and how application and infrastructure modifications impacted service performance. However, he knew the odds were against him. Creating a ‘single source of truth’ in managing change, planning capacity and enabling more effective triage would challenge siloed ways of working and require solid executive support from the top down.

Hoping to beat the odds, John had done his homework. He’d learned from reading about past mistakes. He’d spent time identifying critical stakeholders, engaged them in dialog, and collectively evolved a plan for going forward. He understood the importance of readiness and enthusiasm in mapping this initiative to areas of value and collectively charted Phase One metrics for evaluating his CMDB’s success. This required breaking some barriers between operations, the service desk, and development.

So far John’s success in getting everyone to pull together was mixed. But at least he’d built up some momentum. He felt that if he could move the project forward, he might reach a tipping point when enthusiasm might finally outshine skepticism.

In the process of doing and documenting these stakeholder dialogs, John eventually got the support of his immediate management team. This required about three months of meetings in which he was able to articulate not only his plan, but existing gaps in terms of technology and process in GWSM’s current environment. The management team especially wanted to better understand the chasm between development and operations in making effective handoffs—as development was so often rushed to make changes that operations never fully understood; while in parallel development made assumptions about available infrastructure capabilities that were more often wrong than right.

The support of his immediate management team helped John to escalate his plan all the way to the CIO—a formal gentleman who was change resistant and risk averse and was all too evidently fighting for his job. After another month of meetings, the CIO also bought in—once he realized that a CMDB System might become a way to remedy the currently poor reputation of IT, and so to salvage his own imperiled legacy.

John had gone through a lot of meetings and a lot of dialogs, but he finally thought he had enough momentum to go forward. Like a seasoned skier at the top of a familiar hill, John was ready to take the glide down: to implement Phase One of his CMDB initiative. It had taken him four months of planning, discussion, persuasion and revisions, but now he was now ready. All that seemed to be missing was deploying the software that his chosen vendor had promised. The vendor’s CMDB was supposed to work with many of GWSM’s other investments for managing change on a more siloed level. Best of all, the vendor’s salespeople had spent countless hours with him, promising to listen to his requirements and even shape their product around his needs.

About five months into the process, John had a proof of concept done—albeit with a beta version that seemed to require more attention than ideal from vendor consultants to meet his requirements. But all the features were promised as a part of 2.0 release. John was reassured.

This was going to be the easy part.

Yet, the very next morning after the CIO signed off on John’s deployment plan, he got a memo from the vendor apologizing for delays. Six months later, John and his team were still without a solution. With this delay, the delicate underpinnings of executive and stakeholder commitment began to fade, while development’s “I-told-you-so” attitude was beginning to eat away at John’s self-confidence.

Eight months later, the CIO left, and the new CIO remained indifferent at best. A year later, everyone knew the truth: The vendor-promised CMDB would never ship—and John would have to scramble to find a new role at GWSM.

(Although admittedly fictional, this story is based upon actual client experiences. For insight into the others, read on.)

CMDB Opinions

With war stories like the one above circulating the industry in high volumes, skepticism and confusion abound. And with so many different opinions about what Configuration Management Databases (CMDB) and Configuration Management Systems (CMS) are, have been, can be, and should be, it is no surprise that the topic has become controversial, generating often wildly contradictory views. Needless to say, this confusion is also a setup for failure—especially when it occurs, as it so often does, within a single CMDB initiative, as the voices of vendors, consultants, executives, CMDB administrators, and other stakeholders merge in a cacophony of impossible expectations and siloed priorities.

That leads, of course, to the obvious questions: What is a CMDB? What is a CMS? Moreover, what is this strange hybrid, CMDB/CMS, that we'll refer to throughout this book as a “CMDB System”?

One very high-level definition of “CMDB System” might be as follows: An enabling set of software-delivered capabilities to discover, reconcile manage, and optimize critical IT service interdependencies in the face of change. CMDB Systems are multidimensional in benefits that over time can support the full IT organization while providing a foundation for more effective alignment between IT and the business or organization it serves. CMDB Systems generally require attention to process, culture, and communication and technology to achieve their full value.

Technologically, the CMDB System is a means for reconciling multiple “trusted sources” to capture physical and logical service interdependencies. As such, its roots have been in data management and service modeling. This is evolving to become more inclusive of discovery, automation, analytics, and other technologies, as we shall see in Chapter 3.

The core CMDB might be defined as a central data store of critical IT environmental information, with links to such information stored in other systems, to document the location, configuration, and interdependency of key IT assets, both physical assets and applications. The CMDB can support the change process by identifying interdependencies, can improve regression testing by capturing insights surrounding these interdependencies, and can be helpful in diagnosing problems impacted by changes to the IT environment.

No doubt that the CMDB and, in particular, the CMDB System may sound like tall orders, and of course, they are. However, their benefits can be substanti...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Preface
• Introduction: How to Use This Book
• About the Authors
• Acknowledgments
• Section 1: Failure is Not an Option
• Section 2: The Basics
• Section 3: Awareness and Goals
• Section 4: Moving Forward
• Section 5: Running Your Project
• Appendix A: Glossary of Terms and Concepts
• Appendix B: Sample Request for Product Information
• Appendix C: Self-Assessment: What If You're Not Ready?
• Appendix D: Product Map
• Bibliography
• Index