CM Proposal

This page is a CM Proposal for a company looking to more tightly integrate their CM team which includes their CMDB and their SCM team.

Historically, the CM team focused on data center change management support. The SCM focused on software development support. CM developed the CMDB focused almost entirely on ITIL. SCM created a CMDB for middleware and internally developed applications.

Because these teams were in different organizations, the teams never had the management support to better collaborate. So, major gaps in processes and data were never addressed from a unified CM/SCM view point.

CM Proposal

The reorganization of Configuration Management and Software Configuration Management teams into one organization will allow the teams to fix these gaps in our CM/SCM processes and CMDB data.

The integration of the CM and SCM team will allow us to better serve the organization.

Configuration Management Links

• Configuration Management
• CMDB Best Practices
• CM Proposal
• CM Audit

Collapsing all the enterprise CMDB maybe the desired goal, but may not be achievable in our current state. It may require a staged approach to consolidate all enterprise CMDB data into one source of truth.

Note, that most CMDB experts think it is unrealistic to think an organization can have one all encompassing CMDB. It might be more doable to simply better report from the different databases.

Factors in Implementing a Successful CMDB

• All areas that use discovery technology or use CIs as their core data use the CMDB or the same conventions, e.g., application, network and enterprise monitoring.
• CIs are owned by the person responsible for their performance in production. Ownership means they are responsible for configuration data integrity
• The CMDB is used daily by almost every function in IT and becomes a shared trusted information source which can reduce search time and can highlight incremental changes
• As Incidents are resolved, solutions should be stored in the CMDB
• CMDB Administrator is only responsible for a limited set of support processes. Otherwise, the CMDB will be bottlenecked by the skill set and workload of the CMDB Administrator
• Discoveries source most of the CMDB
• Deployments automatically update the CMDB

CM Road Map

Instead of setting a 6 month plan and a 12 month plan, maybe the plan should be broken down into requirements gathering and implementation.

CM SWOT Analysis

The first 6 months will be a time to gather requirements for the new team. Although, both teams will continue to perform the services they provide now, it will take some time to gather new requirements for the newly formed team.

Even though, the teams would or could remain separate, it would be a team building exercise to perform a Configuration Management SWOT that includes all of our combined services.

CM Implementation Phase

After the SWOT is complete, start the implementation of the SWOT findings.

Benefits

• Centralized configuration database(s) = less maintenance costs, common APIs for better inter-operability, etc...
• Centralized management, decentralized updates = more accurate information, common processes, structured CMDB updates
• More agile to meet infrastructure and auditing requirements, by leveraging Enterprise Tooling and Agile development methodologies.