Awell-designed configuration management

A

well-designed configuration manage-ment database (CMDB) can provide business value in multiple ways. Many organizations deploy a CMDB not only to enable configuration, change, and release manage--ment, but also to facilitate more effective IT asset management (ITAM) and cost controls. In this article, I’ll walk you through nine steps to achieving additional business value from your CMDB by leveraging it as the foundation for effective asset management. Figure 1 out--lines the steps.

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 owner-ship (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 ele-ments as a CMDB. By designing your CMDB to include asset data in addition to configu--ration data, the CMDB can be leveraged by multiple IT service processes and can be used to control the TCO for assets, delivering addi--tional 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 mul-tiple 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 de--pendent IT service management processes,

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 steps to successfully scope and manage

the asset management aspects of a CMDB initiative.

By julIE MANIS

7

1

4

step step step

2

8

5

step step step

3

6

9

step step step Define the purpose of the CMDB Identify all stakeholders and create a CMDB reference group

Define the role of the CMDB in IT service management Define the scope for configuration items and assets and the differences

between them

Define functional requirements

Create a strategy for the

CMDB

Start small, think big for design and implementation Consider tool overlap and organizational gaps Remember critical plan functions

Figure 1. Steps for a Successful CMDB

Facilitating Effective IT Asset Management

with the CMDB: A Nine-Step Approach

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 service-level 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 configu--ration 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 refe-rence 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 ser--vice management groups such as the serser--vice 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 in--formation 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 com--pliance. 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 stake--holders to determine what data needs to be collected to identify, track, and control the con--figuration lifecycle. CIs may vary widely and may include hardware, software, and

docu--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 defini--tion of either what goes in the CMDB or what information needs to be accessible via feder--ated data stores. In addition to configuration data, ITAM would also want to record asset data such as contract, location, and other in--formation 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 con--tention between operational support groups and ITAM and finance groups. Figure 2 details the differences.

Figure 2. Differences Between Asset Management and Configuration Management

Asset Management Configuration Management

Goals: Manage asset costs, contracts, and usage/

ownership throughout lifecycles Goals: Provide logical model of IT environment as basis for ITIL processes

Value: Lower asset TCO/acquisition costs, reduced

purchasing, more efficient allocation, more accurate budgeting/planning

Value: Greater business service stability, availability,

quality (via related ITIL processes)

Asset: Physical IT component tracked based on

value, contractual compliance CI: Physical or logical IT component managed for its operational impact

Type: A CI can be an asset if it is worth tracking for

cost, contract, and usage Type: An asset can be a CI if it is worth managing for operational stability

Differences: Assets not likely to be managed as CIs

include monitors, printers, servers in inventory Differences: CIs not likely to be managed as assets include a custom Java component, a process, a service model

Relationships: Basic relationships (peer, parent, child)

between assets are maintained for retirement process, ownership, license matching

Relationships: Sophisticated relationships between

CIs are maintained to assess change risk, analyze root cause, assess service impact

Both configuration management and ITAM can leverage a single CMDB. For the implementa-tion 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 relation-ships 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 me-thod for reconciling physical inventory data with financial records; in other words, com--paring 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, con-sider 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 busi--ness processes into a single, virtual resource that can enable all aspects of service support as well as provide a foundation for service delivery.

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?

Figure 3. Closed-Loop and Operational Approaches

ITIL Closed-Loop CMDB Approach Operational CMDB Approach

Maintains the expected state; what is supposed to be in the environment based on standards and fi--nancial records

Maintains the actual state or physical representa--tion of what is actually discovered in the environ--ment

Tightly integrated with incident, problem, and change management, plus other IT service man--agement domains per ITIL recommendations

Loosely integrated to incident, problem, and change management

Compares content with expected state and takes

actions based on defined business rules Pushes out expected state to servers and infra--structure Key to achieving ITIL/BS15000 accreditation Often business unit-based vs. enterprise-focused

For effective asset management, you need

a me thod for reconciling physical inventory

data with financial records.

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 opera--tional 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 dic--tionary, so all stakeholders interpret terms and the approach in the same way. Figure 3 high--lights 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 ven--dor strategies, and greater adoption of ITIL. Federated or unified model. The two basic mo-dels for the structure of the CMDB are a feder--ated model and a unified model. A federfeder--ated model is a centralized database linked to other data stores. A federated model helps you avoid the high setup and maintenance costs associ--ated with the pure centralized approach. The alternative, a unified model, stores all CMDB data in a single, unified data structure. A uni--fied 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 approa-ch 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 ap-propriate 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 in--ventory 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 organi-zation, 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 exam--ple, 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 imple-mented 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 comprehen-sive 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 strate-gies, training approaches, and the metrics by which success will be evaluated. These elements will set the groundwork for an ef--fective program.

Define the data the CMDB will store, the func--tional 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

julie Manis is an operational lead in asset management for the global architecture and Core Technologg gies group at accenture. She has more than 20 years of experience delive ring highgvalue lifecycle mangg agement solutions, iTil standard process solutions, and enterprise systems management solutions.

ABouT ThE AuThor

Combining asset and CI records in

a federated repository eliminates

duplication of data and lowers the

cost to maintain and manage

multiple data stores.

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 commu-nications program and regularly report solution effectiveness. Ensure and maintain the commitment of operations employees.

Take small steps — don’t try to boil

the ocean.