Home
SCM Blog
SOX
Build
Agile
CMMI
Six Sigma
ITIL
Sftwr Engineering
Software Testing
Config Mgmt
Release Mgmt
SDP
Subversion
Source Code
Forrester Reports
SCM Jobs
SCM Salaries
Contact Us
SCM EZine
FDD
Disaster Recovery
SCM War Stories

[?] Subscribe To
This Site

XML RSS
Add to Google
Add to My Yahoo!
Add to My MSN
Add to Newsgator
Subscribe with Bloglines

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.

History

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

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

CM Proposal

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

Configuration Management

CMDB Best Practices

Sample CM Plan

CM Audit

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

Enterprise Data Consolidation into one CMBD

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 tosimply better report from the different databases.

Factors in Implementing a Successful CMDB

This section describes common traits that organizations who are satisfiedwith their implementation of CMDB.

  • All areas that use discovery technology or use CIs as their core data use theCMDB or the same conventions, e.g., application, network and enterprisemonitoring.

  • CIs are owned by the person responsible for their performance inproduction. Ownership means they are responsible for configuration dataintegrity.

  • The CMDB is used daily by almost every function in IT and becomes ashared trusted information source which can reduce search time and canhighlight incremental changes.

  • As Incidents are resolved, solutions should be stored in theCMDB.

  • CMDB Administrator is only responsible for a limited set of supportprocesses. 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

    From this list, it is easy to see areas of opportunities for us to improvein our processes and data integrity.

    CM Road Map

    Instead of setting a 6 month plan and a 12 month plan, maybe the planshould 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 theyprovide 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 ateam building exercise to perform a Configuration Management SWOT thatincludes all of our combined services.

    CM Implementation Phase

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

    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.


    footer for CM Proposal page