Developing the Business Case for Change and Configuration Management and the CMDB

Table of Contents

I. Executive Summary ...... 2 II. Change Management Control as a Basis for CMDB ...... 4 A. It’s All About Change ...... 4 B. Is Root Cause Analysis Actually Effective? ...... 4 C. CMDB: A Means to an End ...... 5 III. Today’s Market Value of the CMDB ...... 7 IV. Business Drivers of ITIL Change and the CMDB ...... 8 V. Developing a Strategy for the CMDB ...... 11 A. Is a CMDB an Asset Management Database? ...... 11 B. Developing the Configuration Management Processes ...... 11 C. Beginning to Develop the CMDB Strategy ...... 12 VI. Developing Business Value for Change, Release and Configuration Management ...... 17 A. Change and Release Management ...... 17 B. Business Process Re-engineering ...... 17 C. Change Management Lifecycle Improvements ...... 18 D. Configuration Management ...... 22 E. Calculating Gains on Change, Release and Configuration Management ...... 23 VII. Developing the Business Case for a CMDB ...... 26 VIII. Appendices ...... 28 A. Appendix 1 - Roles and Responsibilities ...... 28 B. Appendix 2 – Skill Set ...... 30 C. Appendix 3 – Current CMDB Vendors ...... 34

Developing the Business Case for Change, Configuration Management and CMDB A Step-by-step Guide to Developing the Business Value for Change and Configuration Management

I. Executive Summary As enterprises and their IT support organizations grow, their infrastructures become increasingly fragmented and spread across a variety of functions, technologies and organizations. As this IT infrastructure ‘sprawl’ continues, efficiency, optimization and overall control over IT resources suffers.

In large and busy enterprises (500 plus changes monthly), organizations often address the IT infrastructure ‘sprawl’ issue with automated or, in some cases manual, Change ‘root cause’ analysis tools. However, spreadsheets and manually maintained asset and specific purpose configuration repositories cannot sufficiently take into account the inter-relationships of CIs and fall far short of effective root cause analysis for complex IT infrastructures.

Root cause analysis, then, not supported by an accurate CMDB database and automated business rules that address complex inter-relationship of CIs can be labor-intensive, as well as ineffective.

However, justifying, developing and implementing a CMDB is not an isolated activity, a technology implementation or a database development effort. A CMDB is a means to an end, not an end in itself, and the end(s) are increased Change Management and control and increased Configuration and Release Management control.

A strategy for CMDB deployment, then, must be developed, the goal of which is to identify and define Configuration Items (CIs) and their relationships; record and report the status of CIs and their related Incidents, Problems and Requests for Change (RFC); and verify the completeness and correctness of CIs. The strategy should include:

 Best practice literature review  Vendor literature review  Functional attributes critical to the implementation of your CMDB  An assessment of the current maturity of your organization in relation to Configuration Management  A ‘model’ reflecting the desired ‘end state’ of your organization in relation to Configuration Management

2 CMDB processes must also be developed addressing planning, verification and audit, identification, control, status accounting and reporting on the Configuration Management process. These processes should take into account ITIL Change Management and ITIL Configuration Management best practices.

The business value of an improved Change and Configuration Management process and a CMDB must be developed and documented for use in a business case. Templates can be used to collect data that will assist in the quantification of:

 Business process re-engineering  Change Management lifecycle improvements  Change Management approval board activities  Change and Configuration Management executions  Metrics to support and make the case for improved Change and Configuration Management and the CMDB

The business case should address:

 Change Management as a Basis for the CMDB

 Today’s Market Value of the CMDB

 Business Drivers of the CMDB

 Development of a Strategy for the CMDB

 Development of the Business Value of the CMDB

 Development of the Business Case for a CMDB

Ultimately the CMDB should be profiled as a crucial tool to the improvement of Service Level Management and an important underpinning to an accurate and effective Asset Management system.

For more detailed information on implementing your CMDB, download Evergreen’s guide to the implementation of a CMDB, ‘Nine Steps to the Implementation of an Effective CMDB’ at the link below: www.evergreensys.com/downloads/cmdb/

II. Change Management Control as a Basis for CMDB IDC’s January 2007 benchmarking study on CMDB and Change Management deployments claims that the CMDB is all about Change. States Stephen Eliot, research manager for Enterprise Systems’ Management Software Service:

“8% of enterprise IT organizations have deployed a CMDB. However, over the next three years, 70% of enterprise IT organizations will consider deploying a CMDB. On average, these organizations make 528 configuration changes a month, which causes an increase in complexity and a high rate of IT service failures. CMDBs are helping and will help IT organizations get infrastructure change under control”. 1

A. It’s All About Change So the business value of a CMDB is all about Change Control? True or False? The answer is “YES” and “YES”.

As enterprises and their IT support organizations grow, their infrastructures become increasingly fragmented and spread across a variety of functions, technologies and organizations. It becomes more and more difficult for IT to gain and maintain control over every Configuration Item (CI) encompassed by the infrastructure. Even an asset management database only archives IT’s assets and documents the CI locations, without exerting any control over them.

As this IT infrastructure ‘sprawl’ continues, efficiency, optimization and overall control over IT resources suffers. In Evergreen’s Q2 2006 survey on Change Management, 67% of respondents rated service quality as the top driver for Change Management, yet 40% reported greater than 26% of changes were short-term and emergency and 44% reported using an informal risk management process for Change Management. So service drives change, yet change processes still tend to be reactive.2

Change process and CMDB are ‘partners’ in executing the work of IT efficiently and accurately. At the highest level, change is the workflow of IT and the CMDB is the information store that provides data to support the decision-making process. This partnership is the functionality that drives an efficient change flow engine.

As realization of the importance of the value of Change Management evolves in large enterprises, organizations are beginning to ‘connect the dots’ regarding the relationship of Change Management to CMDB. Despite this fact, many companies are not doing the analytic work to get the real business value from the effort.

B. Is Root Cause Analysis Actually Effective? In large and busy enterprises (500 plus changes monthly), organizations often address the IT infrastructure ‘sprawl’ issue with automated or, in some cases manual, Change ‘root cause’ analysis tools. These tools analyze changes, in many case failed changes, to get at the ‘root cause’ of the problem.

1 CMDB Deployments and Change Management: Efficiency Benchmarks for IT Organizations, IDC, January 29, 2007 2 Survey on Enterprise Change Management Maturity, Evergreen Systems, June 2006

4 Root cause analysis is critical to the improvement of change control, but without that analysis in the context of all configuration items (CIs) and their inter- relationships, such analysis can be reactive, incomplete and in some cases, downright ineffective. Spreadsheets and manually maintained asset and specific purpose configuration repositories cannot sufficiently take into account the inter- relationships of CIs and fall far short of effective root cause analysis for complex IT infrastructures.

