Ignite Your Configuration Engines - Real world experiences for CMDB success: Part 1
Posted by Gaurav Uniyal, Consultant, Infosys Technologies
ITIL V3 (IT Infrastructure Library - Version 3) celebrated its first anniversary last month, and the authors would be reasonably pleased with the way industry has accepted the new concepts introduced by the framework. One of the interesting changes introduced by ITIL V3 is the Configuration Management System (CMS), a more realistic and realizable version of ITIL V2's CMDB (Configuration Management Database).
To discuss the changing dimensions of CMS/CMDB with the arrival of new service oriented technologies, market trends, vendor strategies, typical challenges and best practices for implementation, this month, the British Computer Society Configuration Management Specialist Group (BCS CMSG) and IT Service Management Forum (itSMF, UK) jointly organized the “The CMDB and CMS - the Powerhouse of Service Management” conference in London.
I also attended the event to present my thought paper - “Ignite your configuration engines: Real world experiences for CMDB success”, sharing my experience on the typical implementation challenges and real world's best practices for CMDB design and implementation.
This is the presentation I made
Know what could be delivered and how? - While participating in quite a few discussions with different organizations for designing CMDB solutions, I have realized that there is general lack of understanding on the “End-State” of the implementation. In fact, in response to a question asked during a research study conducted by Freeform Dynamics, CMDB project managers rated “General understanding of what CMDB is and what it offers” as the prime challenge associated with CMDB implementation. An early consensus on the “End-state” helps in managing the CMDB implementation project effectively and identifying interim milestones for demonstrating CMDB value.
Baseline current processes and technology landscape - A comprehensive assessment of the current process capabilities, technology landscape, interfaces with other processes/ tools, staffing and governance structure not only provides information on the improvement areas, but also helps in identifying the “Business Critical” areas for implementation prioritization. Assessment exercises also help in developing a business case to justify the investments and securing funds for the project.
Structured Requirements Gathering - Traditionally, interviews/ workshops are conducted to gather business and IT user's requirements for building the CMDB solution. However, user’s requirements are endless and a lot of time is consumed in capturing the accurate and complete set of requirements. One better approach for requirements gathering is to use a “Requirements gathering tool” with a list of requirements for selection. Use a “drop-down” kind of functionality to let users select the requirements across multiple sections e.g., interfaces, reporting, CIs coverage, CIs attributes etc., and document additional requirements which are not present in the tool. Doing this, a lot of time could be saved in capturing requirements and determining CMDB customization effort.
Analyze impact of the rollout - Is my organization operationally ready for the rollout? Have we identified the deficiencies in the present environment and its consequences? Do we have a backup plan if something goes wrong? These are some of the questions which need be answered before starting the implementation. Analyze the impact on the existing process, people and technology, and in turn analyze the "business impact" of the rollout. This not only help in getting prepared for any last minute surprises but also provide information on the steps required to make organization ready for the rollout e.g., trainings, communications, tool demo etc.
Develop processes to extract value out of the rollout - The true value of CMDB can never be achieved unless it is well supported by robust processes. One good approach for designing process architecture is to follow a top-down approach. Starting with writing high level policy statements, translate these policies into process/ procedures and then develop detailed work instructions to manage the CMDB operational tasks. While developing the processes, it is worthwhile to consider future growth and plan for a flexible and scalable architecture.
In my next blog, I will share some more real world’s best practices. If anyone has any questions, please feel free to post comments.
