“The secret of change is to focus all your energy, not on fighting the old, but on building the new.”- Socrates.
In this article, I will outline a fairly comprehensive framework view of Configuration Management (CM) objectives, implementation challenges and mitigation, how-to guide, as well as a future outlook.
The Importance of CMDB and Configuration Management
CMDB, or Configuration Management Data Base, is a repository of Configuration Items (CIs) that document the status, configuration, dependencies, and pertinent design information of technical assets. This includes, but is not limited to, the assets themselves as well as the relationship and dependencies between the assets. The information provided by the CMDB is critical to effective management of modern IT environments, and the ability to properly manage and deliver IT and Business services.
"Maintenance of CI information, as well as respective dependencies must be accurate at all times if organizations seek the efficiencies and transparency."
Configuration Management Objectives:
• Enhanced transparency to forecasting / planning changes and their downstream impacts
• Increased reliability / quality of change assessment, planning, delivery
• Improved ability to diagnose and resolve incidents and problems
• Ability to accurately set and monitor service levels
• Better adherence to regulatory requirements
• Ability to demonstrate and articulate value of IT to business
• Traceability of change history to requirements
• Ability to map service relationships among CIs and define service costs
• Transparency and accountability for performance, reporting, and changes to appropriate technology owners and business groups
CMDB Challenges and Approaches to Mitigation
Successful implementations and ongoing management / maintenance of CMDB are often challenged by the scope of data involved and the intricacy of relationship and dependency data. The apparent insurmountability of such obstacles often leads to “analysis paralysis” that prevents IT departments from maturing. However, these risks can be mitigated with a deliberate approach to design, scope definition, and governance:
Rightsizing the CMDB
Challenges: Not knowing where to start; inability to balance CMDB breadth and depth with organizational goals and objectives; lack of understanding of various tools already in use and their relationship to CMDB maintenance; and the need to align CMDB to the ITSM processes it underpins.
Mitigation: Critical application and dependency analysis to prioritize approach; Data architecture mapping to identify risks to data accuracy and reliability; and target state requirements and tools / vendor analysis to design for the future.
Validating and Normalizing Data
Challenges: Duplication of CIs obscure information on SLAs and trends; historical incident and change data may be lost when records are consolidated; errors in incident/problem routing; inconsistent approval of change activities; and lack of buy-in to CMDB if it cannot be validated.
Mitigation: “Golden Source” design mandate to drive all CIs to single and common source of record; CI discovery and service mapping implementation to validate configuration and identify discrepancies; and reporting / dashboard prototyping to ensure the right data will be available by design.
Obstacle: Governing the CMDB
Challenges: Lack of strategy for CMDB growth over time; ambiguous policies on how and when CIs will be updated; lack of designation of the system of record; lack of CI ownership; and lack of CI data standards.
Mitigation: Policies and controls to mandate scope, quality, ownership of CI data across the enterprise; responsibility and accountability matrix to crystallize roles and ownership structure; and service performance, CI quality and SLAs tied to annual performance evaluations.
CMDB Guiding Principles
The CMDB is a critical, foundational element of IT and business service delivery. Up-to-date and accurate information on the physical and logical configuration of infrastructure and applications provides the transparency and accountability needed to manage cost, performance, and innovation. The guiding principles for CMDB design and architecture will enable configuration data to remain evergreen, in order to facilitate downstream incident/problem/ change management and future IT and business services design.
Sustainability
• A properly architected CMDB should include models that encompass federation, integration and discovery
• The CMDB should be viewed as a dynamic entity that must be able to scale up and down as the environment evolves
Repeatability
• Processes, standards, tools and governance models must efficiently support the ongoing addition of:
1. New CI classes
2. New subnets for discovery
3. New locations
4. New vendors
5. New services
Automation
• Manual activities should be avoided, as they are prone to error and do not scale
• Changes to the environment must be reflected on a near real-time basis in order to capture the intended benefits of evergreen CI statuses
• Correlation and normalization of data should occur autonomously to support the evergreen mandate
Configuration Management Evolution
The benefits and objectives, challenges and mitigations, and guiding principles outlined above clearly illustrate why an evergreen mandate is key to a successful CM/CMDB program. Maintenance of CI information, as well as respective dependencies must be accurate at all times if organizations seek the efficiencies and transparency associated with best-in-class operating processes and models.
Today, as most companies pursue maturity of their discovery and CMDB capabilities using multitude products, there is a tremendous focus on creating simplified Application Program Interface (API) connectivity between all the respective CMDB tools with a controlling governance model. As this trend evolves, APIs too will evolve to ensure the correct CI information is appropriately pushed/pulled from these disparate systems.
The future of CMDB, therefore can provide a self-healing, self-correcting CI mechanism for all federated CMDBs, further ensuring data fidelity and authority, and further empowering IT departments to deliver high-performing IT and business services.
Configuration Items (CI) listed in the article, are components of an infrastructure that currently is/are, or soon will be under configuration management. CIs may be a single module such as a monitor or tape drive, or more complex items, such as a complete system. This is common Information Technology Infrastructure Library (ITIL) terminology.
The term “golden source” used in the article is a term commonly used to describe an up-to-date correct source of current information. When we have many sources (or repositories) containing similar data, the “golden source” is considered to be the authoritative source of the current data.