Root cause analysis, then, not supported by an accurate CMDB database and automated business rules that address complex inter-relationship of CIs can be labor-intensive, as well as ineffective.

C. CMDB: A Means to an End However, justifying, developing and implementing a CMDB is not an isolated activity, a technology implementation or a database development effort. A CMDB is a means to an end, not an end in itself. And the end(s) are:

 Increased Change Management and control  Implemented ITIL and IT process improvement best practices  Increased Configuration and Release Management control  Significant risk reduction (of failed changes)  Improved security and regulatory compliance  Greater management of the data center server and software footprint  A higher level of agility, efficiency, accuracy and optimization for IT  Accelerated execution and governance of SOA initiatives as a result of complete visibility into the complete component-based applications and their corresponding IT infrastructure  Reduction in problem resolution as a result of automated root cause analysis, driving up resource performance and availability.  Accelerated and simplified ITIL initiatives as a result of providing a common, accurate, system-level view across IT, speeding workflow and decision- making and supporting ITIL re-engineering efforts.  Better management, tracking and protection of IT assets, resulting in better asset utilization and optimized hardware and software licensing.

Says Dennis Drogseth in EMA’s February 2007 report on best practices for CMDB:3

“The CMDB should hold the relationships between all system components, including incidents, problems, known errors, changes and releases. The CMDB also contains information about incidents, known errors and problems and corporate data about employees, locations and business units. In addition…, the CMDB is often used … to hold details of services and to relate them to the underlying IT components… (and) … to store inventory details… such as suppliers, cost, purchase date and renewal date for a license.”

Two ITIL concepts central to the CMDB are “configuration items’, or ‘CIs’ and ‘libraries’. A CI is the record of the IT element (system, network, application, etc.)

3 Getting Started with ITIL’s Configuration Management Database (CMDB): Best-Practice Tips for Enterprise IT Professionals, EMA Research, Dennis Drogseth, February 2007

5 or business-related entity stored in the CMDB, while a library is “a collection of software or document CIs of known type and status.

So, how does ITIL relate to the CMDB? In short, the CMDB becomes for ITIL a trusted resource for assuring consistency and efficiency across many IT disciplines in support of IT Service Management (ITSM). ITIL does not in any way deal directly with architecture or architectural issues – it is one hundred percent devoted to IT process, ITIL provides the top-down view of processes (the “what” not the “how”) and the CMDEB provides the foundation upon which advanced IT functions are built. The CMDB is, in fact, a concept and not necessarily greater or smaller than its parent, ITIL, but in the “real world” represents an overlapping circle where architectural evolution and best practices come together.4

4 Ibid.

III. Today’s Market Value of the CMDB So what is the business value today for implementing Change and Configuration Management, as well as a CMDB? Studies have examined the effectiveness associated with ITIL-intensive activities and in some cases looked at Change and CMDB individually, yielding some interesting metrics:

 A 30% overall efficiency gain was reported, from research conducted by IDC with 11 different Global 2000 organizations from different sectors and geographies.5 Specific Change and Configuration Management gains include:

o Managing and supporting servers: 30.9% o Change Management: 28.4% o Managing and maintaining network infrastructure: 23.1% o Maintaining configuration database: 22.8% o Managing applications: 10% o Problem management: 9.4% o Service level management: 8.5% o Average number of network devices controlled per FTE up 57% o Average reduction in headcount growth: 12.2%

 The IDC study also documented significant gains that include:

o Three-year cost of investment: $2.1 million o Annual cost savings and increased revenue: $14.5 million o Net present value of three-year savings: $26.7 million o Payback period: 11.8 months o ROI over three-year life of project: 422%

 A $500 million savings from Proctor & Gamble, as well as a 6-8% reduction in operating costs and a 15-20% reduction in technology personnel.6

 A 25-35% reduction in time required to process changes across the infrastructure, a 39% reduction in systems abends and a 75% reduction in ongoing compliance workload from Food Lion, a 1,100-store grocery chain, working with Evergreen Systems.

 A total of 8% of enterprise IT organizations are deploying a CMDB, with a rise to 70% of enterprise IT organizations considering deployment of a CMDB within the next three years.7

5 Determining the Return on Investment from Deploying Integrated IT Service Management, IDC, April 2006. 6 Introduction to ITIL: Early US Adopters Show Business Value, EnterpriseLeadership.org, Elizabeth Ferrarini 7 Drogseth, op.cit.

IV. Business Drivers of ITIL Change and the CMDB In Q3 2006 Evergreen conducted a survey of one hundred (100) IT managers, directors and executives from 90 companies participating in the national itSMF conference in Salt Lake City. The survey was designed to gauge organizations’ commitment to ITIL process improvement initiatives that included Change and Configuration Management. It was also designed to determine if these organizations had re-engineered their processes and measured their success via metrics and milestones. Some of the results highlighted an emphasis on Change and Configuration Management:8

 57% reported that their current ITIL direction focuses on improvement of end-to-end IT service delivery, stressing Change, Configuration and Release Management.

 Top ITIL initiatives were identified as CMDB (64%), Incident and Problem Management (57%), Service Catalog (57%) and Change and Release Management (52%).

 Less than half (45%) have analyzed their top five incidents by call volume, and of these only 31% have performed root cause analysis on their top problems and less than 10% have business goals with ROI to improve these processes.

 Less than 30% have baselined their top five change workflows end-to-end. Of these, less than 19% have re-engineered these and less than 10% have quantified risk reduction and quality/cost efficiency gains that could result from re-engineering.

 Less than 19% have implemented four to five reusable change models based on risk and materiality.

What is striking about these results is that even though CMDB and Change and Release Management are identified as top initiatives by 64% and 53% of participants, less than 30% have baselined their top change workflows and less than 19% have implemented four to five reusable change models. Despite the fact that CMDB and Change Management are considered top priorities, many companies are not doing the analytic work to get the real business value from the effort and in the process are also missing opportunities to implement ITIL Change Management best practices.

Service quality and service delivery are still top priorities, and enterprises seem more focused than ever on exactly which initiatives are being targeted, (CMDB, Service Catalog, Incident and Problem Management and Change and Release Management). However, a good deal of work needs still to be done in the areas of root cause and work flow analysis, and organizations that have actually done this work and have metrics and deliverables associated with the analysis, are few and far between. Some recommendations from the study are to: (DELETE?)

8 Developing the Business Value of ITIL Survey Results, Evergreen Systems, November 2006.

