Awell-designed configuration management

Designing a CMDB that also functions as an asset management repository requires broader definitions of the configuration items included in a traditional CMDB. Follow these s to successfully scope and manage the asset management aspects of a CMDB initiative. By julie manis Awell-designed configuration management database (CMDB) can provide business value in multiple ways. Many organizations deploy a CMDB not only to enable configuration, change, and release managemment, but also to facilitate more effective IT asset management (ITAM) and cost controls. In this article, I ll walk you through nine s to achieving additional business value from your CMDB by leveraging it as the foundation for effective asset management. Figure 1 outllines the s. Step 1 Define the Purpose of the CMDB Start by defining a purpose that relates to your business goals and how the CMDB will add value to the business. The functions the CMDB will serve, the benefits to be derived, and the metrics and measurements of success should be defined and prioritized in the first stage of planning the project. Many organizations initiate an ITAM program to control and manage the total cost of ownership (TCO) for IT assets over their lifecycle. The aim of ITAM is to align technology investments with business objectives to derive optimal value. Additional value can be gained by broa d- ening the scope and purpose of the CMDB to include ITAM functions. A central repository for asset data has many of the same data elements as a CMDB. By designing your CMDB to include asset data in addition to configurration data, the CMDB can be leveraged by multiple IT service processes and can be used to control the TCO for assets, delivering addittional value to the organization. A traditional CMDB contains information on the relationships between configuration items (CIs). Often, these CIs overlap with or are the same items tracked for cost purposes as assets. CIs can be linked to federated asset-related data such as user and location data, fixed asset value, procurement data, contract and license data, and discovery data from the physical environment. ITAM lifecycle process workflows use these links to asset data to optimize controls around software licenses, leases, warranties, retirement, depreciation, and TCO. Combining asset and CI records in a federated repository eliminates duplication of data and lowers the cost to maintain and manage multiple data stores. Reconciling data sources and keeping asset and configuration data in sync establishes a single, definitive source for asset and configuration data. This single definitive data source can be used to synchronize deppendent IT service management processes, 1 Define the purpose of the CMDB Define the 4 scope for configuration items and assets and the differences between them 7 Start small, think big for design and implementation 2 Identify all stakeholders and create a CMDB reference group 5 Define functional requirements 8 Consider tool overlap and organizational gaps 3 Define the role of the CMDB in IT service management 6 9 Create a strategy for the CMDB Remember critical plan functions Figure 1. Steps for a Successful CMDB

such as linking ITAM and change processes and data, or ITAM and service desk processes and data, etc. A CMDB should depict relationships in more granularity than traditional asset repositories, because it must also provide incident, problem, change, and other IT Infrastructure Library (ITIL ) processes with dependency information. An asset manager can use this data to better roll up individual asset metrics into business servicelevel metrics; for example, the total cost of assets associated with a service such as Web order entry. Step 2 Identify All Stakeholders and Create a CMDB Reference Group The CMDB is a tool that involves many more users and stakeholders than just the configurration management or asset management teams, and it is important that you include the views, concerns, and requirements of other teams in the early stages of the project. After identification of all project stakeholders, a reference group should be formed. The reference group should be made up of representatives of all groups that generate requests for change, members of the ITAM group, and members of other affected IT servvice management groups such as the service desk or problem management team. The size of this group varies by the organization, but remember that the bigger the group, the more communication required. You want to keep this group small enough that you get the infformation you need, yet big enough that you cover all your stakeholders. Team members should include a mix of people junior enough to be involved in the day-to-day work of the organization, as well as process owners and managers who understand the business issues to be addressed by the CMDB implementation. The members should also be prepared to spend a significant amount of time forming the data definition of items in the data model, and should be the people who finally sign off on data loaded into the tool. Step 3 Define the Role of the CMDB in I.T. Service Management When you gather requirements for your CMDB, think about what you want the tool to be able to do in the long term. But also keep in mind the high-priority, urgent needs and make sure that you include those in the early stages. The concept is to start small, but think big. In the near term, your goal may be to create a CMDB that can be used for change, release, and configuration management. You may also want to leverage asset data for the financial controls required for ITAM. In the long term, this combined data can facilitate incident and problem management as well as capacity and availability management. CIs may vary widely and may include hardware, software, and documentation. By prioritizing these needs, you may determine that the organization s top priority and most pressing need is software license management. You would start by populating the CMDB with discovered asset inventory data and software license data to be reconciled for license comppliance. At the beginning the scope would be small, but you would design and plan the CMDB to have the flexibility and extensibility to meet your other requirements over time. The CMDB reference group needs to define how the CMDB will be leveraged by ITAM and all other IT service management processes and set priorities. Step 4 Define the Scope for Configuration Items and Assets and the Differences Between Them You ll need to work with the business stakehholders to determine what data needs to be collected to identify, track, and control the conffiguration lifecycle. CIs may vary widely and may include hardware, software, and docum-