In Q2 of 2006 Evergreen conducted another, similar survey that focused specifically on Change Management maturity, surveying one hundred (100) IT managers, directors and executives from 77 companies, organizations and institutions. This survey uncovered similar results:9

 67 % of respondents rated service quality as the top business driver for Change Management in their organizations.  53% reported using only one Change Management application today.  49% said that they use a Change Management application as an IT workflow tool.  72% of respondents reported that 30% or more of their IT staff use a Change Management application in a normal work day.  Almost half (48%) reported using Change Management to plan and execute Release Management activities.  39% integrate Change Management into their portfolio of project management tools today.  59% employ Change Management as a single, enterprise-wide IT Change Management policy and system.  Only 28% have a Change Assessment Board (CAB) review all planned changes prior to design.  40% reported that 26% or more of their changes were emergency, short- notice changes.  Fully 44% still use an informal risk management process for Change Management.

The Change Management survey showcased the fact that even though organizations understand the importance of Change Management to IT optimization, very little complex process improvement, analysis and automation has been applied to achieving that optimization. Some recommendations from the study are to:

 Analyze their top incidents by call volume.  Perform root cause analysis on their top incidents.  Determine implementation costs and return on investment (ROI) for implementing solutions to these top incidents.  Baseline their top Change workflows, end-to-end.  Calculate what re-engineering these workflows would cost and what it would save in efficiencies, calculating ROI and any possible risk reduction.  Implement four to five re-usable Change models based on risk and materiality.

Both studies highlight the fact that even though service delivery and service quality are driving IT process improvement initiatives and high numbers of changes are causing the need for improvements, few organizations are using the process and tools and completing the analytic work to get real business value from their efforts.

This paper makes the point that organizations can gain this business value from their Change Management control efforts by leveraging a CMDB and implementing ITIL best practices in Configuration Management.

9 Op.cit., Evergreen Systems Study on Change Management Maturity

Configuration Management is key to the implementation of effective Change Management control and requires automated root cause and impact analysis, a CMDB database that archives all CIs as well as their interactions and a Configuration Management process that leverages all these tools to manage Change and Release control across the enterprise.

Finally, other activities will be recommended to help IT managers make the business case for a CMDB, including building and promoting a CMDB strategy, using and populating templates for gathering data and developing metrics for ongoing measurement and evaluation of the CMDB.

V. Developing a Strategy for the CMDB

A. Is a CMDB an Asset Management Database? Oftentimes enterprises believe that if they have an asset management database, they also have a CMDB. This can be a confusing and potentially damaging misunderstanding.

IT Asset Management is the discipline of managing finances, contracts and usage of IT assets throughout their lifecycles for the purpose of maintaining an optimal balance between business service requirements, total costs, budget predictability and contractual and regulatory compliance. ITAM activities include the management of inventory, software licenses, vendors, procurement, leases, warranties, cost accounting, retirement and disposal.

The goal of Configuration Management, on the other hand, is to provide a logical model of the IT infrastructure that is accessed by all ITIL processes to drive consistency among them. Activities include identifying, controlling, maintaining and verifying the versions of configured items (CIs). The CI information should be stored in a single repository: The Configuration Management Data Base (CMDB).

Whether a given component is considered an “asset” or a “CI” or both is determined by what you do or plan to do with that component. A component should be considered an “asset” if you decide it is worth managing an associated contract, cost and/or usage attributes throughout its lifecycle. A component is considered a “CI” if you decide it is worth managing operationally for incidents, problems, changes, releases, capacity, etc. The same component can be both an asset and a CI if you decide to manage it for both administrative and operational purposes.

Both ITAM and ITIL’s Configuration Management share the need for reliable data about components in the IT environment. Thus discovery tools (a scalable means of keeping accurate data on deployed components) and a CMDB (a repository for reconciling and accessing the discovered data) can serve both ITAM and Configuration Management. ITAM is another process, like ITIL’s Incident, Problem and Change, that consumes and contributes data to the CMDB, creating value by taking actions based on CMDB data.

B. Developing the Configuration Management Processes A strategy for CMDB deployment, then, must be developed, the goal of which is to identify and define Configuration Items (CIs) and their relationships; record and report the status of CIs and their related Incidents, Problems and Requests for Change (RFC); and verify the completeness and correctness of CIs.

Configuration Management is an ITIL best practice process, a body of data and a set of technology as well. The process is the key to effectively planning, defining and maintaining an accurate and useful CMDB and consists of the following processes:

 Planning – Determine Policy, Strategy and Objectives for available information. Identify tools, resources and how information should be shared.

11  Verification/Audit – Perform physical audits and reviews to ensure data is complete and accurate.  Identification – Select and identify CI structures into the repository, including system of record, relationships and documentation.  Control – Ensure only authorized CIs are captured ‘receipt to disposal’. Also ensure no critical CIs are added or modified within the repository of record without appropriate control documentation (example: an approved Change Request).  Status Accounting – Collect and monitor critical CI history and current status for completeness and accuracy.  Reporting – Support reporting requirements from other process areas in support of process function and data integrity.

The CMDB and the underlying technologies can be somewhat confusing at times. Should the focus be on technology or process and data? Because there are no real standards for these technologies, how does one know what they really need to be successful? The next section provides a suggested roadmap to ensure that success.

C. Beginning to Develop the CMDB Strategy Your strategy should include:

 ITIL Change and Configuration Management best practice literature review  Vendor literature review  Functional attributes critical to the implementation of your CMDB  An assessment of the current maturity of your organization in relation to Configuration Management  A ‘model’ reflecting the desired ‘end state’ of your organization in relation to Configuration Management

The steps below can help to outline how to begin developing your CMDB Strategy.

1. Review current ITIL Change and Configuration Management ‘best practice’ thinking:

A number of industry analyst reports showcase this thinking.10 11

2. Review ‘whitepapers’ written by some of the sectors’ leading CMDB software and solution vendors:

Take a look at the ‘whitepapers’ written by some of the vendors to get a sense for what they provide but remember who is writing the paper. Ask vendors of interest to demonstrate how the technology meets the requirements of today and what their plans are in the next 18 to 24 months. (Refer to the vendor rundown in the appendices.)

10 CMDB or Configuration Management: Know the Difference, Gartner, March 16 2006, Ronni J. Coville 11 Application Mapping for the CMDB, Forrester Research, Q1 2006, Jean-Pierre Carbani and Thomal Wendel PhD

12 3. Review the functional attributes critical to the implementation of a CMDB for specific fit and value in your business and evaluate your organizations’ capabilities to support these attributes. Attributes to consider:

 Reconciliation is the ability to rationalize one or more instances of a CI that is discovered and determine that they are the same item and that their relationships are identified are accurate. This serves as the hub for discovered data prior to updating the CMDB.

 Federation enables multiple data sources to be brought together to represent a coalesced view of a defined level of data. ‘Data stores’ can then be established and linked to the CMDB. The configuration data in a specific IT domain should be managed in the repository appropriate to that domain. However, a subset of data will be kept current in the CMDB and should be easily linked to the CMDB so that a ‘drill down’ into more detail can be performed (e.g., past incidents recorded against a CI).

 Mapping and Visualization provides the ability to illustrate logically and physically the hierarchical and peer-to-peer relationships between CIs. The capabilities must go beyond parent-child relationships to multi-level and functional relationships. This should include reporting capability of various views and, eventually, ‘what-if’ capability to simulate the impact of a change on a specific service or system (previously referred to as ‘impact analysis’). Additional functional relationships that should be supported are:

a. Ownership – the owner of/submitted by b. Direction – governs, uses or runs on c. Communications – creates a data feed to d. Conditional – A activates B if C occurs e. Connectivity – connected to, installed on

 Synchronization provides the ability to update the CMDB with approved changes and to (1) identify changes that were made and not authorized or (2) did not meet the conditions of a change of a specific type or CI.

4. Assess your organization’s Configuration Management maturity:

The simple tool provided below can help you benchmark your organization’s maturity in the area of configuration management against best practice (Information Technology Infrastructure Library/ITIL) standards.

This assessment should be conducted as it applies to the entire IT organization, not to an individual or a group of department(s) or function(s). For each assessment question, choose the answer that most accurately reflects the current state of the environment from the whole department’s point of view.

KPAs (Key Process Areas) are used to help develop and measure the benchmarked standards. All of the goals for a specific KPA (Key Process Area) must be satisfied for the KPA to be satisfied. All of the KPAs within a maturity level and within each lower level must be satisfied to be rated at that maturity level.

13 KPAs apply to a repeatable maturity level. In the Infrastructure Technology Infrastructure Library (ITIL), a repeatable maturity level means that the most important processes have been introduced. The effective structure of IT processes is predictable, and the provision of IT services is repeatable. The process returns defined results within a specified time. Repeatable levels are the lowest level of maturity, via ITIL standards, in which processes and procedures can be considered reliable and consistent.

Keep in mind that the main purpose of Configuration Management is to establish and maintain the integrity of products that are subject to or part of the IT services. Configuration Management involves the identification of the relevant hardware and software components that need to be put under configuration control. This includes components owned by the customer that are being managed by the service provider, components owned by the provider that are used by the customer and components owned by the provider that are used to deliver the service. Changes to the configuration are evaluated with respect to the service level agreement and with respect to possible risks for the integrity of the configuration.

A Configuration Management plan covers the Configuration Management activities to be performed, the schedule of the activities, the assigned responsibilities, the resources required (including staff, tools and computer facilities), the CM requirements and activities to be performed by the service delivery group and other related groups.

The table below helps to assess the maturity of an organization’s repeatable Configuration Management levels. The scoring key below indicates how each question should be scored, and interpretation of scoring is included below the table. Total score should indicate whether an organization has a consistent, inconsistent or non-existent approach to this KPA:

Scoring Key: 3= Consistently 2= Inconsistently 1= Never

Process Area: Configuration Management Score 1. Is a Configuration Management plan prepared for each service according to a documented procedure?

2. Is a documented and approved Configuration Management plan used as the basis for performing the Configuration Management activities?

3. Is a Configuration Management library system established as a repository for the configuration base lines?

4. Are the products to be placed under Configuration Management identified? Are action items for all configuration items/units initiated, recorded, reviewed, approved, and tracked to closure according to a documented procedure?

5. Are action items for all configuration items/units initiated, recorded, reviewed, approved, and tracked to closure according to a documented procedure, by an automated process or toolset?

6. Are changes to configuration baselines controlled according to a documented procedure?

14 7. Are (software) products from the configuration baseline created and released according to a documented procedure?

8. Is the status of configuration items/units recorded according to a documented procedure?

9. Is the procedure in question 8 facilitated by an automated system?

10. Are standard reports documenting the configuration management activities and the contents of the configuration baselines developed and made available to affected groups and individuals?

11. Is the procedure in question 10 facilitated by an automated system?

12. Are configuration baseline audits conducted according to a documented procedure?

13. Are configuration baseline audits facilitated by an automated toolset?

Total Scoring Configuration Management

Interpretation of Scoring:

35-52= Consistent approach to Configuration management

21-34= Inconsistent approach Configuration management

Under 21= No organized approach to Configuration management

5. Develop a ‘model’ for your desired ‘end state’ for a Configuration Management system:

The first critical step in developing a desired ‘end state’ for your Configuration Management system is establishing a sound reconciliation process. This involves developing a plan to relate CIs in your infrastructure as well as the scope of attributes that will be included in the CMDB. Discovery and mapping tools can be used to gather discoverable information for the first time.

Once your reconciliation process is designed, you may want to develop a process to filter the discoverable data to only those attributes that you will manage in the CMDB. (Note: There may be other information you discover that is required for other processes such as asset management. Use the discovery reconciliation tool to create a filtered view of asset management data before updating the ITAM data repository.)

Only after the filter is created should the CMDB be populated with the discovered data. The physical data discovered should be linked to the logical data in the CMDB. A plan should be developed to generate reports for a minimum of 10% of the planned data sets and also one to audit those records for accuracy. This may require checks of the physical data of a sample of servers and the relationships between servers and applications for example.

15 Once your model is designed to capture an accurate view of the CMDB, an exception process should be developed against the ‘gold datasets’. A process should also be developed to regularly schedule updates. If differences develop against the ‘gold dataset’, the CMDB should be able to produce exception reports for changes in a particular dataset. Each exception should be reviewed to ensure that the change is supported by a corresponding change record in Change Management. In fact, the Change Management record should have a task that includes the final check of the exception by Configuration Management to ensure that the change is an expected change. Unexpected changes can then be handled by exception reporting and corrective action taken.

Finally, be sure to establish an audit process to spot check for accuracy and develop a set of metrics to measure accuracy on an ongoing basis

6. Develop a resource plan for implementing your CMDB:

A Configuration Management system and a CMDB will require some specialized resources, some that can probably be harvested from your existing IT personnel pool and given some specialized training and some that may have to be recruited specially, depending upon your current resources. Appendices 1 and 2 provide detailed matrices of required resources and the sorts of skills and training that they will require.

For a more detailed planning guide on how to implement a CMDB see: www.evergreensys.com/downloads/cmdb/