mentation. You also need to create the same definition for asset data and determine what items will be tracked as assets. For an item to be considered a CI, you would ask these types of questions: > Is this item related to a critical business process or application? > Could an unauthorized change to this item have severe consequences? > Are unauthorized changes common to this item or attribute? > Do many people in the environment often need to refer to this information? > Is this information not easily available through other tools (such as dependencies between software items or clustering of servers)? For an item to be tracked as an asset, you would ask these types of questions: > Is this asset being depreciated as a fixed asset? > Are there annual maintenance agreements related to this asset? > Does this item need to be tracked through disposal for EPA compliance? > What software is loaded on this asset? > Do I need to track costs for this item over its complete lifecycle? > Is this asset covered under a software license agreement and does it need to be tracked for compliance? > Could we negotiate lower costs if we knew how many of this type of asset we would purchase next year? When the answer to such questions is yes, then you ll likely want to include that item in the CMDB. If the CMDB will also be used for ITAM, the ITAM group will have a much broader definittion of either what goes in the CMDB or what information needs to be accessible via federaated data stores. In addition to configuration data, ITAM would also want to record asset data such as contract, location, and other infformation that enable the cost tracking and compliance controls. While there is usually significant overlap in what is tracked as a CI and what is tracked as an asset, the distinction is often a point of conttention between operational support groups and ITAM and finance groups. Figure 2 details the differences. Asset Management Goals: Manage asset costs, contracts, and usage/ ownership throughout lifecycles Value: Lower asset TCO/acquisition costs, reduced purchasing, more efficient allocation, more accurate budgeting/planning Asset: Physical IT component tracked based on value, contractual compliance Type: A CI can be an asset if it is worth tracking for cost, contract, and usage Differences: Assets not likely to be managed as CIs include monitors, printers, servers in inventory Relationships: Basic relationships (peer, parent, child) between assets are maintained for retirement process, ownership, license matching Configuration Management Goals: Provide logical model of IT environment as basis for ITIL processes Value: Greater business service stability, availability, quality (via related ITIL processes) CI: Physical or logical IT component managed for its operational impact Type: An asset can be a CI if it is worth managing for operational stability Differences: CIs not likely to be managed as assets include a custom Java component, a process, a service model Relationships: Sophisticated relationships between CIs are maintained to assess change risk, analyze root cause, assess service impact Figure 2. Differences Between Asset Management and Configuration Management

Both configuration management and ITAM can leverage a single CMDB. For the implementation to be successful, however, the requirements for both need to be defined up front and the CMDB must be designed to accommodate the requirements of both functions. After you have identified the necessary CIs and asset attributes, you must determine the depth to which these items will be tracked. Make sure you include enough information to meet the established business requirements without storing unneeded or excess data in the CMDB. Decisions about the depth of CIs and assets should be made for each functional environment and should be based on the level of control required and the level of criticality for each component type. Step 5 Define Functional Requirements Once you have defined what you want to track, you need to establish a method for inventory discovery for both hardware and software across all operating systems. A methodology and tool must be chosen for mapping relationships among the CIs and populating the CMDB. You will need to define what interfaces need to be built to collect contract data, user data, procurement data, and fixed asset data. For effective asset management, you need a method for reconciling physical inventory data with financial records; in other words, compparing what you actually have to what your financial records say you should have. You will need to reconcile CIs that are also assets. These must be related, based on key attributes, and linked in the CMDB. The same exercise must be performed for reconciling inventory information from multiple discovery tools. During the requirements-building phase, consider which processes can be automated, so that you can reduce errors and costs in loading and maintaining the CMDB. Ideally, the CMDB combines configuration, topology, financial, and asset-sensitive information as well as businness processes into a single, virtual resource that can enable all aspects of service support as well as provide a foundation for service delivery. For effective asset management, you need a me thod for reconciling physical inventory data with financial records. Step 6 Create a Strategy for the CMDB After you have defined all your requirements, they must be translated into a high-level strategy and scope. Key considerations include: > What are the key business purposes and problems to be resolved? > What activities and processes must be included? > What are the functional requirements? > What are the key achievements for measuring success? ITIL Closed-Loop CMDB Approach Maintains the expected state; what is supposed to be in the environment based on standards and finnancial records Tightly integrated with incident, problem, and change management, plus other IT service manaagement domains per ITIL recommendations Compares content with expected state and takes actions based on defined business rules Key to achieving ITIL/BS15000 accreditation Operational CMDB Approach Maintains the actual state or physical representattion of what is actually discovered in the environmment Loosely integrated to incident, problem, and change management Pushes out expected state to servers and infrasstructure Often business unit-based vs. enterprise-focused Figure 3. Closed-Loop and Operational Approaches