VI. Developing Business Value for Change, Release and Configuration Management Now that the Configuration Management maturity of your organization has been evaluated, the next step is to begin to quantify the value of improvements to your Change, Release and Configuration Management processes. This section should assist in helping to quantify and document the business value of an improved Change and Configuration Management process, as well as the value of a CMDB.

Templates will be used to collect data that will assist in the quantification of:

A. Change and Release Management Because Release Management is at the highest level a type of change, Change and Release Management will be grouped together into one category. The goal of Change Management is to ensure that standard approaches are used for all changes made to the IT infrastructure, yielding efficient and accurate outcomes.

Change Management controls changes to all Configuration Items (CIs) and follows a lifecycle approach—Plan, Approve, Execute, Review. At a higher level, Change is the workflow engine of IT. It links customer requests with outcomes end to end through IT. Typical activities in the lifecycle of Change Management include:

 Planning—proposing a change; justifying the need, identifying the business benefit and assessing the impact, risks and costs associated with the change.  Approving—reviewing and validating the proposed change and ensuring impacted entities have the opportunity to provide feedback.  Executing—managing and coordinating the change and ensuring correct completion.  Reviewing—reviewing change outcome and impacts; evaluating lessons learned, if applicable; and closing the change request.

B. Business Process Re-engineering Classic Business Process Re-engineering efforts show the greatest gains when looking at workflows that are more complex (have a greater number of steps and approvals) and cross three or more areas (silos) in going from start to finish. Organizations that have not base-lined and re-engineered the top five to six high- volume workflows in IT can see efficiency gains of 25-40%.

To provide adequate evidence of the value of re-engineering, select three high- volume workflows crossing three or more areas. Examples may include IT security approval processes, medium-level software programming changes (such as 20-40 hours of code development), IT procurement actions, server operating systems or database upgrades.

17  Using a spreadsheet, interview those involved from end to end to create the ‘as-is’ process state. Review the workflow for unnecessary steps, duplicative activities, excessive manual activities, excessive delays and rework caused by inaccuracies and errors due to poor end-to-end understanding and communication.  Build the desired state by devising the most simple, streamlined approach to meet the business requirements and assume the use of basic Change Management technology to automate communications and workflow.  Measure the expected change in efficiency and elapsed time.

In practice, simple workflow end-to-end redesign can be done in a working session with the relevant parties. By facilitating discussion of the current state and its drawbacks, it is relatively straightforward to build the desired state, step by step, as the current state is being documented. Additional refinement of the desired state can be done after the working session.

C. Change Management Lifecycle Improvements Key improvements can also be found in the four phases of the Change Lifecycle— Plan, Approve, Execute and Review. A great deal of IT time and energy goes to Change Management execution. For most organizations, there are valuable opportunities for improvement in other areas that are often overlooked.

1. Change Management Planning

Most potential for gain in this area will be uncovered by discussing the Change Planning process with those handling the IT change requests. Typical improvements come from raising the bar for change approval (saying no to changes that are not justified), empowering those requesting the change to plan it, matching level of effort in change planning with the materiality of the proposed change, and clarifying and communicating expectations related to change submission completion and lead times. The table below should assist in analyzing the Change Planning process for improvement opportunities.

Change Management Planning Analysis Table  How many different types of changes are there; how are they grouped?

 Is there a process to group changes into five or six types, based on risk and materiality (cost and business value)?

o If so, is there a reliable process for ranking changes that is not self-selected by the requestor?

 Have change requestors (users) been empowered through some type of self-service function to create and submit change request packages?

o Are there clear submission guidelines and change lead times based upon the risk and materiality weighting of the proposed change? Have these been well communicated?

 What percent of change requests have errors or lack appropriate support and must be returned for rework?

 What percent of change requests are non-standard for lead time? (Short-notice or emergency changes arising from lack of advanced planning.)

18  What percent of change requests are rejected based on not meeting minimum business justification levels?

 What backlog of change requests exists at this stage?

o How does it break down by change request type? o What should the level be, and what impact does it have on the business, if any, at the current level?

 General Improvement Questions:

o Ask staff what they would change, if anything. o What is most frustrating in their jobs and why? o What achievement(s) are they most proud of? o What activities do they see as adding no value?

2. Change Management Approval

Most potential for gain in the Change Management Approval area will be uncovered by discussing the Change Approval process with those handling the IT Change Approval process. Typical improvements come from streamlining and routing approval processes based on risk and materiality, reducing approval activities by screening out unqualified requests, reducing time required by standardizing and improving the quality of the requests, and planning work more efficiently by raising compliance with submission lead time standards.

Change Management Approval Analysis Table  Are there different levels of approval process and oversight?

o If so how are the levels defined? . Are they directly linked to the change planning activities? o Does the level of impact analysis vary with the risk or materiality?  What percentage of change requests are rejected at the Change Advisory Board level?

o What are the top three reasons for rejections? . Incomplete? Undetermined risk? Poor impact analysis? Lack of business value?

o What are these rejections costing the business?  What percent of change requests reviewed for approval are non- standard for lead time? (short-notice or emergency changes arising from lack of advanced planning)

o What are these emergency requests costing the organization?  What percentage of change requests are reviewed by the Change Advisory Board that are not worthy of their involvement?

o How do these submissions get to this level? o Does this create risk by limiting the time available to review truly critical change requests?

19  What backlog of change requests exists at this stage?

o How does it break down by change request type? o What should the level be, and what impact does it have on the business, if any, at the current level?

 General Improvement Questions:

o Ask staff what they would change, if anything. o What is most frustrating in their jobs and why? o What achievement(s) are they most proud of? o What activities do they see as adding no value?

3. Change Management Execution

Most potential for gain in the area of Change Management Execution will be uncovered by discussing the Change Execution process with those doing the work and passing it from silo to silo. Typical improvements come from streamlining and reducing complexity by grouping similar workflows and reducing them to a manageable number. For example, all server upgrades are ‘essentially’ the same, yet many organizations have completely different workflows for each type of server platform.

Executing via common workflows makes the work of IT less customized and more replicable. Gains in efficiency, simplicity, accuracy and service quality are common, along with reductions in cost and risk. These improvements come from:

 Filtering approval processes based on the risk and materiality of the proposed change.  Reducing approval activities by screening out unqualified change requests.  Reducing work time required by standardizing and improving the quality of the requests.  Planning work more efficiently by getting staff to comply with change submission lead time standards.

The table below should help calculate the value of improved Change Management Execution:

Change Management Execution Analysis Table  Which, if any, high-volume activities have been grouped into common workflows? (How will grouping affect reduction of repetitive activities including which ones, how many, etc.)

 Which, if any, workflows have been redesigned (at the enterprise level) and automated in Change Management? (Calculate enterprise-wide labor savings based on automation.)

 What backlog of change requests exists at this stage?

o How does it break down by change request type? o What should the level be, and what impact does it have on the business, if any, at the current level? (Calculate the impact of reducing RFCs on service delivery.)

20  What percentage of changes were emergency?

o For non-emergency changes treated as such, what was the cost to the business to handle these? (Calculate the volume of unusual costs of emergency changes.) . What was the root cause?

 Calculating Non-Quantifiable Value:

o Ask staff what they would change, if anything. o What is most frustrating in their jobs and why? o What achievement(s) are they most proud of? o What activities do they see as adding no value?

4. Change Management Review

Most potential for gain in the area of Change Management Review will be uncovered by discussing the Change Review process with those performing the review work. For most organizations, effective change review is the most neglected change activity.

Changes that do not fail, but don’t perform well for some reason or other are rarely reviewed. Changes that fail during execution or illustrate themselves as software failures are obvious and should be considered separately. More subtle changes need to be examined separately and root causes examined. Changes that cause serious failures, often evidenced by unplanned downtime or worse, usually do receive in-depth analysis. These often result in major systematic course corrections, but only after the fact, when high costs have been incurred. Red flags should go up for changes that fail during initial execution, but more subtle changes should be investigated thoroughly as well. Many IT organizations operate reactively and thus ignore these more subtle changes, spending the majority of their time on reactive analysis.

Typical improvements come from better change review activities that reduce the number of failures and also reduce the number of changes that fail in execution, thereby reducing the number of ‘near’ failures. Questions for analysis of the Change Management Review function are listed in the table below.

Change Management Review Analysis Table  Review the failed changes and the changes that caused failures in a given period by type, risk, materiality and configuration item (CI). Consider:

o Which changes failed and had to be reversed? . Review root causes and actions taken . (Calculate costs in labor and reduction in service levels) o Which changes caused system failures? . Review root causes and actions taken . (Calculate costs of risks)

21 o Which changes consistently take longer than projected; why? . Is there an unrecognized risk here? o Review cost and risk to the business for all of the above. Consider incident volume related to these changes to help determine impact to the business. (Calculate the number and type of incidents and costs to the business.)