Closed-loop or operational approach. Your strategy and scope will help determine which approach you use for your CMDB. The two approaches currently used to design a CMDB are the closed-loop approach and the operattional approach. Industry analysts, consultants, and vendors often use the same wording for both approaches, further contributing to the confusion about these approaches. Be sure to agree on a common language and term dicttionary, so all stakeholders interpret terms and the approach in the same way. Figure 3 highllights the characteristics of the two approaches. We expect the best practices from both of these approaches to merge. The closed-loop approach will become the dominant approach, due to greater maturity in discovery and service management software, ITAM and CMDB venddor strategies, and greater adoption of ITIL. Federated or unified model. The two basic models for the structure of the CMDB are a federaated model and a unified model. A federated model is a centralized database linked to other data stores. A federated model helps you avoid the high setup and maintenance costs associaated with the pure centralized approach. The alternative, a unified model, stores all CMDB data in a single, unified data structure. A uniffied model has fewer interfaces to build and maintain, and works well for a CMDB that is not too complex. For most organizations, especially ones that are large or complex, adding ITAM data to the CMDB contributes to the complexity and size of the database, making a unified approach impractical. If you populate the CMDB with all the attributes required for every ITIL process and ITAM, a single data store would quickly become unmanageable. The federated approach allows you to store a subset of critical data for all processes in the CMDB with pointers to data stores for less critical information. Step 7 Start Small, Think Big for Design and Implementation Your design and implementation plan for the CMDB should be based on the big picture or vision established early in the project. However, two goals must be kept separate: > The long-term capabilities of the tool > The immediate, most urgent needs of the business The overall design should focus on meeting the requirements of all the stakeholder groups. But when you plan the actual implementation, focus on the most critical business priorities first and start as small as possible, limiting your scope and the level of detail tracked for configuration items. For example, an appropriate model to start with might be: > Windows Servers name, location, IP number, person, or > Software name, version, publisher, person After the tool has been live for some time, the plan should define a method for expanding the scope on the basis of operational needs. Items should be included only if they support the vision for the project and a prioritized list of requirements. It is important that the tool you use for a CMDB be able to accommodate future growth. If you choose a tool that allows only configuration mapping and later you want to include asset functions, you ll be challenged if the CMDB cannot accommodate items such as contract data. You want to make sure the base structure and functionality of the tool will allow you to expand as you go. Step 8 Consider Tool Overlap and Organizational Gaps Remember that the CMDB is not an inventory tool. It should not just replicate data that is equally well presented through various invventory tools, but should provide additional information, such as:

> Topology mapping and dependencies between critical applications > Tracking data for releases and builds > Ownership in the organization and cost center data > Contract data > Incident management tickets Since a CMDB has interfaces to so many other processes, groups, and activities in the organization, the design and implementation of the CMDB tend to expose a number of problems in an organization. These gaps often include: > Lack of clarity about packaging and software releases (What is a release? How is new software installed on a server?) > Lack of consistent naming standards for hardware > Lack of inventory or discovery tools for all segments of the population > Lack of change management; for example, the process might exist but is not respected > Lack of ownership of hardware; for exampple, assets might have no clear owner or support group Your work plan should allow time to identify and resolve these problems. Step 9 Remember Critical Plan Functions An effective work plan for deploying a CMDB must ensure that the following items are implemented along with tools and processes: > Metrics Establish audits, measures, and metrics to determine the success and quality of the CMDB. > Support Define who will maintain data, manage databases, and audit for quality. > Communication Employ a comprehensive communication plan that identifies who will be impacted by the program, and states the goals of the projects, the benefits to be achieved, and the measures of success. > Training Provide process and tool training for each of the teams using and supporting the CMDB. Training must focus not just on the functionality of the tool but equally on the underlying processes that leverage the CMDB. The Key to Delivering a Successful CMDB Defining value and success up front is the key to successfully delivering a CMDB. Identify the strategic goals of your CMDB. Your strategy should incorporate business purpose, high-level sponsorship, tool and architecture options, operational processes, communication strategies, training approaches, and the metrics by which success will be evaluated. These elements will set the groundwork for an efffective program. Combining asset and CI records in a federated repository eliminates duplication of data and lowers the cost to maintain and manage multiple data stores. Define the data the CMDB will store, the functtional requirements of the CMDB system, your structural approach, and your plan for turning your vision into reality. The effort you put into the beginning of the project will guide you and help you deliver a CMDB that will provide the information required to make effective business decisions creating maximum value. n ABOUT THE AUTHOR Julie Manis is an operational lead in asset management for the Global Architecture and Core Technolog gies group at Accenture. She has more than 20 years of experience delive ring high-value lifecycle manag agement solutions, ITIL standard process solutions, and enterprise systems management solutions. *62544* 5 tips for effective asset management with the cmdb Develop and articulate a clear CMDB strategy linked to business objectives. Ensure overt buy-in from senior leadership. Construct an effective communications program and regularly report solution effectiveness. Ensure and maintain the commitment of operations employees. Take small s don t try to boil the ocean.