o For any CI with a high percentage of changes, was deeper analysis performed? If so, what were the findings? (Try to pinpoint costs associated with change problems associated with particular CIs and their impact on the business.

 What percentage of changes were emergency and high-risk changes?

o Review root causes and actions taken

Analysis of the findings in Change Management from the perspectives of basic re- engineering of key, high-volume workflows and key improvement points in each of the four phases of the Change Management lifecycle should point out clear opportunities for business value improvement. These include improvements in service quality, efficiency, accuracy and agility, and reductions in risks and costs.

D. Configuration Management According to ITIL, Configuration Management “provides a logical model of the IT infrastructure by identifying, controlling, maintaining, and verifying the version of all Configurations Items in existence.” A Configuration Item (CI) is defined as a component of the infrastructure. All the detail and relationship information about CIs is stored in a repository—the Configuration Management Database (CMDB). All ITIL processes access the CMDB, which is fundamental to consistency across ITIL processes.

One can think of the ITIL Service Management processes as IT workflow and the CMDB as an information store. Workflow accesses the information store to plan and execute more effectively. Many organizations are working on CMDB functionality today, but few have an operational CMDB. If there is no CMDB ‘baseline’ today, then how can one assess the potential value of a CMDB in the organization? The answer lies in assessing the following:

 Improvements related to IT asset effectiveness.  Improvements in effective Incident and Problem Management.  Improvements in Change and Release Management.  Providing source data for compliance activities

In most cases, the CMDB will be a superset of IT asset management information, and as such, analysis can yield useful information from classic IT asset management queries. The table below can assist in that assessment.

Configuration Management Execution Analysis Table  Do we have an accurate IT hardware and software discovery capability?

 Have we reconciled discovered software assets with significant software license agreements?

22 o Have we used this information in negotiations with the vendor? o Have we gone a step deeper and reviewed license use by user? o (Calculate software license savings.)  Have we done the same for hardware assets? (Calculate savings on hardware assets from better lifecycle management.)

 Have we done the same for telecom assets/circuits? (Calculate savings on telecommunications assets.)

 Have we done the same for outsourced relationships where pricing may be based in part, or in whole, on some asset count?

 Have we used this data to reconcile insurance and property tax costs? (Calculate reductions in insurance and property tax costs.)

 Have we reconciled assets with department managers to recover underutilized assets? (Calculate saving based on better asset utilization.)

 Is the data being used in chargeback system by department?

IT staff that provide level 1-3 support can be valuable resources in this area, as they understand the value of having asset and configuration information at their fingertips during incident diagnosis. The table below can assist in this analysis.

Asset and Configuration Management Data Analysis Table  What are the top three to four incident types that could be resolved more effectively by having asset and configuration data easily available?

o How are these resolved? (Calculate cost of not having this information.) o What volume of incidences does this affect? o For these incidences, what is the end-user downtime impact? (Calculate this impact on the business.)

 Is lack of asset/configuration information the root cause of any problems today?

o Could effective asset data eliminate any common types of incidences? o (Calculate the impact of this on the business.)

E. Calculating Gains on Change, Release and Configuration Management Potential improvements in the Change and Release Management processes can include the following:

 Reduction of systems failures  Reduction in failed changes  Reduction of risk  Improvements in efficiency, accuracy and service quality that transform IT from primarily reactive to primarily proactive

23 Gains could come in all phases of Change and Release Management, including planning, approving, executing and reviewing changes and releases, as well as the core re-engineering of the high-volume workflows.

In each Change Management activity, there should be an analysis to determine what asset and configuration information would improve the speed and accuracy of the activity. For most organizations, informal repositories of asset and configuration data are maintained in each technical silo, with varying degrees of accuracy. The cost of maintaining these multiple repositories should be explored, as well as impacts and failures that may arise form inaccurate data.

Most change failures are self inflicted and caused by the unintended consequences of changes. For many of these failures, the root cause of the failure is an inability to accurately understand the true impact of a proposed change. The root causes of all change and system failures should be examined, and a determination should be made as to which of those could have been prevented by accurate impact analysis.

Most potential for gain in Change Management comes from re-engineering and automating high-volume IT workflows (changes), viewed in two ways:

 Basic re-engineering of key, high-volume IT workflows.  Key improvement points in each of the four phases of the Change Management lifecycle.

One way to approach calculating the value of re-engineering high-volume workflows is to:

 Calculate productivity, time and expense associated with the major high- volume IT workflows currently.  Once re-engineered (projected for re-engineering) re-calculate those same productivity, time and expense figures with the new workflows.

Key improvement points in each of the four phases of the Change Management lifecycle should also be examined for value gains as defined in the previous sections. Review and quantify for gains in service quality, efficiency, accuracy, agility and reductions of risk and cost.

Configuration Management can be a bit easier for calculating gains. The areas detailed below should be investigated for calculating value:

 Accurate software discovery can yield reconciliation between software assets and licensing agreements that can yield real-dollar savings and be used in software site and seat licensing negotiations.

 Similar types of reconciliations can yield additional dollars when applied to hardware, telecom and outsourced assets. Accurate inventory quickly turns up where funds are being ignored or under-utilized.

 Reconciliation of all this data can yield additional savings in taxes and insurance costs as well.

 Recovering underutilized assets from other departments saves dollars as well and can result in redeployed assets that can save money on expenditures for additional equipment.

24 Organizations with advanced IT asset management practices have recovered millions of dollars by eliminating unnecessary expenditures. Although a CMDB has no inherent value in and of itself, its value is derived by all of the IT processes that it improves and should be considered as part and parcel of an overall IT process improvement strategy.

VII. Developing the Business Case for a CMDB With objectives and metrics in place, your organization is now poised to develop your business case for CMDB.

Use the list below to analyze the information gathered so far and organize and document your business case for Change and Configuration Management and the CMDB.

Change Management as a Basis for the CMDB This component of the document should make the case for the development of Configuration Management as a tool for effective change control for organizations that process high numbers of changes on a regular basis. Some reference to your organization’s regular number of changes is appropriate here. Arguments may be presented about the inadequacy of simple change control methods (such as root cause analysis) to manage high numbers of regular and emergency changes.

Today’s Market Value of the CMDB References should be made to current literature and benchmarks around CMDB. Analyst, consulting and vendor viewpoints should all be taken into account.

Business Drivers of the CMDB Document what the business drivers are in your organization for Change and Configuration Management and the CMDB.

Develop a Strategy for your CMDB Document and develop your CMDB strategy. This should include (1) establishing objectives for the CMDB; (2) benchmarking your organization’s CMDB ‘maturity’; (3) developing the process for the CMDB; (4) ‘modeling’ your CMDB against your desired ‘end state’; and (5) developing a resource plan for implementing your CMDB.

Develop the Business Value of a CMDB Use the enclosed table to develop the value to the business of improved Change and Configuration Management through the development of a CMDB. Calculate gains that can be improved through Change and Release Management, business process re-engineering, Change Management lifecycle improvements and improved Release Management.

Develop the Business Case for a CMDB Summarize all of the information in a business case, pulling together arguments for improved Change Management, market value of a CMDB, the organization’s business drivers, your proposed strategy for implementing the CMDB and the metrics associated with the business value that a CMDB will bring to the organization.

It would be useful to conclude your business case with a summary of the strategic benefits associated with the development of a CMDB, including:

26  Increased Change Management and control  Increased Configuration and Release Management control  Significant risk reduction (of failed changes)  Improved security and regulatory compliance  Greater management of the data center server and software footprint  A higher level of agility, efficiency, accuracy and optimization for IT  Accelerated execution and governance of SOA initiatives as a result of complete visibility into the component-based applications and their corresponding IT infrastructure  Reduction in problem resolution as a result of automated root cause analysis, driving up resource performance and availability  Accelerated and simplified ITIL initiatives as a result of providing a common, accurate, system-level view across IT, speeding workflow and decision- making and supporting ITIL re-engineering efforts  Better management, tracking and protection of IT assets, resulting in better asset utilization and optimized hardware and software licensing

The most important benefit to the implementation of an effective CMDB is that it anchors effective optimization of all other functions within the IT infrastructure, including the processes that support Change, Problem, Incident, Release and Configuration Management. Each of these disciplines is linked to the CMDB:

 CI information is utilized to quickly and accurately identify and resolve incidents.  Data from the CMDB is used by problem management to troubleshoot and also to perform root cause analysis.  The impact of proposed changes is calculated by accessing the CMDB for information and using it to maintain an audit trail for compliance and reporting.  The CMDB supports Release Management in the deployment of changes, planning and impact assessment and as a tool for recording updated CIs.

Finally, the CMDB is profiled as a crucial tool to the improvement of Service Level Management and an important underpinning to an accurate and effective Asset Management system.

Appendices are also presented that provide details on CMDB resource requirements, ‘best-of-breed’ vendors and potential pitfalls associated with CMDB development.

VIII. Appendices

A. Appendix 1 - Roles and Responsibilities The following table describes the CMDB implementation team members for a very large enterprise. Smaller projects can scale down accordingly.

Project Role Project Responsibilities Ongoing Responsibilities Sponsor/Stakeholder Defines Use Cases/Value realization, ultimately responsible for delivering ROI Owns Financial and contractual issues, non-technical aspects of CMDB “Sells” value throughout the organization, acts as a CMDB “Champion” Communicates goals, timelines, deadlines to Project Team and other Roles CMDB Administrator Installs CMDB components, CMDB GUI Client, patches, updates and upgrades Owns packages and physical parts of discovery patterns Maintains architecture and deployment documentation from PSO and afterward Owns stability and performance SLAs, implements best practices Owns system settings, limits, configuration, circuit breaker settings Maintains events and event configuration Owns Backups and DR readiness plan and operations Connectivity and communication between server, gateway, probe and client Owns and delegates authority to use the JMX administrative console functions Administers security, users, profiles, permissions, etc. Creates and deploys enrichments at the system level Discovery Manager Owns logical parts of discovery patterns (function, parameters, etc.) Owns domain scope (IP ranges, Protocols, Credentials) Schedules discovery Runs on demand discovery or delegates authority to do so Validates discovery results, iterates rediscovery, repair discovery Works with Mapping specialist to gather discovery credentials Goes between CMDB administrator (which may be self in small shops) and the owners of the discovered infrastructure Ensures the discovery strategy supports the use cases for CMDB Deploys/maintains integration patterns to external applications

28 Owns incoming data into the CMDB (manual entry, integration, etc.) Works with the IT CMDB Configuration Manager Mapping Manager Responsible for delivering value of Use Cases Interacts with Application SMEs, Owners and Users Architects/implements Application Mapping strategies Architects/implements Reporting structures and usage, Change detection/management strategies, Correlation, etc. Architects/implements enrichments at the application level Goes between CMDB administrator (which may be self in small shops) and the owners of the discovered infrastructure Ensures the discovery strategy supports the use cases for CMDB. Works with CMDB Discovery Manager and Administrator to resolve issues Responsible for reporting value realization to Management / Stakeholders “Sells” value throughout the organization, acts as a CMDB “Champion” DBA Creates database Manages database performance and Allocates database space growth, monitoring, tuning, reorgs, etc. Performs security actions to allow CMDB installation Backups Available for problem solving during Allocates additional space as installation needed Available for infrequent problem solving Server Assists with scoping/hardware planning Manages CMDB server hardware Administration Procures/allocates CMDB component Manages CMDB server/OS (space, hardware patches, etc.) Verify OS/software compliance Network Verifies network connectivity Maintains component connectivity Administrator Assists in probe deployment planning Maintains connectivity to target environments

Security Facilitates credential-gathering processes Responsible for CMDB component Administrator for installation security Facilitates credential-gathering processes Controls/delegates discovery for discovery credentials Configures firewalls (may be Network Admin) Verifies CMDB security precautions Application SME Consults with application mapping Validates application maps specialist Identifies superfluous/missing Verifies use cases components Provides initial documentation of existing, Possibly, the end-users of the manually assembled maps (Visio diagrams) mapping effort Users / End users of Use cases verified Validates use case implementation project Demo/training Provide qualitative feedback

29 B. Appendix 2 – Skill Set Three of the project roles described in Appendix 1 need certain skills ideally. If possible assign individuals with the following backgrounds.

1. CMDB Administrator

The CMDB Administrator is a technical IT position, requiring a standard combination of server, networking, database and application support skills. The focus with the CMDB Administrator is maintaining performance and availability of the CMDB server and ensuring the CMDB architecture is deployed as designed and documented as required. The major skill levels and areas required for the CMDB Administrator are:

 Networking: – Basic understanding of TCP/IP networks and network hardware – Firewalls and DMZs – Basic Connectivity concepts such as networking protocols and packet sniffers  Windows: – Basic Windows administration skills – Windows domains – NETBIOS/drive mapping/windows networking and connectivity  UNIX: – Basic understanding of UNIX OS and concepts: – UNIX shells and scripting – UNIX file systems – UNIX networking concepts  Database: – Basic MSSQL or Oracle user skills – Basic SQL knowledge, SQLPlus for Oracle, Enterprise Manager for MSSQL – Basic understanding of basic database architecture, e.g., table spaces, allocated disk space, etc.  J2EE: Basic understanding of java and J2EE application architectures  Application: – Ability to manage and support a distributed, enterprise-level application – Ability to diagnose/troubleshoot problems – Experience working with vendors and vendor support – Ability to trace transaction flow and use logging facilities for problem solving

30 2. CMDB Discovery Manager

The CMDB Discovery Manager is a technical IT position, requiring a broad background in multiple IT disciplines. A competent discovery manager is key to a successful implementation. Wise customers will choose their most technically competent resource available for this position. The major skill levels and areas required for the CMDB Discovery Manager are:

 Networking: – Advanced understanding of TCP/IP networks and protocols – Good understanding of network hardware and network devices such as Firewalls, DMZs, load balancers – Advanced connectivity concepts such as networking protocols and packet sniffers, VLANs, bandwidth – Networking protocols: SNMP WMI UNIX and Windows Command Line protocols (TTY/SSH/Telnet) JMX Application-specific protocols (generic)  Windows: – Advanced Windows administration skills, including WMI – Windows domains – NETBIOS/drive mapping/windows networking and connectivity  UNIX: – Advanced understanding of UNIX OS and concepts: – UNIX shells and scripting – UNIX file systems – UNIX networking concepts – UNIX administration commands used for discovery, such as ifconfig/ipconfig, df, ps, etc.  Database: – Basic MSSQL or Oracle user skills, ability to interpret system-level SQL statements used for discovery – SQL knowledge, SQLPlus for Oracle, Enterprise Manager for MSSQL – Basic understanding of basic database architecture, e.g., table spaces, allocated disk space, discovered database resources, etc.  J2EE: – Basic understanding of java and J2EE application architectures, EJB, administration consoles, J2EE servers and domains and JDBC.

31  Application: – Good understanding of older as well as modern application architectures; 2- and 3-tier applications, OSI model of layers – Ability to architect and deploy discovery processes: Discovery scheduling Working with other IT administration groups such as networking, DBAs, Server Administrators and Security Administrators – Experience working with vendors and vendor support – Ability to trace transaction flow and use logging facilities for problem solving – Ability to effectively communicate discovery (CMDB population) results and capabilities to management

3. Mapping Manager

The CMDB Mapping Manager is a technical IT position, but less technical and more applications- and business-focused than the other two CMDB areas. The major skill levels and areas required for the CMDB Mapping Manager are:

 Business: – Understanding of internal organization structure, LOBs – Intimate knowledge of organization’s management structure, formal and informal political processes, lateral flow of knowledge and power within and between business units – How to find and use specific resources within the organization – Ability to create a structure and execution process for application mapping that complies with and is effective within their company – Ability to manage a team of application mapping specialists  Presentation and Communications: – Ability to work with management and technical people of all management levels and skill sets – Persuasive speaking, ability to “sell” CMDB throughout the organization – Ability to present application mapping requirements and results to Application and IT Management  Application: – Intimate understanding of the company’s business services, applications and IT infrastructure – Good understanding of older as well as modern application architectures; 2- and 3- tier applications, OSI model of layers

32 – Basic Understanding of application tiers, platforms and up/down stream dependencies – Ability to interface with application SMEs: to communicate requirements, understand answers and interpret those answers into the appropriate application mapping tasks

33 C. Appendix 3 – Current CMDB Vendors For reference purposes, here are the current CMDB players in alphabetic order.

 BMC Atrium, Marimba  Computer Associates purchased from Cendura  EMC Smarts Application Discovery Manager purchased from nLayers  HP uCMDB purchased from Mercury who purchased Appilog  IBM CCDM purchased from Collation  Microsoft, a neophyte CMDB in their Service Center product  Tideway  Symantec purchased from Relicore

1. Product Weaknesses to Avoid

 Agent-based technology on Solaris, AIX or Windows 2K for limited versions)  No ability to map network devices  Cannot map DB, .Net or J2EE application components  No ability to detect changes to Configuration Parameters stored in DB  No ability to detect application intra-dependencies  Immature product  Discovers only J2EE App Servers  Limited Network service discovery (LDAP, NFS & DNS)  CMDB is mainly a SDK and each installation is a custom development  No discovery engine  Rely on third-party events to build topology  Only supports Oracle or MS SQL as database  Multiple products required to achieve complete Application Mapping Solution  Application discovery based on network traffic fingerprinting  Combination of non-integrated products  No integration services  Poor visualization and mapping  No event management, alerting or notifications  Can’t add custom discovery patterns