CMDB Business Value

A Planning Checklist for CMDB Success

Demystifying Configuration Items

Implementing a CMDB-based IT Service Structure

6 Tips for Managing the “People” Factor

Published by BMC SoftwarePublished by BMC Software

A Compilation of Articles by Industry ExpertsA Compilation of Articles by Industry ExpertsVIEW

POIN

TFocus on: C

MD

B Leadership

VO

LUM

E TWO

About BMC Software

BMC Software helps IT organizations drive greater

business value through better management of

technology. Our industry-leading Business Service

Management solutions ensure that everything IT

does is prioritized according to business impact, so

IT can proactively address business requirements

to lower costs, drive revenue and mitigate risk.

BMC solutions share BMC Atrium™ technologies

to enable IT to manage across the complexity of

diverse systems and processes — from mainframe

to distributed, databases to applications, service

to security. Founded in 1980, BMC has offices

worldwide and fiscal 2005 revenues of more than

$1.46 billion. BMC Software. Activate your business

with the power of IT. For more information, visit

www.bmc.com.

This publication was created by BMC Software.

Focus on CMDB LeadershipFocus on CMDB Leadership

CONTRIBUTORS

We greatly appreciate the contributions of the following people and companies:

Ahmad Abdel-Wahed, MicrosoftAlexandre Avelar, CSC BRASILKia Behnia, BMC SoftwareKevin Behr, IT Process InstituteCharles BetzTom Bishop, BMC SoftwareDavid Chiu, BMO Financial GroupLinda Donovan, BMC SoftwareDennis Drogseth, Enterprise Management AssociatesTroy DuMoulin, Pink ElephantV’Ali Ford, EMSJeff Gibson, VoyenceGene Kim, IT Process InstituteJoe Lord, AliantJulie Manis, AccentureJonathan Markworth, CompuComTim Mason, TRM AssociatesTroy McAlpin, Invoq SystemsJavier Leyva Novoa, Quitze TecnologíaJason Odden, WiproBrady Orand, Column TechnologiesCraig Piercey, AliantFrederieke C.M. Winkler Prins, Service Management PartnersVal Sanford, SinglestepPerry Sellars, Strategic TechnologiesDevesh Sharma, OracleGeorge Spafford, IT Process InstituteSelma Turki, IBMKyle Ward, AliantHans-Heinz Wisotzky, MATERNA GmbH Information & CommunicationBob Worner, BMC Software

Editor-in-Chief: Elaine KornSenior Editor: Leanne BantsariTechnical Editor: Kurt MilneTechnical Reviewers: Brian Emerson, Dave WiltEditorial Team: Wendy Assatourian, Linda Donovan, Elizabeth Ferrarini,

Paul Mangione, Sheila Mangione, Suszi McFaddenCreative Design: Liora Blum Graphic DesignCover Photograph and Design: Della CalfeeCreative Direction: Michele Floriani, Della CalfeeSpecial Thanks: Kim Bigler, Kelly Blice, Kimberly Chihaoui, Michael Cotignola,

Jihad El-Assaad, Karl-Anders Falk, Pierre Germain, Ali Ghazanfari, Jan Hagge, Rhonda Hagstedt, Margaret Henry, Dan Hoffmann, Eric Holliday, Susana Landeira, Maggie McLening, Paul Peissner, Faye Rukstales, Matthew Selheimer, Tanya Solomon, Molly Thiel, Andy Walker

Call 800-841-2031. Learn how BMC Software BSM solutions can help your business.

©2006 BMC Software Inc. All rights reserved.

ACKNOW

LEDGEMEN

TS

Industry luminary Malcolm Fry and a team of experts, including David Chiu, Troy DuMoulin, Brian Emerson, Jeanne Morain, Michael Nicoletti, Maria Ritchie, Michael Os, Angie Massicotte, and Ken Turbitt, will guide you in the forthcoming book, Step-by-Step Guide to Building a CMDB. Filled with best practice examples and practical advice, the book details 25 steps for deliver-ing a CMDB:

1. Obtain CMDB knowledge2. Review and agree on CMDB goals3. Create a CMDB mission statement4. Review and identify governance requirements5. Review and select supporting best practices6. Identify inventory and asset requirements7. Identify and address potential problems8. Review and define benefits9. Final scoping objective and expansion planning10. Define service catalog CMDB requirements11. Define requirements for other processes, including non-ITIL processes12. Define configuration item level — IT service model13. Define configuration item relationships14. Define configuration item attributes15. Design IT model blueprint16. Select technologies for your CMDB17. Calculate and present ROI18. Construct your CMDB19. Create configuration item lifecycle management process

20. Identify and install metrics — KPIs, CSFs, and reporting

21. Build supporting processes

22. Select tool to automate CMDB population

23. Populate your CMDB

24. Train the CMDB configuration management team

25. Create a continuous service improvement program

Malcolm Fry is a recognized IT industry luminary with more than 35 years experience in information technology. He serves as an independent executive advisor to BMC Software. Malcolm is the author of four best-selling books on IT service and support, he has had many articles and papers published, and he is regularly contacted as a source of information by technology journalists. In addition, he is the solo performer in a highly successful, best-selling video and DVD series made for the Help Desk Institute. He is an original contributor to IT Infrastructure Library (ITIL®) and has Masters-level ITIL certification.

The other contributors are respected subject matter experts.Step-by-Step Guide to Building a CMDB is scheduled to be available in Sep-tember 2006. For more information about this book, and to register for a free copy, please go to www.BMC.com/StepByStep.

COMING SOONSTEP-BY-STEP GUIDE TO BUILDING A CMDB

�

05 AMessagefromTomBishopChiefTechnologyOfficer,BMCSoftware

SeCTiOn� PRACTICAL AdvICe foR dePLoYING A CMdB

08 TheiTServiceStructure:insightGainedthroughimplementingaCMDBA CMDB-based service structure can help you accelerate your transition from a tactical, silo-focused IT organization to a more strategic, business-focused powerhouse. Learn from the experience of an organization that did just that. ByDavidChiu

16 ensureCMDBSuccessWithaPlanningChecklistAsk the right questions before you start your large enterprise CMDB implementation, and the project will be much smoother. Use this checklist as a guide.BySelmaTurki

22 FourPracticalStepstoaSuccessfulCMDBimplementationYou can achieve a successful CMDB implementation if you approach it in a methodical way. Here, we provide a view of a CMDB implementation through the eyes of the project managers.ByJoeLord,CraigPiercey,KyleWard

28 AMilestone-BasedApproachtoaRapidCMDBDefinition-to-DeploymentinitiativeYou really can implement a CMDB initiative that achieves both thorough-ness and quick results. This eight-phase approach, each with an accompanying milestone, describes how. ByJasonOdden

36 AdviceforAchievingQuickWinswithYourCMDBimplementationIdentify and achieve quick wins to realize greater success with your CMDB implementation.ByV’AliFord

42 UsingiTiL’sConfigurationManagementActivitiesforCMDBSuccessUse the five ITIL configuration management activities, plus an additional activity developed by Quitze, as the basis to deliver a CMDB that supports the needs of the business. ByJavierLeyvanovoa

50 SixTipsforeffectivelyManagingthe“People”FactorSuccessful implementation and long-term viability depend on how effectively you manage the human aspects of the CMDB. Here are six tips for including the human factor in your CMDB equation. ByTimMason

TABLe of CoNTeN

Ts

Focus on: CMDB LeadershipFocus on: CMDB Leadership

�

56 FiveDesignConsiderationsforaCMDBGet a head start on the most difficult issues of CMDB design by first examining five important topics: configuration items, federated systems, data schema, discovery, and data integration and reconciliation. ByDennisDrogseth

64 AccelerateyourCMDBimplementationwithaBestPracticeProcessModelUsing a best practice process model speeds up the definition phase, which reduces costs and helps you to hit the ground running with your configuration management and CMDB initiatives.ByFrederiekeWinklerPrins

71 People:TheKeytoCrackingtheiTServiceModelCodePeople provide insight to business processes and create a link to the IT infrastructure, helping you develop an accurate service model.ByAlexandreAvelar

74 StartwithServiceDefinitionsandReapSuccessBegin your CMDB initiative by defining the services that IT provides to the business, and increase your chances of success. This article shows you how.ByBradyOrand

80 DemystifyingConfigurationitemsThe configuration item (CI) is one of the most necessary, yet problematic, concepts in IT governance. This article presents a simplified way of categorizing CIs that may be useful in designing, populating, and managing an effective CMDB.ByCharlesBetz

88 MissionPossible:GatheringtheRightDatainYourCMDBtoOptimizeiTServicesAdopting a pragmatic approach to gathering data can help you create an effective CMDB. Use these guidelines to overcome what might, at first, seem like an impossible mission.ByValSanford

96 Services,Software,andHardwareCis:JustlikeanOreoCookie!The CMDB is the cookie jar for the Oreo cookies that represent your business systems. Business services and hardware components are the two chocolate wafers, and software is the filling that holds the wafers together.ByJonathanMarkworth

TABLe of CoNTeN

Ts

�

TABLe of CoNTeN

Ts

SeCTiOn� CAPABILITIes eNABLed BY A CMdB

102ChangeManagement:TheKeytoaPicturePerfectinfrastructureWhen a CMDB is the centerpiece of your change management process, you can more efficiently and accurately change your IT infrastructure to meet business needs. ByHans-HeinzWisotzky

108Rememberthe“CM”inCMDBThe CMDB is more than a static repository of information. It is an integral part of the configuration management (CM) process, providing the foundation for other IT processes that enable the delivery of business services. When you start your CMDB project, make sure CM is part of the equation.ByPerrySellars

116FacilitatingeffectiveiTAssetManagementwiththeCMDB:Anine-StepApproachDesigning a CMDB that also functions as an asset 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.ByJulieManis

124CMDBBusinessValueUnfortunately, IT decisions are not always made based on a high standard of data integrity. Perhaps this is because many people are unaware of the power of a CMDB.ByKiaBehnia

128LeveragingidentityinformationThroughtheCMDBBy leveraging identity management, you can achieve a comprehensive, accurate, and up-to-date source of people information for the CMDB.ByAhmadAbdel-Wahed,BobWorner

134CMDB:TheKeytoJump-StartingiTiLSuccessThree experts discuss the Visible Ops methodology, which offers a simple approach to implementing ITIL in four practical steps. In this methodology, the CMDB is a key factor in driving quick wins.ByKevinBehr,GeneKim,GeorgeSpafford

142CMDB:TheResortCondominiumforiTJust as a resort condominium can streamline a housing complex, the CMDB can improve access to data about IT application and infrastructure components. The result is a better ability to break down organizational silos and provide end-to-end service management.ByTroyDuMoulin

150Don’tForgetthenetworkFollow a three-step approach for populating the CMDB with network data and using purpose-built network configuration management tools for a successful CMDB initiative.ByJeffGibson

156CanPeopleBeConfigurationitems?Get more out of your CMDB and stream-line your IT service support by maintaining a dynamic repository of information about the people involved in, and affected by, the incident management process.ByTroyMcAlpin

�

160UsingBPeL,BSM,andtheCMDBtoManageiTfromtheBusinessPerspectiveWhen CMDB information links a BPEL-designed business process to Web Services and underlying IT services, you can drama-tically improve the alignment of IT with the goals of the business.ByDeveshSharma

POSTSCRiPT164Dr.Henry

CMDB implementations keeping you up at night? Just ask Dr. Henry…ByLindaDonovan

TABLe of CoNTeN

Ts

Welcome to the second edition of VIEWPOINT. Our first edition

focused on the value of a configura--tion management database (CMDB) and provided expert advice on how to achieve a successful CMDB imple--mentation. We received a very posi--tive response to the first edition and our readers have asked for more. In addition, companies are embracing the CMDB at a tremendous rate, and as a result, we bring you this second edition, which again includes a broad range of articles from BMC customers, partners, and industry experts.

This publication has two sections. Section One, “Practical Advice for Deploying a CMDB,” is designed to help organizations jump-start their implementations, make the process a smooth one, and get the most value out of it. In our lead article, David Chiu of BMO Financial Group talks about how you can use a CMDB-based service structure to accelerate your transition to a strategic, business-focused IT organization.

Selma Turki of IBM identifies the ques--tions to ask before you start a large enterprise CMDB implementation and provides a checklist that you can use as a guide. Alexandre Avelar of CSC BRASIL discusses how people are the key to cracking the IT service model code. Additional articles in this section include design recommend-ations, incorporating best practices from the IT Infrastructure Library (ITIL®), and a variety of other guide--lines for success.

Section Two, “Capabilities Enabled by a CMDB,” includes a number of articles describing the capabilities the CMDB facilitates. For example, Julie Manis of Accenture discusses a nine-step approach for using the CMDB to facilitate effective IT asset management. Perry Sellars of Stra--tegic Technologies explains how the CMDB is an integral part of the configuration management (CM) process, providing the foundation for other IT processes that enable the delivery of business services.

Be sure to read the article by Devesh Sharma of Oracle, which discusses using Business Process Execution Language (BPEL), BSM, and the CMDB to manage IT from the busi--ness perspective. Section Two also includes articles providing insight into such areas as the benefit of categorizing people as configuration items in the CMDB, using the CMDB to jump-start ITIL implementations, and other compelling topics.

Although I’ve just mentioned a hand--ful of articles above, this edition of VIEWPOINT contains many other interesting and informative articles. I’d like to personally thank all of the contributors for helping to make this book practical, educational, and use--ful. As you can see from the breadth of companies contributing articles to this edition, the CMDB has truly become an industry phenomenon, and we look forward to future con--tributions from many of you now reading this.

You may also be interested to know the CMDB has become such an im--portant resource that BMC and several other leading companies have joined together to create a new interoper--ability specification designed to enable customers to federate and access information from their complex, multi-vendor IT infrastructures. Working together, we will develop an open, industry-wide specification for sharing information between CMDBs and other data repositories. We plan to submit a draft specification to an industry standards organization later this year.

Best regards, and good luck on those CMDB implementations,

Tom BishopChief Technology Officer, BMC Software

ABOUTTOMBiSHOPTom Bishop was named one of the top 25 CTOs by InfoWorld Magazine in 2004. A well-known technology innovator, he holds nine patents in fault tolerant computing and has been involved in leading the develop-ment of industry standards such as the Distributed Management Task Force (DMTF) and POSIX. For more than 20 years, he has served in senior technology and strategy roles at lead--ing organizations including UNIX International, Tandem Computers, and CompuCare Management Sys--tems. Tom was an early employee of Tivoli Systems and rose quickly through the organization, serving first in key development roles before being named Chief Technology Officer and General Manager for IBM Tivoli’s Embedded Solutions business unit.

AMeSSAGeFROMTOMBiSHOPChIef TeChNoLoGY offICeR, BMC sofTwARe

�

�

PRACTICA

L Ad

vICe fo

R dePLo

YING

A CM

dB

�

“The power of a CMDB lies in its ability to provide a structured way to identify the relationships between IT resources, also known as CIs, and the business functions they support.”

—DavidChiu,BMOFinancialGroup

“A CMDB cannot be built in isolation. It is at the heart of the ITIL framework and is what keeps ITIL best practices alive and kicking.”

—SelmaTurki,iBM

“The CMDB is enabling us to deliver improved service and availability to the business that depends on us.”

—JoeLord,CraigPiercey,andKyleWard,Aliant

“The key is to prioritize and start with those processes that have the greatest expected improvement from integration with the CMDB.”

—JasonOdden,Wipro

“Achieving a quick win can help you establish greater efficiencies and increase your pace toward reaching your ultimate CMDB goal.”

—V’AliFord,eMS

“Providing accurate and consistent information about CIs and their relevance to the business ultimately will enable the business to meet its goals.”

—JavierLeyvanovoa,QuitzeTecnologia

“To a large degree, successful implemen-tation and long-term viability depend on how effectively you manage the human aspects of the CMDB.”

—TimMason,TRMAssociates

“Your CMDB can significantly empower your organization — once it is a consistent, dynamic and trusted data source.”

—DennisDrogseth,enterpriseManagementAssociates

“A best practice process model is a time-saving and money-saving shortcut to successful service management.”

—FrederiekeC.M.WinklerPrins,ServiceManagementPartners

“The people in your enterprise are the key to creating business relevance and cracking the service model code.”

—AlexandreAvelar,CSCBRASiL

“Start with a critical business service and then build out the service model or the dependencies within the CMDB that go behind that service.”

—BradyOrand,ColumnTechnologies

“CIs have differing levels of involvement in day-to-day service management and production processes.”

—CharlesBetz

“The ultimate goal of any CMDB imple-mentation is to utilize the data in a way that optimizes your organization’s IT infrastructure and decision-making capabilities, and thus optimizes the services you provide to the business.”

—ValSanford,Singlestep

“A CMDB implementation is successful when all interested parties consider your CMDB the single source of truth for the IT infrastructure.”

—JonathanMarkworth,CompuCom

SeCTiOn�PRACTICAL AdvICe foR dePLoYING A CMdB

����

����

�8

��

��

�0

��

80

88

9�

8 ��

8

aCMDB

ACMDB-basedservicestructurecanhelpyouaccelerateyourtransition

fromatactical,silo-focusediTorganizationtoamorestrategic,business-focusedpowerhouse.Learnfromtheexperienceofanorganizationthatdidjustthat.

ByDAViDCHiU

INsIGhT GAINedThRouGh

IMPLeMeNTING

THei.T.SeRViCeSTRUCTURe:

9

�0

The power of a configuration manage--ment database (CMDB) lies in its ability to provide a structured way to identify

the relationship between IT resources, also known as configuration items (CIs), and the business functions they support. By consoli--dating and structuring the data with information about various types of CI relationships and dependencies, you can create a structured representation of IT that enables a broad range of service management capabilities that are otherwise not possible. The relationship infor--mation that is stored in the CMDB provides a common language and awareness that allows you to manage IT from a business perspective. The concepts and practices enabled by an IT service structure are powerful and drive bottom line value both within IT and to the business.

As your IT organization increases its maturity level of IT service management practices, you reach a point where further increases in service levels are not feasible without a way to identify and communicate dependency relationships. If you can’t identify the link between the service you deliver and the people, processes, appli--cations, servers, databases, and networks that enable that service, you really can’t manage and deliver IT services with the level of quality the business expects. You must transition from managing IT resources in technology silos to managing them in the context of a broad ser--vice picture. An IT service structure enables this powerful leap forward in capability.

This article shares insight gained through im-plementing a CMDB-based service structure at BMO Financial Group, and shows you how to leverage the CI relationships managed by a CMDB to build an IT service structure that will help you accelerate your transition from a tactical, silo-focused IT organization to a more strategic, business-focused powerhouse.

The goal is to help you understand a whole new set of questions and the broad range of powerful new capabilities that emerge when you see the pieces of the IT infrastructure, people, and processes as a collective whole.

seRvICe MANAGeMeNT evoLuTIoNLet’s start with the obvious. IT has become very complex. It is impossible for one individual to understand how everything works together. It’s difficult to determine how a business trans--action flows across the IT infrastructure, and complicated to figure out how different tech--nology components depend on each other. If you’ve ever been involved in a data center consolidation, you know how hard it is to pre--dict the impact of pulling the plug on a server and moving it to a new location.

Now combine that increased complexity with an ever-increasing set of expectations from the clients and users of IT within your organization, and you have a recipe for high expectations that are more and more difficult to meet.

To more effectively manage the complexity, and to better meet the expectations of the users, you first need to recognize that you have to start managing IT as a service. But moving toward managing IT as a service is complex. You also need a parallel transition in tools and infor-mation to manage IT from a new perspective.It’s easier to make this transition if you develop a way to structure data about the IT infrastruc-ture and its relationships. The first step is to

create an accurate inventory of the pieces of your IT infrastructure. Then, identify the rela--tionships between those various pieces and the IT services they deliver to the business. Finally, put the people and processes in place to update and maintain that information on an ongoing basis.

Creating this set of structured data gives you an accurate picture and subpictures of various IT systems. This picture of how everything is related and how it fits together to enable the delivery of IT services is your IT service structure.

You must transition from managing IT resources in technology silos to managing them in the context of a broad service picture.

��

This IT service structure opens up a whole new set of possibilities in managing IT.

With the IT service structure in place, you can relate IT resources to the business and manage them from a business perspective. How? By “walking the structure.” Analyze and use information in the CMDB to answer key busi--ness questions such as:

What is the real cost of delivering a business service — not just the cost of the technology assets that provide the service, but also the associated support and maintenance costs absorbed by the IT organization? What is the impact of an IT failure, change implementation, or other infrastructure event on the delivery of business services?What is the capacity of technology assets required to support a particular business service today and in the future, and what is the current capacity utilization of that service?What is the quality of a particular business service provided by IT with respect to such factors as availability, reliability, perfor--mance, and incidents reported by users?

By answering these questions, you can gain insight that will enable you to better align IT with your business goals.

defINING The sTRuCTuReYou’ll need to really think through your IT service structure to portray the highly complex IT environment in a form that can be easily managed and communicated to a business audience. Creating such a structure in the CMDB involves:

>

>

>

>

Establishing CIs Defining the hierarchical relationships among the CIsDefining the functional relationships among the CIs

A graphical representation of a generic IT service structure is illustrated in Figure 1.

Establishing CIs. The CMDB is vital if you are implementing IT Infrastructure Library (ITIL®) best practices, because it provides a centralized access point for a wealth of information about all IT resources (or CIs). CIs are physical assets such as servers, PCs, and network equipment, as well as logical assets such as software, documentation, and contracts. CIs can also be attribute information such as the configuration, cost, and location of hardware CIs. An important aspect of the CMDB is that it provides a single source of truth that all ITIL processes can share. Consequently, the CMDB provides a point of integration across IT service management processes — integration that is essential for a successful ITIL implementation.

You may have already established your tech--nology assets as CIs in a CMDB. To have a com--plete picture, however, you should include additional CIs depicting other vital IT resources, such as people and services. Technical support and change implementation personnel provide IT services, making it essential that, in addition to hardware and software, you include people in the definition of the IT service structure.

>>

>

��

An important aspect of the CMDB is that it provides a single source of truth that all ITIL processes can share.

One way to incorporate people into the struc-ture is to create CIs that define human roles in the delivery of IT services — for example, an application support group that provides second-level support for a particular set of applications. Including people in the structure delivers real business value because it provides better visibility into costs. This enables you to calculate the total cost of providing a particular business service, including not only the acqui--sition and implementation of technical assets that provide the service, but also the costs associated with maintaining those assets and supporting the people who use the service.

Another distinct entity that you must account for in the structure is an event, such as a service failure or scheduled maintenance. Events can be represented by service records that are es-tablished as CIs. The service records not only

specify events but also tie the events to specific IT technology assets, permitting you to examine such factors as service quality over time.

Establishing hierarchical relationships. Once the CIs have been established, you can group them by their hierarchical relationships. You can use hierarchical relationships to describe the decomposition of an aggregate into its subsets. Take care in determining the degree of granularity here. Too much granularity creates unnecessary data volume and complexity, hampering analysis. Too little granularity limits the scope of analysis.

Any given service can include the following technical elements:

Platform and platform devicesSoftwareDatabase

>>>

Figure 1. IT Service Structure

One way to incorporate people into the structure is to create CIs that define human roles in the delivery of IT services.

Connected to

Uses

/ Us

ed B

y

Used By

Uses

Uses

/ Us

ed B

y

Connected to

Runs on (Installed on) Runs (Contains)

Runs (Contains)

Member of / Consists of Member of / Consists of

Governs Governs Governs Governed by

Conn

ecte

d to

Data

Exc

hang

e

CreatesDatafeed

ReceivesDatafeed

Back

s up

/ Ba

cked

up

by

Conn

ecte

d to

Uses

/ Us

ed B

y

Runs

on

/ Run

s

System

Name: <xyz>

SERVICE

Technology

Name: [System] + Technology

SYSTEM

TECHNOLOGY

PLATFORM DEVICE PLATFORM NETWORK DEVICE SOFTWARE DOCUMENTNETWORK

Image

SOFTWARE DATABASE FACILITY

TECHNOLOGY TECHNOLOGY TECHNOLOGY

Software

Name: [System] + Software

TECHNOLOGY

Database

Name: [System] + Database

TECHNOLOGY

Document

Name: [System] + Document

TECHNOLOGY

Facility

Name: [System] + Facility

TECHNOLOGY

Logi

cal C

Is

Subs

yste

ms

Syst

ems

Serv

ices

Phys

ical

/ Vi

rtua

l CIs

��

Network and network devicesDocumentationFacilities

Establishing functional relationships. The next step is to establish the functional relationships and interdependencies among CIs, including:

The physical relationships, such as which servers connect to which network nodes or which applications run on which serversThe logical relationships, such as which virtual servers are hosted on which physi--cal serversThe relationships of the technology assets to the business services they support; for example, the IT infrastructure components that support an online bill payment service

In this step, a major issue that you’ll need to address is controlling the number and comple xity of functional relationships to be defined and managed. The situation is similar to the com--plex relationships among people. Some are familial or social, while others are health related or service oriented. The list is long and varied. When people discuss relationships, however, they typically do so in a particular context that narrows the relationships to be considered. For example, in the context of patient admission to a hospital, only health-related and familial relationships are relevant.

Likewise, in the world of IT, the context de--termines the type of relationships that are of interest to you. Consider an example in which a server failure occurs. If you’re the technician troubleshooting the problem, you may be in--terested in the physical and logical relationships of the server to other technology assets. If you’re service desk personnel, on the other hand, you probably are interested in the relationships between the failed server and the business services it supports.

>>>

>

>

>

Including people in the structure delivers real business value because it provides better visibility into costs.

��

Categorization enables you to deal with the volume and complexity of relationships and present data in a straightforward, understand--able manner. You only look at the relationship types that are of interest to you. To categorize relationships by type, you need an IT service structure that provides a formal method to define and name relationship types. For ex--ample, the term “runs on” may be established to define a type of relationship between an application and a server. Conversely, the term “run” defines the relationship between a server and an application.

The PAYoffWith the IT service structure defined and main--tained in the CMDB, you have a comprehensive, manageable, and easily accessible source of information about IT resources, which creates more efficient and effective IT processes. The service structure provides a “book of record” of all dependencies. That enables a real under--standing of the picture of the IT systems as a whole. With that information, the possibilities of improving basic IT functions are exciting, and they are virtually limitless. Here are just a few examples of how you can use the IT service structure to improve existing processes and functions:

Service costing — It is nearly impossible to determine the cost of services if you can’t roll up the costs of underlying IT compo--nents related to particular services. With a service structure, you can calculate the total cost of delivering a particular service that IT provides, including not only the ope-rating cost of the technology assets, but also the associated maintenance and support costs as indicated by the service records.Service restoration — When a server fails, restoration of service is difficult unless you

>

>

know what infrastructure components are dependent on that server. With a service structure, you can determine all business services supported by the server and quickly notify the users affected by the problem, informing them of any known workarounds and advising them of what to expect in terms of problem resolution.Incident management — Incident manage--ment often becomes complicated when multiple incidents simultaneously are sub--mitted to the service desk. With a service structure, you can quickly and easily prio-ritize responses based on business impact, facilitating the most efficient use of limited IT resources. Problem management — Without a service structure, much of your time spent on prob--lem management is determining the cause of the failure. With a service structure in place, you can quickly determine which systems are impacted, along with any recent changes to all related systems, signi-ficantly reducing the time spent on root cause analysis.Change impact management — Change impact management is most effective when it includes analysis of the impact of a change on upstream and downstream systems. With a service structure in place, you can easily analyze each change request to identify the business systems that will be affected by a planned infrastructure change, ensuring that you can execute the change with minimal or no business disruption.

With a service structure, you can quickly and easily prioritize responses based on business impact.

>

>

>

5TiPSFORiMPLeMenTinGACMDB

Capacity management — Capacity manage--ment is typically done at the infrastructure component level. With a service structure in place, you can conduct capacity man--agement at the service level. Capacity for a service can be planned, monitored, and managed. You can have a holistic view of all the components that make up the service. A capacity index number can be calculated and monitored for the whole instead of via each component.Service level management — Service level management is difficult if you don’t con--sider the combined performance of all components that deliver the service. If five major components contribute to the proper function of a critical business application, the combined service level is dependent on each of those components. With a ser--vice structure in place, end-to-end service management can include nested service levels, as related to the overall service level agreement, for each component.

RedefINe The RoLe of I.T.If you don’t have a service structure, you won’t have a standard way of representing the picture as a whole. With a service structure, you can quickly gauge the delivery quality of a parti-cular business service and determine where improvements are required, ensuring the continuing delivery of business services at agreed-upon levels. With the ability to perform these functions, you can redefine the role of IT from managing technology to maximizing the value contribution of IT resources to the busi--ness of the enterprise. Bottom line: IT no longer just supports business operations; it becomes a key player in advancing business goals. n

>

>

DavidChiuis a senior business tech­nology specialist at BMo financial Group. david was one of the pro­­cess architects for many of the ITIL processes implemented in BMo during the last five years, including release, change, configuration, and service level management. he now provides leadership and subject

matter expertise for the continual improvement of the established ITIL processes through the use of statistical process control techniques and other quality improvement methodology. david won “Best ITIL Case study” awards at the 7th and 8th Annual International IT service Management Conferences. he is also a con­tributing author for hdI’s book, Implementing Service and Support Management Processes: A Practical Guide.

ABOUTTHeAUTHOR

Establish techno logy CIs in the CMDB, including physical assets (servers, PCs, network equip ment), logical assets (software, documen tation, contracts) and attribute infor mation (configuration, cost, and location of hardware CIs).

Group CIs by their hierarchical relation--ships, and carefully

determine the degree of granularity.

Include events, such as a service failure or scheduled main-

tenance, in the CMDB. Events can be repre--

sented by service records that are

established as CIs.

Incorporate people into the CMDB by

creating CIs that define human roles in the

delivery of IT services.

Control the number and complexity

of functional relationships to be

defined and managed.

��

Ask the right questions before you start your CMdB, and your implementation will be smoother. Usethischecklistasaguide.

BySeLMATURKi

CMDBSUCCeSSwithaPlanningChecklistensure

��

If you are thinking about implementing a configuration management database (CMDB), you are probably wondering,

“How do I get started in a way that will en--sure success?” The answer is, “By asking the right questions up front.” In particular, for large, geographically dispersed organiza--tions, it’s better to undergo rigorous planning up front. Spending time at the outset to obtain buy-in from the project’s multiple stakeholders, as well as to attain consensus on approach, will save you time and headaches in the long run.

As an IT architect responsible for service management and asset management imple--mentations for IBM clients, I have assisted a number of organizations in implementing a CMDB. Over time, I’ve developed a set of questions that help uncover the right infor--mation before an IBM team begins a CMDB engagement. Posing these questions to our clients drives up our success rate because the questions encourage clients to think about requirements and help set expectations for the project. The answers to these questions help us avoid surprises as we travel down the road toward a CMDB. Asking these questions also assists us in staying within the client’s schedule and budget.

If you are looking to implement a CMDB, you need to understand that building a successful CMDB takes time. You have to use a rigorous methodology and have a strong commitment if you’re going to incorporate all relevant IT components into a consolidated CMDB. The

IT Infrastructure Library (ITIL®) framework serves as an excellent guide.

For large, geographically dispersed organizations, it’s better to undergo rigorous planning upfront.

Below, I will present in a checklist format the set of questions that you should ask before you start your CMDB implementation. The goal is to help you get all potential issues on the table so you can prepare for any obstacles that may arise, and accelerate your progress toward a fully functional CMDB.

defINING sCoPeImplementing a CMDB is an ambitious effort. Ambition is a good thing, but it needs to be tempered with an understanding that, in large environments, a phased approach will probably be best. You have to consider not only the over--all scope, but also your short-term, midterm, and long-term view and vision. The following questions will help: > Are we going to build a single CMDB for the

entire enterprise or one for each data center? > How can we maintain existing data sources,

if appropriate, and how can we eliminate the need for sources that must be main--tained manually?

> How should we approach, review, and analyze the many disparate data sources that are collecting configuration item (CI) data throughout the enterprise?

�8

> What is the scope of the existing service desk? Will it be expanded?

> What is the scope of the existing change process, if any?

> Which service level agreements (SLAs) do we want to implement?

> Should we start with the most willing department or the most reluctant one?

> Which data source will become master and which will become slaves?

> Should we incorporate only those com--ponents that are the most expensive to maintain and support, or should we follow financial rules and guidelines?

> Should we limit the CMDB to only those components involved in supporting the most critical business applications?

> Should we try to map CIs based on busi--ness impact from the start or save this effort for a future project?

> Should we take over all elements that will be part of an automated update procedure up front or leave them for a second phase? (Keep in mind that incorporating them into an automated process may mean building an integration point.)

People, processes, technology, and information all come into play in the CMDB.

When I asked an executive at a major tele--communications company about how much of the enterprise he wanted to address with the CMDB, he initially drew out a large and complex organizational chart. As we went through the scoping questions, he began to see he needed a realistic rollout plan. We talked about which groups would be reluctant to embrace the CMDB and which groups already had tools and processes in place.

When we sat down again a week later, the executive had identified three groups for a phased implementation. The first group was the one least likely to resist the CMDB and that had the most to gain. We consolidated five or

six existing databases, put processes in place, and demonstrated success within about three months. This initial phase paved the way for a successful rollout to the other two groups, each of which took about three months.

This executive’s decision to start with a group most willing and enthusiastic was based on his insight into the nature of his enterprise. The opposite approach can work equally well in some organizations because demonstrating success in a reluctant group can have a sig--nificant impact on getting others to buy in.

CoRReLATING PeoPLe, PRoCesses, TeChNoLoGY, ANd INfoRMATIoN People, processes, technology, and informa--tion all come into play in the CMDB. For that reason, I find that adopting a model and approach correlated to all four — and reflect--ing that model in your plan — will increase your success rate. I’ve proven this in many engagements. Here are the questions I ask:> What are the processes behind the CMDB?> Which kind of actions and/or processes

will keep the CMDB alive and relevant?> Which components and their related

attributes are used by the service desk, the analysts, the change managers, and existing SLAs?

> Who are the main players, stakeholders, and users of the different processes — in particular, those around configuration management?

> Which SLAs do you already have in place or want to implement?

> Which changes will you be managing and tracking in the CMDB?

> Is your organization ready from a role/profile perspective?

> Have you thought about the people impact of implementing an ITIL process-based ap--proach? (People will either have more or less to do, depending on the situation.)

> Have you explained to those affected how their job and role will change as a result of the CMDB implementation?

�9

> Have you thought about the technology aspect? Technology is also important, considering that it needs to be acquired, mastered, and maintained.

Reducing the number of data sources is an essential step.

One of our government clients was outsourc--ing its IT function, but wanted to bring the effort back in-house. The organization had nothing in place — no staff, no processes, no tools. The client was working on ISO certi--fication, so a process-driven approach with proven processes and supporting technology was important. Our adopted approach, which focuses on people, processes, information, and technology, was the perfect match. It helped the agency structure the organization, hire the right people, put best practices in place, train staff, and identify data needs and re--porting requirements.

LIMITING The NuMBeR of dATA souRCesWhen enterprises start looking at the amount of data that various individuals and groups are keeping, they are often overwhelmed. The reality is that much of this information doesn’t belong in a CMDB. Moreover, there’s a lot of duplicate and redundant information. If you don’t whittle it down before you begin build--ing your central repository, you’ll end up with a CMDB that is large and unwieldy.

It takes a lot of time and effort to examine the data and determine what data should go and what should stay, but reducing the number of data sources is an essential step. Here are a few questions that will help you identify the right information, so that you end up with a CMDB that is relevant, accurate, consistent, and business driven:> What processes will be integrated with

the CMDB? Change management? Asset management?

> Which CIs are needed by those processes? > Who will be using these CIs as part of their

normal activities?> Do CIs need to be physically consolidated

into the CMDB or could/will they be seen through a federated view?

> How will existing CIs be integrated? Through a complete move or by using an integration point into the target CMDB?

> Are the CIs part of any SLAs? > Have CI relationships been created?

If so, how? Do these relationships need to be maintained?

One of our clients, a company that had gone through a number of mergers and acquisitions, found that it had nearly 65 different databases scattered among various groups. The company was trying to consolidate several business applications and infrastructure components to achieve greater efficiency and reduce costs. We explained that they needed to closely ex--amine all the data sources, check the relevance of each one, and determine which ones were within the scope of the CMDB and which ones were not.

The effort delayed the CMDB project for nearly a year. Was it worth it? Absolutely. Without this effort, obstacles would have materialized at every step. It would have cost the company much more in terms of time, money, and ef--fort because it would have been necessary to build integration points to all the disparate data sources. Maintaining those integration points would have been a major headache. Instead, the various groups weeded out un--necessary data, consolidated where they could, and ultimately ended up with six data sources that were relevant to the CMDB.

�0

sTRoNG LeAdeRshIP ANd ITIL exPeRTIse Strong leadership is essential, not only in the client organization but also from the external consulting team. Moreover, the stronger the ties between the teams, the more effective they become at driving the project forward and keeping the key stakeholders involved and motivated. Strong leadership drives the project ahead despite obstacles, political is--sues, and resistance to change. Without strong leadership, you can count on delays, cost overruns, and a high risk of failure.

A CMDB cannot be built in isolation. It is at the heart of the ITIL framework and is what keeps ITIL best practices alive and kicking. That makes a keen knowledge of ITIL ex--tremely important — because ITIL provides the framework for efficient service support and delivery.

Questions aren’t really applicable in this case, so I’m listing several important characteristics of a strong leader and some thoughts on what is expected of someone in this role:> Has the confidence and support of senior

management and the respect of peers> Demonstrates leadership abilities in

other projects> Displays good listening and

negotiating skills> Is knowledgeable in multiple IT service

management disciplines> Possesses a good working knowledge

of ITIL guidelines> Has a solid understanding of the business

drivers and requirements

The client featured in the previous section had enormous obstacles to overcome. Mergers and acquisitions had resulted in a complex environment. Political issues sometimes made reaching agreement a grueling task. People felt ownership in their own data and processes. It took a strong leader to bring everyone together and ultimately reduce the number of data

sources to a manageable number and create a CMDB that delivers value to the business.

CommunicatingforBuy-inandCommitmentCommunication is vital at every step of the project, from early planning through piloting and rollout. Communication helps people understand the “why” and the “how” of the CMDB project — that is, why the enterprise needs the CMDB and the value it will deliver. It keeps them informed of the project’s progress and lets them know when the project will affect specific groups.

The CMDB is the heart of the ITIL framework and is what keeps ITIL best practices alive and kicking.

Bear in mind that most of the key players have already built their own homegrown methods of maintaining data that is relevant to their job functions and technical requirements. Switch--ing from their familiar spreadsheets, databases, and paper-based systems is unsettling at best. Effective communication explains how elimi--nating their obsolete, manual processes and replacing them with a CMDB and ITIL best practices will make their jobs easier and ensure greater success for the enterprise as a whole.

Communicating the added value for the busi--ness, including its benefits from a user point of view, has a major impact on people’s buy-in. Executive sponsorship is also required and should be highlighted throughout the project lifecycle. Without effective communication, you can expect to experience resistance to change, project delays, and a slow adoption rate.

Questions aren’t applicable here either, so I’m providing a checklist of communication activities that will help instill enthusiasm in everyone involved in the CMDB project, as well as everyone who participates in IT service man--agement processes:> Strong executive sponsorship and

communication from executives displaying support

5TiPSFORSUCCeSS

> E-mail campaigns announcing the project, with regular and repeated communication of plans and status to people whose jobs will be impacted by the project

> A section on the corporate intranet describing the mission and goals of the project, key players, benefits to the business, road maps, and schedules

> Focus groups — initially to gain input from all affected areas of the business and then on an ongoing basis to validate plans, road maps, and schedules

> Consulting workshops around organization changes and communication

> Meetings, meetings, meetings — but be sure to keep them productive, to the point, and fun, if possible, to avoid meeting burnout

> Workshops to train people on software tools and processes

Occasionally, we have a client that for one reason or another doesn’t do a good job of communication. At one company in particular, people had become frustrated and concerned as the project progressed. They knew they would be forced to change their way of work--ing, but hadn’t been convinced of the value of making that change.

The IBM team had to come in after the fact and launch a major communication campaign to sell the project. We used a combination of e-mail messages, meetings, workshops, and other channels to disseminate key messages about the project. These efforts alleviated a lot of concerns that key stakeholders had, and ultimately, turned around a bad situation.

AChIevING suCCessBuilding a CMDB is the beginning of a journey that requires consistency, commitment, good communication, and a process-driven business focus. By asking the right questions before you embark on your journey, you can avoid many roadblocks. Use the questions and recommen--dations presented here as a starting point, but feel free to add your own. n

SelmaTurkihas ten years of experience working in computer technology. she has been with IBM for seven years, starting at IBM Canada Ltd. as an IT specialist. In 2000, selma transferred to IBM Belgium as an IT architect. selma concentrates on assisting clients in the consulting, planning, design,

and implementation of service management and asset management solutions, based on the ITIL framework and the worldwide IBM IRMa best practices.

ABOUTTHeAUTHOR

Carefully scope out the project and come up with a

well-defined plan.

Consider people, process, information,

and techno logy when building your approach.

Weed out un necessary data

and reduce the number of data

sources involved.

Select a strong leader with a thorough

knowledge of service management and

ITIL, as well as good listening and

negotiating skills.

Use a variety of means to

communicate your message and gain

buy-in across the enterprise.

Strong leadership drives the project ahead despite obstacles, political issues, and resistance to change.

��

��

Managing a configuration manage--ment database (CMDB) implemen--tation is like rock climbing. You don’t

just blindly race up the wall to the top — in fact, that would be impossible. Instead, you move methodically, one step at a time, to avoid stumbling or falling. Both rock climbing and a CMDB implementation are challenging, but the end goal of each is attainable if you take a systematic approach and understand and analyze the requirements before moving forward. And when you achieve that end result — whether it be reaching the top of the rock wall or successfully implementing a CMDB — you’ll have a great sense of accomplishment.

In November 2005, we initiated our CMDB implementation at xwave, an Aliant Company. The project included integrating mainframe data into our CMDB, since both our Infrastructure Services (IS) team and our business stake--holders prioritized a business process that included applications based on the mainframe. Our goal was to achieve the maximum benefit with minimal additional data.

The incremental approach we adopted enabled us to effectively meet our implementation goals and avoid scope creep, which could have de--railed our project. We successfully completed the implementation in less than 90 days. Based on our experience, we recommend a four-step approach to a CMDB implementation.

We wanted to ensure we included enough data on CIs and attributes in the CMDB, and that the data would be useful.

sTeP 1iDenTiFYTHeReQUiReMenTSThe requirements phase involved defining the project scope; that is, detailing and document--ing the business requirements and obtaining stakeholder and IS agreement on what was to be initially encompassed by this initiative. We wanted to ensure we included enough data on configuration items (CIs) and attributes in the CMDB, and that the data would be useful to the support teams and the business. We

ByJOeLORD,CRAiGPieRCeY,AnDKYLeWARD

YoucanachieveasuccessfulCMDBimplementationifyouapproachitinamethodicalway.Here,weprovideaviewofaCMDBimplementationthroughtheeyesoftheprojectmanagers.

SuccessfulCMDBIMPLeMeNTATIoN

PracticalSteps4 to a

��

also wanted to avoid going too wide or deep with the scope, while keeping in mind how the project affected our current processes and how we would deal with the fairly static nature of the mainframe environment.

We ensured that each CI we planned to include in the CMDB was either already utilizing, or going to utilize, our change management pro--cess, so that moving forward, any changes to the infrastructure would be captured in the CMDB. We were adamant about this ap--proach, because to maintain the integrity of the CI data in the CMDB, we’d need to track any changes to CIs.

Stakeholder satisfaction and involvement was also a key priority. Applicable teams from support, metrics, and management assisted us to ensure we would meet the business needs with the initiative. We explained to them the benefits they would derive by having cer--tain information captured within the CMDB. We finalized the requirements phase with the completion of a requirements document, which we made sure was approved by all involved stakeholders.

Below are some of the key questions we posed to our stakeholders to help determine requirements:

How much detailed information do you want to track for each CI? Are you tracking that data today?Where are you keeping it? How is it tracked? What value does it add to the business or the support team?If you are giving us a requirement, how are you going to keep that requirement current in the CMDB?

One of the biggest challenges at this phase was identifying the actual stakeholders who needed to be involved in the project or who would need to consume CMDB data. We addressed this challenge through discovery discussions with client contacts from the

>

>>>>

>

support team and service managers to ensure we had the right people at the table.

The other major challenge was keeping the scope manageable. We accomplished this by relentlessly focusing on our objective — maximum benefit with minimum additional data collection — and ensured that all stake--holders understood the importance of con--centrating on this objective.

The potential content of the mainframe CIs and their attributes was extensive, and we wanted this information to be kept at a man--ageable level to ensure data accuracy would be maintained. We started small, and then let the project grow only as needed. The “nice to have” requirements that did not provide business value were dismissed, so that we could focus on the business need and man--ageability of the data.

We ensured that each CI we planned to include in the CMDB was either already utilizing, or going to utilize, our change management process.

sTeP 2 desIGNIn the design phase, we took the requirements document and asked ourselves, “Where do these requirements fit in?” We began this phase by identifying how we would use the CMDB, as well as how the previously defined required data would be captured. We then examined our processes. For example, we looked at our change and incident management processes to determine how we would ensure that any changes in the infrastructure were flagged, and how cases related to any of the CIs would be associated properly back to those CIs. We then documented these processes in a stan--dard operating procedure document.

We also defined and built compliance reports to ensure that the outlined processes for con--figuration management would be followed.

��

These compliance reports also would serve as a method of auditing the recorded data. Finally, we used the specified requirements for gathering the CIs and their attributes as the basis for building the templates and the reports needed for post-implementation.

We clearly communicated to all stakeholders how we were going to capture information and how the data would be populated in the CMDB.

Once the requirements document was finalized and approved by the stakeholders, we built an import template for the support team to populate with their CI information. We also used the template to:

Identify any compliance reports we would need to build to ensure that we would be documenting and training our support teams on these processesEnsure that the processes would be followed on a continual basisVerify that any required post-implementation reports would be built and ready

Our biggest challenge at this phase was en--suring that the requirements were clearly defined before we began the design. In a few cases, stakeholders were adamant that they needed data that wasn’t identified in the requirements phase. We evaluated each request to include additional CI data in the defined scope. We expanded upon the require--ments document in cases where we determined the business need was critical.

sTeP 3 BuILd In the build phase, we gathered data to pop--ulate the CMDB based on information from all stakeholders. We used the templates that we had created in the design phase to gather the data. The key stakeholders verified that the information in the templates was complete and accurate data. We checked to make sure that the CI data would actually fit in the places in the CMDB that we had identified the data would reside.

>

>

>

We clearly communicated to all stakeholders how we were going to capture information and how the data would be populated in the CMDB. We also conducted training sessions with the support teams and stakeholders to ensure that they clearly understood their requirements and responsibilities related to how the CMDB would be used and how the configuration management process would be managed. We explained how the CMDB was related to other service management procedures, and how it would benefit support individuals as well as the business. This communication was essential in attaining buy-in from every--one affected by this project.

The biggest challenge at this stage was getting all of the stakeholders together at one time so that they could understand the collective value of the CMDB implementation and how their needs affected or tied in with other areas of the business.

sTeP 4 IMPLeMeNT During the implementation phase, we took what we had defined and built and put it in place. Since we had been very methodical in the requirements, design, and build phases, our implementation phase was very straight--forward.

In this phase, we first finalized a standard operating procedure for configuration man--agement for the mainframe from a service delivery perspective. We wrote this document with input from all the groups, taking informa--tion from the requirements phase; incorporating processes we already had defined for the configuration management service itself and breaking it down to a mainframe level; and having that document approved and published. We then imported the approved data into the CMDB.

The biggest challenge we encountered at this phase was ensuring that the scope was kept in line with our initially defined parameters. We had to convince stakeholders that this

��

wasn’t the time to expand the scope of the project, but agreed that these needs would be considered for a subsequent phase.

ResuLTs The CMDB is enabling us to deliver improved service and availability to the business that depends on us. We conduct quarterly custom--er value index measurements and the level of client satisfaction is improving. We attribute this to our CMDB implementation. In addition, while the implementation has been in place for only three months, our compliance reports show that the support teams have embraced and are following the defined processes.

Finally, the CMDB is already providing us with initial lifecycle data of the CIs from infrastructure changes and incidents associated with them — information that wasn’t available prior to this implementation. This view provides valuable historical data that can be used by both the business and other service management processes. For example, we use historical data to help us analyze problems reported with infrastructure items.

ThRee KeY TAKeAwAYsDon’t look at your CMDB implementation as a rock wall that is impossible to scale. Take a methodical, analytical approach to ensure success. When setting forth with your imple--mentation, keep three key points in mind. The first point is to clearly define your phases and plainly document the deliverables under each phase. Have a clear understanding of the de--sired end result of each phase and document it accordingly.

The second point is to ensure that you stay within the defined scope. Other requirements may arise, but if you take them on, the scope may end up too broad to accomplish in one initiative. It’s alright to add to the scope if the business requirement is critical. If it isn’t, make a note of the additional requirements, and you’ll have a head start when you begin to expand upon your CMDB implementation.

The third main point is to continually commu--nicate with everyone involved in, or affected by, the implementation. Ensure that they un--derstand the scope of the CMDB project, as well as the benefits they will realize as a result of learning new processes. We provided ongoing communications, so that everyone who needed to be was engaged at every stage of the process. As a result, we did not have a challenge in gaining acceptance of the CMDB. n

The CMDB is enabling us to deliver improved service and availability to the business.

5TiPSFORASMOOTHiMPLeMenTATiOn

Keep the scope manageable by

relentlessly focusing on your objective.

Keep in mind how the CMDB project affects

your current processes.

Involve applicable teams to ensure that the CMDB initiative

meets business needs.

Define requirements clearly before begin--

ning the design.

Communicate the scope and benefits

with everyone involv ed in, or affected by, the

implementation.

JoeLordis the team lead for the Configuration Management team and the Configuration Manage­­ment process owner within Aliant. his responsibilities involve providing guidance to, and overseeing his team’s involvement in, several ITIL process initiatives. Joe has worked in IT for six years and is currently

certified as an ITIL Practitioner.

ABOUTTHeAUTHORS

CraigPierceyis a senior technical analyst with Aliant and is team lead of the Mainframe Technical & database support Team. In his 23­year IT career, Craig has performed many roles. his primary area of expertise is with systems­managed storage and virtualization. his team supports the ICT environment and

delivers ICT solutions. Craig has been a key contribu­­tor to Iso certifications and ITIL implementations.

KyleWardis a business process analyst with Atlantic Canadian­based Aliant. Kyle is part of the Configuration Management team, and is currently heavily involved in several ITIL process initiatives within the organization. Kyle has worked in IT for seven years and is ITIL certified.

�8

Most IT departments have taken one of two distinct approaches in deplo-ying a configuration management

database (CMDB). One approach is to focus on thoroughness, and the team spends months, if not years, planning the solution. This approach may make sense in certain situations, such as a complex deployment in a large enterprise. However, the delay in actually implementing the CMDB causes functional groups to become

impatient because they see no signs of prog--ress. Many times, the functional groups will move forward with disparate solutions. These disparate solutions are hard to integrate once the overall CMDB solution implementation is under way.

The other approach is to focus on quick results. Organizations taking this approach jump right to implementation without much, if any, planning.

AMilestone-Based

Rapid CMDBApproachtoa

Definition-to-Deploymentinitiative

�9

They load the CMDB with as much data as they can access. However, functional processes rely on accurate, reliable CMDB data. The result of this sort of implementation is that the CMDB data does not support the functional processes that depend on it.

You need to identify the providers, consumers, and data sources that the CMDB will impact.

While these approaches attack the challenge in different ways, they both often fail for the same reason: It is difficult to determine ahead of time the entire size and scope of the CMDB implementation.

At Wipro, we have devised an innovative ap-p roach that is thorough, yet drives quick results. Through working with numerous customers on CMDB deployments, we have created an iterative eight-phase CMDB implementation approach.

YoureallycanimplementaCMDBinitiativethatachievesboththoroughnessandquickresults.Thiseight-phaseapproach,eachwithanaccompanyingmilestone,describeshow.

ByJASOnODDen

�0

This approach provides a complete definition-to-deployment plan for a rapid CMDB imple--mentation at a reasonable cost. The output of each phase is a milestone that represents a significant achievement and value, empower--ing the organization following this methodology to make informed decisions regarding the implementation of a CMDB.

Achieve these milestones in order, and you can scope and plan your CMDB implementation in real time. This approach is designed to work with any out-of-the-box CMDB solution. Each milestone can act as a checkpoint for the previ--ous milestones. That allows you to take a holistic, flexible approach toward your CMDB initiative.

PhAse 1iDenTiFYCMDBPROViDeRS,COnSUMeRS,AnDPROCeSSeSTo reach the milestone in this phase, you must be able to provide the right configuration data to the people and processes that need it. First, you need to identify the providers, consumers, and data sources that the CMDB will impact. We recommend you use a best practices frame--work, such as the IT Infrastructure Library (ITIL®), to accomplish this.

Next, you’ll need to identify the touch points in each of the processes the CMDB crosses. Best practices frameworks touch a number of different processes, and not every organization will be at the same maturity level for every process. The key is to prioritize and start with those processes that have the greatest expected improvement from integration with the CMDB.

The scope of the CMDB is also considered during this stage. Identify a reasonable and limited scope for the initial deployment of the CMDB — a reasonable, conservative scope that can be implemented well, learned from, and repeated to broaden and deepen the CMDB over time. Consider the following questions:

What processes, such as change manage--ment, would consume data from the CMDB?

>

What other applications, such as network discovery tools and applications, would provide data to the CMDB?What specific roles of people will provide data to the CMDB or query from it?How important is each application that consumes data from the CMDB?

Prioritize and start with those processes that have the greatest expected improvement from integration with the CMDB.

Milestone for phase 1 CMDB providers, consumers, and processes are identified.

Checkpoint. Providers, consumers, and pro--cesses should align with each other. Another useful activity is to prioritize processes and scope areas, keeping them reasonable, con--servative, and repeatable. Project phases should be sensible and align with external depen--dencies. Note: Initial scope may be limited to achieve quick wins. If you have identified multiple CMDB releases, you will need to keep future phases and milestones carefully aligned with each release.

Risk factors. Providers and consumers not only need to be identified, but also put in the con--text of the processes that rely on the CMDB. If something is missing from this broad picture, the CMDB is at risk of not satisfying all the needs of business and IT processes. Without clearly defined dependencies among providers, consumers, and processes, project phases could be defined that do not have all the nec--essary prerequisites in place. Similarly, CMDB elements could be implemented before the processes are in place to maintain or take advantage of these CMDB elements.

>

>

>

��

PhAse 2QUAnTiFYTHenUMBeROFCisAnDTHeiRReLATiOnSHiPS(SizinG)Phase 2 is intended, within the scope identified as milestone 1, to define and quantify the configuration items (CIs) and relationships. You’ll want to consider the following:

How many records will you be storing in the CMDB?How are CIs going to be related to each other?How will you populate or discover those relationships?How will you maintain the accuracy of the data?

Milestone for phase 2 The number of CIs and their relationships are effectively quantified. Checkpoint. You’ll need to manage the trade-off between the benefit of having the data versus the cost of maintaining the data. If you find yourself with too much manual ad--ministration, you might want to go back to phase 1 and refine the scope. Again, if you have multiple releases of the CMDB identi--fied, these releases can be realigned to bal--ance sizing requirements.

You’ll need to manage the trade-off between the benefit of having the data versus the cost of maintaining the data.

Risk factors. If you don’t achieve accurate sizing in this milestone, you might have dozens of manual links that never get updated (leading to an out-of-date CMDB). You might also end up with a database that’s either too small or too big. As a result, you might install the CMDB on insufficient hardware that provides poor performance. You may also find that you don’t have the right staff for the amount of manual maintenance or data administration you’re setting up.

>

>

>

>

PhAse 3DeFineAHiGH-LeVeLDATAMODeLThe purpose of this phase is ensure that you perform a gap analysis between the CMDB technology that you plan to implement and the data you defined in phase 1. Map the data that each of the providers has to offer, along with the data consumers will need. If you’re going to build a CMDB tool, then the process of achieving this milestone will include a complete design phase.

The gap analysis helps you to look at the list of fields to be included in the solution, and com--pare them against the data sources you already have. Ask yourself the following questions:

Based on the prioritized processes, what data do we need?What data do we already have? Where is it located?What data fields are already included in the solution?Where is the gap and what fields are missing in these areas?Can we make everything fit with our CMDB solution, or do we need some custom work or development?

>

>

>

>

>

��

Milestone for phase 3 A high-level data model is defined and documented.

Checkpoint. If you discover that a required data source isn’t included in the planned CMDB solution, you may need to customize the so--lution. Make sure the benefit of having the data justifies the cost of customization. You might want to change the phasing of the inte--gration to start with an initial scope that utilizes what is included in the solution. Likewise, if you find yourself with more processes than you can handle, or with data sources that aren’t going to provide much value, then you might return to phase 1 and refocus on a couple of them.

Risk factors. If you don’t realize this milestone, you may end up with a CMDB that won’t be able to accommodate all of the data provided to it. Similarly, the CMDB won’t be able to provide data that’s asked of it. Furthermore, if you don’t perform a gap analysis, you’ll have a large list of fields and a very complex struc--ture. As a result, you’ll have trouble tying the data to the tool later in the implementation.

Make sure the benefit of having the data justifies the cost of customization.

By starting with a list of attributes (fields) and comparing what is available from the providers and needed by the consumers, you avoid getting mired in the technology itself. This comparison will lead to the set of fields actu--ally required — a much smaller set of data than every thing all providers have to offer. This required set of attributes can then be compared to the technology in a simple gap analysis exercise.

PhAse 4DeFineTHeReLATiOnALCLASSMODeLThe purpose of this phase is to determine the relational hierarchy necessary to define and store the attributes and relationships that make up the CMDB. To this end, you’ll want to make sure the fields are in the right place with the right structure. Your detailed design diagrams should show all of the relationships between entities. During this phase, remember these guidelines:

If tools or technologies rely on the data structure, try to stay within that structure.Avoid unnecessary complexity in the data structure.If using an object-oriented model, take care to put attributes in the right level, especially where there are potentially many layers of subclasses.

A complete, out-of-box solution can save you time and money in designing a model that can define and extend to all of those classes.

Milestone for phase 4 The relational class model is clearly defined.

Checkpoint. The level of customization of the tool still allows for reasonable performance, maintenance, and upgrade capability. Phases still make sense within the context of the data model and structure. Precedence of data from the provider systems should also be understood at this point, since it must be reconciled into the CMDB (else the data be incorrect or inconsistent).

Risk factors. If you skip this phase and don’t achieve this milestone, you will either have not enough or too much segregation between the different types of records in the CMDB. Also, you might end up with records that are too big or too unmanageable.

>

>

>

��

PhAse 5MODeLTHeDATAReCOnCiLiATiOnThe purpose of this phase is to start the transition from design to implementation by modeling data reconciliation. Milestone 1 identified all of the different data users and providers. Now, you’re ready to create those integrations by mapping how data will be reconciled when it comes from two different sources. The goal is to have one single data set. You’ll need to know the following:

What are the rules for data precedence? What are the compare rules for any two data sets? How do you compare and merge those records?How often do you need to collect, compare, and merge data into the published CMDB? What is the frequency of discovery?What are the data set requirements for how the data maps into the system?What sorts of jobs will continue ad hoc versus a scheduled or automated recon--ciliation process within the CMDB?How do you identify each record?

Milestone for phase 5 A process has been defined for reconciling data when you have more than one data source.

Checkpoint. Overall complexity is a key point here. It is entirely possible to architect recon--ciliation rules that are unrealistic to create and maintain. Implementation phasing and stages should also be in line with provider data avail--ability, process maturity, and consumer tool and process readiness.

>>

>

>

>>

>

>

Risk factors. If you don’t achieve this milestone, your CMDB might have duplicate records — either in the same place or in different places. In other words, your CMDB has bad data.

PhAse 6exTenDCMDBATTRiBUTeSAnDSTRUCTUReIn this phase you will perform the CMDB attri--bute and class-level implementation of the data model you’ve created. You’ll want to add any needed fields, classes, and relationship types, as well as any workflow to link the pro--vider and consumer systems and processes together. If any attributes have been identified without at least one provider or one consumer (remember, these can be manual), you can add them later.

The goal is to have one single data set.

The end result should look like a well-structured CMDB (what’s in it and what fields are there) ready to have CIs plugged into it. Now you know it’s the right time to create those integrations.

Milestone for phase 6 CMDB attributes and class-level implementation of the data model are complete.

Checkpoint. If you skip phase 5, or casually outline the process in milestone 5, you’ll have a poorly structured CMDB. Verify your imple--mentation in milestone 6 against the design from milestone 5 to ensure completeness.

Risk factors. If you do not meet this milestone, you might not find the fields you need when you are ready to import data or to integrate data from other tools. In other words, failure to perform this phase could result in your inability to load or to integrate all of the data.

��

PhAse 7MiGRATeAnDCOnVeRTDATAThis phase has two purposes: to conduct one-time loads of data into the CMDB from your legacy sources, and to create the integrations you’ve prioritized. Make sure you include con--sumers’ integrations. Also, don’t forget to create any federated links. If you have data that is not stored in the CMDB, but would be referenced, you’ll need to create those links.

You can perform both phase 7 and phase 8 iteratively when you start an integration, by creating the reconciliation rules for the data source and then executing them.

Milestone for phase 7 Data is migrated and converted and integra--tions are created.

Checkpoint. Training, testing, and user accep--tance will reveal whether you have success--fully accomplished this milestone. Failure to complete testing and training will lead to poor acceptance of the CMDB as it is deployed.

Risk factors. If you don’t complete this phase, you’ll have an empty or an incomplete CMDB.

PhAse 8DePLOYTHeCMDBThe purpose of this phase is to complete all of the activities needed to get your system ready for production. This includes the following:

Test the system and user acceptance in preproduction. Migrate any preproduction systems to full production systems.Train personnel to use the CMDB.Inform key audiences about the CMDB.Test all integrations.Validate that everyone knows how to use the CMDB.

If people don’t know how to use the CMDB, then its value goes untapped and the organization gets shortchanged.

Before you go into production, you might want to have several iterations where you import other data feeds or data sources, test them, and deploy them.

>

>

>>>>

5TiPSFORDeFininGAnDDePLOYinGACMDB

Milestone for phase 8 CMDB is successfully in production.

Checkpoint. Production system is live and in--tegrations are functioning. Users are trained and using the system appropriately. Processes are interacting with the CMDB and keeping it up to date.

Risk factors. If you don’t thoroughly complete the tasks in this phase, the resulting CMDB may have incomplete data, insufficient data, or data loaded with bugs. If people don’t know how to use the CMDB, then its value goes un--tapped and the organization gets shortchanged.

suCCessfuL defINITIoN To dePLoYMeNTThis eight-phase approach answers the often-conflicting needs for both thoroughness and quick results. By following this approach, meeting the milestone in each phase, watching the checkpoints, and knowing the risk factors, you can rapidly progress from definition to deployment of your CMDB. n

JasonOddenis a principal solutions architect at wipro. he is a certified Remedy Approved Consultant (RAC) and has more than nine years of Remedy® experience and dozens of successful implementations in a wide array of environments. In ad dition to his customer focus, Jason has been an active member

of the Remedy community, participating in alpha and beta programs, and has been a presenter at numerous national Remedy user Groups (RuGs). Jason is ITIL foundation Certified.

ABOUTTHeAUTHOR

Know what delivers value to your custom--ers and providers of

CMDB data.

Define the appro-priate scope and

depth of the project.

Make sure that you’ve completely

thought through the design of the CMDB.

Plan for the future. In your efforts to get something up and

running quickly, make sure you don’t hinder the future functionality

of your CMDB.

Go back and refine as needed, and have a flexible attitude so

you can build the best CMDB possible for your organization.

��

Do you embrace the idea and promise of the configuration management data--base (CMDB), but feel overwhelmed

by the details? Do you have a lot of asset data and configuration items (CIs) that you’d like to put into the CMDB, but have no idea where or how to start — or how to identify the infor--mation you need to gather?

Breaking down your CMDB project into smaller pieces will enable you to really wrap your arms around it. By identifying and achieving quick wins, you can make significant progress toward a successful CMDB implementation. Here is some guidance for this “quick win” approach.

IdeNTIfY The MosT MATuRe dATA CoLLeCTIoN MeThodPopulating the CMDB with CI data is a quick win. I usually start by asking the client: How do you currently collect data, how often, and in what database do you store that information? And then I recommend that we start building the CMDB using the client’s most mature method for data collection.

��

identifyandachievequickwinstorealizegreatersuccesswithyourCMDBimplementation.

Here’show.

AdviceforAchievingQuickWins

withYourCMDBimplementation

ByV’ALiFORD

�8

Your most mature method might be a discovery tool. Or, you might have a well-defined manual auditing process, where you walk the floors to take an inventory of your assets. Whatever your most mature method is, start there.

defINe A LIsT of I.T. seRvICesIn addition to identifying your most mature data collection method, create a service cata--log, or list of services that IT provides to end users. Creating the service catalog is critical, because it allows you to go to the business stakeholders to determine the services that the business sees IT providing for them.

For example, the service could be the ability to take online orders or the capability to pro--vide outstanding customer service through a customer support application that is always available. It might also be access to the Inter--net, network services, or printing services. Once you know what services IT provides to the business, you’ll usually have a good idea of what you’ll need to build, as well as the CI information you’ll need to gather to populate the CMDB.

foCus oN A weLL­defINed seRvICe ThAT I.T. PRovIdes To The BusINess If you already have a service catalog, determine the business service that has the most well-defined processes. Some organizations decide to start with their pain points. However, we’ve found that in many cases, the areas with major pain points usually lack a sound process to gather the necessary information to populate the CMDB. You would need to engineer a new process and then collect the data to populate the CMDB, and this would result in a longer time frame for implementation.

To achieve a quick win, start where the pro--cesses are already defined. If the processes are defined and you’re already collecting the data, then that can lead to an even quicker win. You can demonstrate the power of the CMDB

with this quick win, and at the same time, you can use your initial success to begin to address one of the processes that has pain points.

CReATe A ToPoLoGY TRee foR eACh seRvICe CATALoG ITeMAfter you define your list of services and populate your most mature data into the CMDB, you can identify the CIs that support each service that IT provides to the business. Add the application databases that reside on those CIs, and on top of that, add the service. Eventually, you will have a full topology tree, so you’ll be able to see the assets that support each service catalog item.

To achieve a quick win, start where the processes are already defined.

Typically, your most mature method of gath--ering data covers an entire asset class, so you’re probably discovering a large majority of a system, such as desktops or servers. In some cases, your topology representation might need to have a generic item that represents the network infrastructure, for example. At least you’ll have a placeholder, so you know that you will need a discovery method to fill in the unknown cloud of network services, including routers, switches, hubs, Ethernet cables — everything that makes up that net--work infrastructure. The key is gathering that information, developing the service catalog, and then filling in the unknown areas on the topology tree.

Keep in mind that today, discovery tools are best suited to identify the assets that support the services that IT provides to the business. You should have discussions with the business stakeholders to define the services themselves and the assets that support those services. In the future, I expect that discovery solutions will be enhanced to provide service discovery as well.

�9

ReCoNCILe MuLTIPLe dATA seTsIf you have created a topology tree for each service, you need to pull in other data sources so you can create a more accurate represen--tation to attach to the service catalog.

Start with a pen and paper exercise of building a matrix. Think about all of your data sources; what can you discover? Then, think about the asset classes that you want to bring into the CMDB, such as desktops, servers, or printers. Next, match the discovery tool to the asset class. Then rank their attributes; which source do you use when there is conflicting data? For example, if you have three data sources for printer information (and thus, three sets of data) — and you need to determine the amount of memory in the printer — then which data set do you use?

After you define your list of services and populate your most mature data into the CMDB, you can identify the CIs that support each service that IT provides to the business.

Completing this exercise allows you to begin building out your reconciliation and rules. You will have multiple data sets coming into the CMDB, so you must determine how you will reconcile into your production data set. Having this matrix helps you decide what the author--itative data source will be.

During this exercise, we also work with our clients to bring an IT Infrastructure Library (ITIL®) perspective to the assets, relating inci--dents and problems and changes through the discovered items in the CMDB. It’s at this point that organizations really start to see improve--ment in IT infrastructure management.

suCCess sToRY: CoNveRT dATA ANd esTABLIsh dIsCoveRY feedWe have worked with several organizations that achieved quick wins upon which they can continue to build. One client, a large pharma--

ceutical company, needed to convert its current repository of asset data into data suitable for the CMDB. The company wanted to retire a fixed asset system that contained information about the entire infrastructure: databases, applications — everything in the IT environ--ment — as well as contract information. However, the company’s discovery tool found only desktop data.

To meet the company’s needs, we began by converting the fixed asset data from the leg--acy system and bringing that data into the CMDB. Next, we adjusted the desktop data discovery feed so it could populate the CMDB. Once the desktop data was feeding the CMDB, we set up a process to reconcile the discovery data versus the CMDB data.

The quick win was to get rid of the legacy system, populate the CMDB with this data, and create a discovery feed into the CMDB. Then, when the data was in the CMDB, we began work on tying it to the appropriate business services.

You will have multiple data sets coming into the CMDB, so you must determine how you will reconcile into your production data set.

This company already had a list of services, along with service level agreements that dic--

�0

tated when a service would be available and when it could be taken down for maintenance. We brought the list of services directly into the CMDB, and placed the repository of asset data within the topology map. Then, we took the organization’s IT service catalog and determined the business services below each item in the service catalog. Underneath that, we deter--mined the applications supporting the business services, and then the databases that support the applications and servers that support the database. In this case, we had a good reposi--tory for data. In essence, we completed the topology tree.

Achieving a quick win can help you establish greater efficiencies and increase your pace towards reaching your ultimate CMDB goal.

The greatest benefit to our client was a repos--itory directly tied to its help desk ticketing system. The company had an external asset repository for reference purposes. Previously, the help desk solution didn’t feed into the re--pository, so there was no way to capture the data that related assets to an incident, or as--sets to a problem. Now that the asset data is tied to the help desk system, the company can see exactly how many changes have been made to a particular asset or how many incidents have been reported against an asset. That was a big win for this client.

QuICK wIN foR GReATeR effICIeNCYAchieving a quick win can help you establish greater efficiencies and increase your pace toward reaching your ultimate CMDB goal. For example, time management and produc--tivity experts encourage you to consolidate your data from a handwritten address book, a PDA address book, a Microsoft Outlook address book, and a calendar down to one place, so that you quickly and efficiently know the true source of your data. The same thing is true for your CIs and a CMDB. If you have CI information scattered in multiple databases, you don’t know which one is accurate. You have to take more time just to find out which database to query.

The quick win is achieved when the data is in a central location, and everyone knows where to find the information they need. When you need to update that data, add new data, or find another source, you know where you will be consolidating that information — in the CMDB. Then you will have a starting point for your CMDB on which to continue building. You can identify other data sources that will make this view even more comprehensive than it was before, and therefore increase your efficiency even further.  n

The quick win is achieved when the data is in a central location, and everyone knows where to find the information they need.

5TiPSFORAQUiCKWinAPPROACHTOACMDBiniTiATiVe

V’AliFordis a Remedy application architect and developer with eMs. he is a Remedy Approved Consul­­tant (RAC) and has seven years of experience developing solutions in the BMC® Remedy® IT service Management suite and BMC® Remedy® Customer service and support app lications. v’Ali has app­

lied proven methodologies to analyze, design, develop, and document systems for eMs’s clients. v’Ali has successfully led teams to integrate various products with BMC® Remedy® products. he is well­versed in industry standard best practices such as ITIL.

ABOUTTHeAUTHOR

Identify your most mature data

collection method.

Meet with business stakeholders and develop a list of services that IT

provides to the business.

Create a topology map that illustrates

how your assets support the services

you provide.

Use a matrix to help determine which

data set is the authori--tative data set, and establish your data reconciliation rules.

Leverage the quick win for further improvements

to your IT infrastructure

processes.

��

ConfigurationManagementActivities

UsingiTiL’s

for CMDB Success

UsethefiveiTiLconfigurationmanagementactivities,plusanadditionalactivitydevelopedbyQuitze,asthebasistodeliveraCMDBthatsupportstheneedsofthebusiness.Thisarticleexplainshow.

ByJAVieRLeYVAnOVOA

��

The configuration management database (CMDB) is essential for effective con--figuration management. Moreover, it

is the key element in the entire IT Infrastructure Library (ITIL®) best practices service model.

The ITIL book, Best Practices for Service Support, discusses and defines five specific configuration management activities, ranging from planning

to verification and audit. At Quitze, we use these five activities, plus one additional activity, as a framework for CMDB implementations.

In this article, I’ll expand upon the ITIL config--uration management recommendations by providing specific guidance for effectively evolv--ing through the six activities, which will set the stage for a successful CMDB implementation.

��

ACTIvITY 1PLAnninGITIL’s Best Practices for Service Support book states that this first activity includes “planning and de--fining the purpose, scope, objectives, policies and procedures, and the organizational and tech--nical context, for Configuration Management.”1

Activities in planning a configuration management process include:

Assigning a person to be responsible for the process and systemsAnalyzing existing configuration manage--ment systems, data, and processesGaining agreement on the purpose, objectives, scope, priorities, and implementation approach for the configuration management processPlanning for and obtaining funding for configuration management toolsAttaining commitment for extra resources

The important tasks in this activity are defining the depth and breadth of the CMDB as well as the business policies and rules surrounding the CMDB. Defining the borders helps to focus the implementation so you don’t try to accomplish too much in the first phase. It’s fine to save some of the less business-critical requirements for a future phase.

Tips for effective planning include the following:Get management support, starting from the top.Gain commitment from everyone — in all parts of the organization — who needs to be involved in the project.Clearly define your business idea and be able to succinctly articulate it. Know your mission. Examine your motives. Make sure you have a passion for owning a configura--tion management process. Be willing to commit to the hours, discipline, continual learning, and the possible frustrations of owning your own business IT process.

>

>

>

>

>

>

>

>

>

>

Conduct a competitive analysis of the configuration management market, including products, prices, promotions, advertising, distribution, quality, and service. Also be aware of the outside influences that affect your business. Seek help from other organizations, vendors, professionals, government agencies, employees, trade associations, and trade shows. Be alert, and ask lots of questions.

If you don’t plan effectively, it will take much longer to deploy the initial phase of the con--figuration management process and the CMDB. The staff responsible for the deployment may become disinterested. You’ll end up gathering information that is not aligned with business objectives, or acquiring tools that are unneces--sary. Finally, you will not address and resolve external influences that inhibit or change the scope of the initiative.

ACTIvITY 2iDenTiFiCATiOnOnce you’ve defined the breadth and depth of your CMDB, you will need to identify each of the configuration items (CIs) that will be stored in the CMDB. According to ITIL, this activity includes “selecting and identifying the configuration structures for all the infra--structure’s CIs, including their ‘owner,’ their interrelationships and configuration docu--mentation. It includes allocating identifiers and version numbers for CIs, labeling each item, and entering it on the Configuration Management Database (CMDB).”2

You’ll need to have a working knowledge of the common data model (CDM) of the CMDB. Understanding the CDM will enable you to:

Determine the attributes of each class, so you can find out if your CDM attributes are sufficient for the business requirements

>

>

>

1. ITIL Best Practices for Service Support, p 121, Her Majesty’s Stationery Office, 2000

Defining the borders helps to focus the implementation so you don’t try to accomplish too much in the first phase.

��

Know which types of configuration items are not included within the CDM scope and which will be created later as classes within the CMDB

Next, you’ll need to identify the external data sources from which the CI information will be obtained — either automatically or manually. You’ll also need to identify the data sources that you’ll only point to, to obtain the CI information.

Tips for effective identification of CIs include the following:

Conduct a workshop with everyone involved in the process to prioritize services and re--lated CIs to put in the CMDB, how they re--late to each other, and how data is captured.Use a service catalog, or a list of services that IT offers, to define the initial depth and breadth of the CMDB by completing the following steps:

Identify the critical services that affect critical business functions.Analyze each critical service to pinpoint every IT component that supports it.Catalog all components that support critical services into families, so the cat--egorization will be easier.Identify key attributes of each family so you can more easily support the components.Use the basic relationships between components, such as “component of” or “impacts directly on.”

Acquire the assistance of a technical writer or a documentation analyst.Evaluate the quality and value of existing configuration documentation.Involve appropriate hardware/ software suppliers.

>

>

>

1.

2.

3.

4.

5.

>

>

>

If you don’t effectively prioritize CIs, you will find that you are storing a lot of useless infor--mation in your CMDB, resulting in excessive storage and search costs, confusion when searching information, and an abundance of problems in managing and maintaining CMDB data. You will also likely discover that you are not storing critical information that people need, and people will be less likely to use CMDB data.

ACTIvITY 3COnTROLITIL states that this activity entails “ensuring that only authorized and identifiable CIs are accepted and recorded, from receipt to disposal. It ensures that no CI is added, modified, re--placed or removed without appropriate con--trolling documentation, e.g. an approved Change request, and an updated specification.”3

The CMDB permission schema plays a crucial role in this activity. If you don’t have an infor--mation security schema, you cannot be assured that you are providing truthful and timely in--formation about the CI to the right process. Figure 1 is an example of a permission schema.

You will also need to identify which processes, applications, and users rely on CMDB data, and codify any business rules that are going to be put in the CMDB. These tasks will require you to do the following:

Define the role of people accessing the CMDB.Define what type of data is associated with every role.Provide a means for disaster recovery.Define permissions to control retrieval of a copy of the controlled master for software, data, and documentation.Define the method for determining whether the configuration data matches the minimal requirements.

>

>

>>

>

2,3. Ibid

If you don’t effectively prioritize CIs, you will find that you are storing a lot of useless information in your CMDB.

��

Tips for effective control of the CMDB include the following:

Implement a robust tool that allows you to store and manage information about CIs so that anyone can see the status of every CI and the history of incidents, problems, changes, service level agree--ments, etc.Be sure to consider the business rules and policies around the CMDB, so the in--formation will be consistent. Examples of business rules or policies include:

The change management process is the only process that allows modifica--tion of CMDB data.All the hardware CIs must have the “HW” prefix in the name.

Use a robust change management solution, integrated with the CMDB, for processing every IT infrastructure change. This will enable you to know which CIs are involved in every change, and to track all changes associated with a CI.Validate the CI information before updating the CMDB if you use a discovery system.

Define which attributes must be included in the comparison.Define what to do if a CI is discovered with changes.

>

>

–

–

>

>

–

–

Coordinate documentation efforts in advance of major hardware and software upgrades.Involve the asset management group for desktop equipment inventories.

If you don’t effectively control access to CI information in the CMDB you will find that CI data is changed without proper authorization, causing the data to be inconsistent. In addition, confidential information may be used for illegal or other purposes that are not aligned with the business. Incorrect CI data will also increase the time required to fix incidents. Ultimately, inconsistent CI data will cause your CMDB to be irrelevant in your organization.

ACTIvITY 4STATUSACCOUnTinGAccording to ITIL, this activity includes “the reporting of all current and historical data concerned with each CI throughout its life cycle. This enables Changes to CIs and their records to be traceable, e.g. tracking the status of a CI as it changes from one state to another for instance ‘under development,’ ‘being tested,’ ‘live,’ or ‘withdrawn.’” 4

>

>

Figure 1. Example of a Permission Schema

Type of CI Group Process Read

writ

e

PCsupport­hardware

Incident Management xProblem Management xChange Management xRelease Management x

support­softwareIncident Management xProblem Management

Microsoft

windows

server

support­hardware

Incident Management xProblem Management xChange Management xRelease Management x

support­Applications

Incident Management xProblem Management xChange Management xRelease Management x

support­Networking

Incident Management xProblem Management xChange Management xRelease Management x

4. Ibid

��

To perform this task, you will need to main--tain the status of CIs within the CMDB, as well as other related information, including:

Lifecycle state of each registered CIIncident, problem, change, and release history of each CIService level agreement with the busi--ness associated with each CI

This process of obtaining and maintaining status information can be manual or automatic, but we suggest that you use a robust config--uration management solution that supports CIs of varying complexity, such as entire systems, releases, single hardware items, software modules, or hierarchical and networked rela--tionships between CIs.

Your configuration management tools should facilitate the impact assessment of requests for change (RFCs) by storing information about the relationships between CIs. This will enable the status accounting to be auditable.

When an organization understands how important the CMDB is in supporting business needs, it will automatically publish on its intranet the status accounting of critical CIs stored in the CMDB, sorted by status and type. If users need to know the full status account--ing report, they can run the report manually.

Using the statistical results from this account--ing, you can find:

Behavior patternsBaseline and release identifiers Latest software item versions for a system build or application The number of changes for a system or IT component

>>

>

>>>

>

The number of baselines and releases The usage and volatility of CIs Comparisons of baselines and releases

Tips for effective status accounting include the following:

Use statistical reports from your configu--ration management solution or IT service management applications to assist with this activity.Have executive and detail reports that feed the business needs.Record vital statistics (for example, change requests) about the product.Filter status accounting according to the permission schema.Have flexibility for getting reports from the configuration management tool.

If you don’t effectively perform status account--ing and have IT managers review the reports, then you will lose control of the CI data. This will cause CIs to have an unknown state. You will also lose pattern identification, which means the CI data cannot be used to find the root causes of problems with CIs. Finally, you will lose information about changes and releases associated with CIs.

ACTIvITY 5 VeRiFiCATiOnAnDAUDiTITIL describes this activity as “a series of re--views and audits that verify the physical ex--istence of CIs and check that they are correctly recorded in the Configuration Management system.”5 In other words, this activity will help you to determine if the CMDB data is accurate.

You will need to perform audits of the following:

CIs that may have been updated without an associated RFCCI revisions that do not comply with the defined standards

>>>

>

>

>

>

>

>

>

Ultimately, inconsistent CI data will cause your CMDB to be irrelevant in your organization.

5. Ibid

�8

Revisions to software that may not be regis--tered in the defined software library, which will allow you to know the presence of unlicensed or non-tested software

Also perform verification when the following conditions occur:

A CI is associated with an incident, problem, change, release, service level agreement, operational level agreement, and under--pinning contractsThe relationship of a CI with its environment is being researchedThe history of the CI is being consulted

You’ll also need to verify activities performed by the discovery system. These activities will enable you to know when there are differences between the discovered information on a CI and the data stored in the CMDB.

Tips for effective verification and audit include the following:

Get your CIO’s support to help you make verification a “must” on a regular basis, year after year; make sure everyone is committed to the verification process be--fore beginning. Use reporting tools to help determine which CIs are not operating properly, or which CIs are actually being used. This activity will help you better align the CMDB to the needs of the business.Integrate your configuration management tool with a network monitoring and discov--ery tool to help to determine the quality of the data in the CMDB. Create an audit schedule based on how critical each CI is to the business. This ac--tivity is especially important if you use an automatic discovery tool.

If you don’t effectively perform verification and audit, you will have inconsistent data. The CIs in production will not match the description in the CMDB. You will also have unauthorized CIs in your CMDB (unlicensed

>

>

>

>

>

>

>

>

software, for example), and CI data will not match the minimum established requirements. Ultimately, if you have incorrect data in the CMDB, your IT organization will not use it.

ACTIvITY 6BACKinGUPAnDARCHiVinGTHeCMDBBased on our experience with CMDB projects, we add a sixth activity to the five configura--tion management activities outlined in ITIL.

Backing up and archiving the CMDB rests with the IT service management application. The frequency and method depend on the business objectives. However, you will need to back up the data from the RDBMS data handler, the platform on which the CMDB is built, the relationship between the CIs, any service level agreements related to the CIs, the application tools and other tools integrated with the CMDB, and the external information sources. Your configuration management tool can help with exporting and archiving this data.

The archiving activity refers to extracting information from the CMDB that is no longer useful for everyday activities, but that may be useful for audit and control purposes. You might be able to use the CMDB platform functionality. You will, however, need to define the rules under which the information archiving will take place. You might define the end life of each CI to determine when to archive. To determine which CIs or which information to archive, you might also ask yourself which CIs are critical to the organization.

Tips for effective backup of the CMDB include:Make sure your procedures for backing up the CMDB align to the business. For example, “The CMDB needs to have a full

>

Integrate your configuration management tool with a network monitoring and discovery tool to help to determine the quality of the data in the CMDB.

OFUSinGiTiL’SCOnFiGURATiOnMAnAGeMenTACTiViTieS

5 BeneFiTS

backup every Sunday at 12 a.m., before the start of the work week.”Keep a diary of the backups made on the CMDB, including the date and status of every backup, readily available. This task often is the responsibility of the configu--ration manager.Test the backups from time to time to ensure accuracy. Again, this task often is the respon--sibility of the configuration manager.Back up the CMDB structure when you first populate the CMDB and anytime you make changes to it.Perform delta backups of the data in the CMDB.

If you don’t effectively back up and archive the CMDB, be prepared to recover from hardware or software failure through other mechanisms. If your backups of the CMDB are ineffective, you will consume a lot of space with useless backups that either may not work when you need them or will restore the CMDB with in--accurate information. In addition, the CMDB may have security vulnerabilities.

A CMdB To suPPoRT BusINess NeedsDeploying a CMDB is more than storing infor--mation in a database. Use these six activities as a framework for your CMDB implementation, so you can achieve a useful configuration management process as well as a CMDB that effectively helps you support the needs of the business. Providing accurate and consistent information about CIs and their relevance to the business ultimately will enable the busi--ness to meet its goals. n

>

>

>

>

JavierLeyvanovoa is a new technologies manager at Quitze Tecnología. Javier is a Remedy Approved Consultant (RAC) and ITIL certified, and has advised numer­ous customers about ITIL, CoBIT, and BMC software products. he has been a trusted leader in complex projects supporting ITIL processes.

ABOUTTHeAUTHOR

Providing accurate and consistent information about CIs and their relevance to the business ultimately will enable the business to meet its goals.

Effective planning focuses the imple--

mentation and reduces the time to deploy the initial phase of the configuration

management process and the CMDB.

Effective prioritization of CIs will help you reduce data storage

costs, streamline data searches, encourage use of CMDB data,

and more easily manage and maintain

CMDB data.

Effective control of access to information

in the CMDB helps ensure the consistency

of CI data and the relevancy of the CMDB to your organization.

Effective status accounting helps you to control the CI data and track information about changes and releases associated

with CIs.

Effective verification and audit helps

ensure that your data is consistent, that the

CIs in production match the description in the CMDB, and that the CIs in your CMDB

are authorized CIs.

�0

Successfulimplementationandlong-termviabilitydependonhoweffectivelyyoumanagethehumanaspectsoftheCMDB.HerearesixtipsforincludingthehumanfactorinyourCMDBequation.

ByTiMMASOn

foreffectivelymanaging

“People”factor

the

I recently completed a configuration manage-ment database (CMDB) implementation at a major oil company. The implementation

of this world-class CMDB has been so well accepted that the company honored us with two internal company awards.

The implementation wasn’t without difficulty, however. In fact, one of the biggest challen ges to our long-term success was getting the “people” side of the CMDB equation right. The

implementation team tackled this challenge head on and overcame it.

Sophisticated technologies were available, and related technologies were evolving at a rapid pace. Discovery tools were becoming more thorough and more automated, and modeling tools were becoming more sophisticated. But these tools alone did not guarantee a successful implementation. We also needed to address and resolve the people issues.

��

��

CMdB: The PeoPLe ANGLeIf you’re like most IT professionals, you’re pre tty well convinced that your enterprise needs a CMDB. After all, understanding which IT assets make up the infrastructure and how those assets deliver business value is core to making business-focused decisions within IT.

And maybe your CIO is demanding better and quicker information about the effect of an IT change on the business, the impact of changing a sourcing arrangement, or the criticality of specific infrastructure elements on business processes. It’s also likely that you’ve spent a lot of money on one-off audits and cleanup exercises to gather and organize this informa--tion when you need it.

The answer to these challenges is to create a sustainable source of information and know-ledge that enables effective management of IT. In other words, implement a CMDB that is compatible with IT Infrastructure Library (ITIL®) guidelines.

In reality, however, maintaining a global source of knowledge on IT assets and their business value is a huge challenge. Multiple sourcing arrangements, organizational transfor mation, and IT asset migration all complicate the goal. A large percentage of critical information is not discoverable, and many enterprises finish a CMDB project only to discover that maintaining it is a nightmare. Some have resor t ed to large, centralized teams to manage and maintain data. Others simply fail to maintain it.

One of the biggest challenges to long-term success is getting the “people” side of the equation right.

So here’s a single thought to keep in mind th roughout your CMDB project: To a large degree, successful implementation and long-term via bility depend on how effectively you manage the human aspects of the CMDB.

Below, I’ll pro vide some guidelines on how to do just that.

TIP 1HOOKinTOexiSTinGPROCeSSeSYour enterprise already has a lot of IT processes in place: changes, installs, projects, handovers, and so forth. Our team found that adding Update CMDB tasks to each of those existing processes paid off enormously. By adding those tasks, we hooked into any existing process that resulted in changes that needed to be reflected in the CMDB.

To a large degree, successful implementation and long-term viability depend on how effectively you manage the human aspects of the CMDB.

The change process is an obvious place to begin. However, not everything you want to maintain in the CMDB falls under the scope of change control. Moreover, putting everything that does fall under change control into the CMDB can translate into an unworkable change process. A change of application owner or business contact, for example, may not be controlled by the change process. It does, however, represent a change that must be reflected in the CMDB.

We also looked beyond the change process to processes related to operational acceptance. We ensured that whenever a support group began to work on correcting an issue, the CMDB was updated to reflect the current state. We also embedded the data-center installation process — that is, the process of getting items into a data center and into a rack — as work--flow in the CMDB.

The real challenges are spotting the relevant processes and getting people to follow the new step.

��

TIP 2COMMUniCATeWiDeLYAnDTAKeATOP-DOWnAPPROACHCommunication that explains the value and benefits of the CMDB is vital to getting buy-in. Effective communication gives people insight into CMDB project goals and benefits. It can — and should — take a variety of forms, including e-mail campaigns, an intranet site, meetings, workshops, and training.

However, you can’t make things happen through communication alone. People quickly develop communication fatigue, and let’s face it, the life of an operations person is not full of spare time to attend training courses and worry about new tasks. Getting people to follow the right process and take responsibility for data on the configuration items (CIs) they know requires more than communication and more than training. We found we absolutely needed sup--port from the top of the operations organization.

The challenge here is that the people adding and maintaining data are often not the people benefiting from it. Too often, IT operations peo ple see the CMDB as an overhead or burden. Anything you can do to communicate how it will make their lives easier or add value for them is important to the success of the project.

TIP 3MAKeiTeASYTOUSe,GiVeSOMeTHinGBACKMaking it easy to update and maintain the CMDB and get data from it sounds obvious, but I want to stress that this is critical to the success of your implementation. Unless you pay attention to the user interface, you’ll end up with a CMDB that makes it difficult to find data and understand important relationships. When that happens, people aren’t inclined to use the CMDB — or keep it up to date.

We set a goal of ensuring that we weren’t making the CMDB any harder to use than it had to be. To achieve this goal, we dedicated time to building reporting tools, quick wild-card searches, and views for visualizing and navi--gating the CMDB.

The challenge here is that the people adding and maintaining data are often not the people benefiting from it.

While we mandated that people use the CMDB, we also recognized that mandates never win hearts and minds. So we also spent some time to make the CMDB especially useful to people who were adding and maintaining data. This often meant incorporating more CI types and attributes than were needed for configuration management purposes. These types and attri-butes, however, benefited key groups of users who maintained critical data, which gave them a stake in keeping data up to date. We also made sure that the core data that was critical to the enterprise was maintained globally, while data that was specific to certain groups didn’t need to be.

TIP 4eSTABLiSHDATAOWneRSHiPAnDCLeARMeASUReSClear accountability for data goes hand in hand with the process element. We found that every-one wanted information from the CMDB, but no one wanted to pay to maintain it. People pointed to the configuration management team and said, “It’s their responsibility.” Con--figuration managers, however, cannot own the data because they have no way of knowing if the data is accurate. They can own the pro--cesses related to checking accuracy, but not the data itself.

With this in mind, we built a model of data ownership with clear measures that put the onus of maintaining CMDB data on the people who know the data best. This involved imple--menting a network of data owners and data managers. The data managers are members of the support group for each CI. We aligned their roles to the data they need to support on a CI — for example, operating system support was aligned to operating system infor mation. Data managers are accountable to a data owner for data quality.

��

We incorporated data quality targets into con-tracts for third parties and established personal objectives for internal staff. The data owner acts as an escalation point to which configuration management can raise issues. We modeled all this in the CMDB. Now, when users click on a field, they can immediately see who owns the data.

TIP 5AUTOMATeDATACHeCKinGITIL audit and verification processes can be time consuming, so you need to give some thought to ensuring that you focus only on the data critical to the audit. To assist with this, we built in some automatic functionality that iden tifies missing data and basic errors, and notifies the appropriate data manager.

It’s important to understand that this function-ality does not validate fields during data entry. Why? Because when you force people to fill in a field to complete a process, they’ll resort to entering anything they can think of if they don’t have the correct information. They do this because they want to finish the task at hand

and move on to the next one. Obviously, this can wreak havoc with accuracy.

To overcome this problem, we included Unknown as a valid entry. By doing so, we allow people to complete a task even if they don’t have all the information required by the CMDB. The verification functionality picks up on the missing and unknown information and alerts the data manager that some action is required.

TIP 6USeAUTODiSCOVeRYAPPROPRiATeLYDiscovery tools play a vital role in manag--ing the detailed, complex information about hardware configurations, such as patch infor-mation, BIOS settings and dates, memory, and disk allocations. While important, this information represents only a fraction of the picture when asking important questions, such as “Whom do I contact to get approval to re--boot the VMWare server?”

The message here is that autodiscovery is criti-cal to providing an asset base with detailed configuration information. To make the leap to a successful CMDB, however, you need to understand that people and process are vital. So, use autodiscovery appropriately and don’t rely on it for all data.

PeoPLe PRovIde KeY To suCCessAs technologists, it’s easy for us to get caught up in the technology side of things when we approach a major project, such as a CMDB

We built a model of data ownership with clear measures that put the onus of maintaining CMDB data on the people who know the data best.

OFMAnAGinGTHePeOPLeFACTOR

5 BeneFiTS

implementation. We need to keep in mind that an effective CMDB implementation also involves people and processes. Too often in IT, we overlook the people side of the equation. By following the tips in this article, you can ensure that you effectively manage the human capital in your enterprise, so you can build your own world-class CMDB that’s worthy of internal and external awards. n

TimMasonis a founding director at TRM Associates, an information management consultancy firm. Tim brings deep experience and insight from an extensive background in management consulting at a leading u.K. consulting firm. while working in the industry, he has held inter­­national IT assignments spanning

europe, Australia, Asia, and the united states.

ABOUTTHeAUTHOR

Efficiency — If you automate data checking,

you can streamline ITIL audit and

verification processes.

Integrated process for updating CMDB — By adding Update CMDB tasks to existing pro--

cesses, you can create a hook to any process that results in changes that need to be reflected

in the CMDB.

Buy-in from stakeholders and participants — By communicating how the CMDB will

make their lives easier or add value for them, you can more easily

gain buy-in.

Up-to-date CMDB — If you make the

interface easy to use, people will be more inclined to use the CMDB and keep

it up to date.

Accountability — You can increase accountability by establishing data

ownership to create an escalation point

and by defining clear ways to measure

performance.

To make the leap to a successful CMDB, you need to understand that people and process are vital.

��

GetaheadstartonthemostdifficultissuesofCMDBdesignbyfirstexaminingfiveimportanttopics:configurationitems,federatedsystems,dataschema,discovery,anddataintegrationandreconciliation.Herearethequestionstoconsider.

ByDenniSDROGSeTH

COnSiDeRATiOnSFORACMDB

5 design

��

Your configuration management data--base (CMDB) can significantly empower your organization — once it is a con--

sistent, dynamic, and trusted data source that supports such objectives as change and con--figuration management, inventory and asset management, and service assurance.

The CMDB can enhance the alignment of busi--ness and IT. It can also help IT to reap enormous advantages in operational effectiveness by improving cost efficiency and service quality. And perhaps most importantly, the CMDB is a potential cornerstone not only for IT Infra--structure Library (ITIL®) process initiatives,

�8

but also for adoption of long-term IT systems management technology.

However, a CMDB initiative requires patience, perseverance, and a willingness to plan for multiple phases of deployment over months and possibly even years. You’ll need a set of achievable first-phase goals, and will need to choose your underlying architecture wisely.

In our May 2004 report “Next Generation Architecture,” we at Enterprise Management Associates (EMA) posed that management technology solutions, such as the CMDB, need the following: > Effective and non-redundant data gathering

across disciplines> A distributed or federated data store to

support multiple management disciplines> Cooperative analytic engines to flexibly

enable access to this data store> Role-based views of services to enable

real-time analysis and historical reporting > Targeted and validated automated actions> Dynamic mapping to service and busi--

ness objectives

A CMDB, as defined by ITIL, is process-centric, and as such, it can only imply these architec--tural goals. In fact, a CMDB-like capability would have become necessary in the industry even if ITIL had never existed. Many companies have already recognized that developing an effective approach to storing and sharing data in support of operational and business goals is becoming a top-of-mind requirement in its own right. In other words, the CMDB has architectural roots that are just as deep and meaningful as ITIL process objectives. Such an architectural approach to a CMDB can create the following benefits: > Efficiencies in data gathering — You can

gain structural efficiencies that will help you gather data from multiple sources for multiple sources in a consistent, coherent, and trusted fashion.

> Efficiencies in data analysis — Greater efficiencies in accessing and analyzing data

make it easier for IT to write and support multiple management applications.

> Foundation for policy-based automation — A foundation for policy-based automation can directly support your critical busi--ness processes.

> New model for product integration —You can more easily integrate products within single brands or suites, as well as across brands, when your architecture provides a model for product integration.

> Foundation for modularity — A structural foundation for modularity in management product design gives you greater choice, flexibility, and adaptability.

Your CMDB can significantly empower your organization — once it is a consistent, dynamic, and trusted data source.

BefoRe You desIGN: GoALs ANd oBJeCTIvesAs you begin your CMDB initiative, ask yourself the following questions:> What are the short-term and long-term

goals — including operational and busi--ness-related goals — I want to accomplish with a CMDB?

> How can I best quantify these goals?> What internal IT constituencies are affected

by these goals and objectives? > Which constituencies in the company need

to provide input to the CMDB initiative? > What external customer or consumer

constituencies are likely to be affected by these objectives?

> What outside supplier relationships — such as WAN services and application hosting, for example — will likely be affected by these objectives?

> What current IT processes will be affected by this CMDB initiative?

> What are the short-term and long-term CMDB requirements for my company?

> What do I need to do to prepare my IT organization for the cultural and process

�9

changes that a service management and CMDB initiative will require?

> What are the organizational implications of investing in a CMDB? For instance, to what degree will my IT organization evolve in focus and value to the business by leveraging the CMDB as a catalyst? What are the organizational implications of becoming more service provider–like and more accountable? For operational or business alignment reasons — or both — do I need to define a separately accountable organization around the CMDB?

Your answers to these questions will guide you through five design considerations that are integral to your CMDB deployment.

desIGN CoNsIdeRATIoN No. 1COnFiGURATiOniTeMSConfiguration items (CIs) are the entities that populate the CMDB or CMDB system, and are fundamental to the CMDB itself. CIs in a CMDB could include:> Network and systems hardware > System software, including

operating systems> Business systems and

custom-built applications> Commercial off-the-shelf packages,

standard products, and database products> Physical databases> Software releases> Configuration documentation, such as

system and interface specifications, licenses, and maintenance agreements

> Service management components and records, such as capacity plans, IT service continuity plans, known errors, and requests for comment (RFCs)

ITIL emphasizes that CIs are not isolated entities, but are interrelated components of a service management fabric. CIs are ultimately

important only insofar as they participate in the active support and delivery of business services.Successful CMDB deployments have clear, attainable objectives that are implemented in phases, adding breadth and depth over time. The initial discussion of what CIs need to go into the CMDB in first-phase deployments is therefore predicated on the goals of that phase.

To identify the focus for the initial phase, ask yourself which areas are priorities for your company’s CMDB initiative. Many CMDB initiatives address the following:> Change and configuration management> Disaster recovery planning> Security audit and compliance> Consolidation (business application,

server, and application)> Service assurance> Asset management> Capacity planning> Lifecycle application planning and

service planning

With your goals for the first phase as a guide, you can define the CIs that need to go into the core CMDB by using a model that has two axes. (See Figure 1.)

Low time sensitivity

High granularity of data

High time sensitivity

High granularity of data

High time sensitivity

Low granularity of data

Low time sensitivity

Low granularity of data

Gran

ular

ity o

f Inf

orm

atio

n

Time Sensitivity

Figure 1. Considerations for storing CI data

in core CMDB

Along one axis is time sensitivity and how often the CMDB needs to be updated. Along the other axis is granularity of information, or what EMA calls “atomicity.” Using these axes for CI planning, an IT organization might choose to keep inventory, topology,

Configuration items are ultimately important insofar as they participate in the active support and delivery of business services.

�0

and configuration detail in the core database, where time sensitivity is low and atomicity is high. On the other hand, granular and ex--tremely time-sensitive performance information might reside in one or more databases that have bidirectional integration with the CMDB. In this bidirectional integration, performance information could leverage relationship and configuration modeling in the core CMDB, while the core CMDB could be updated when critical services and CI components were de--graded or unavailable.

By prioritizing your first-phase objective in terms of change manage ment, service level management, inventory and asset manage--ment, or some other area, it then becomes possible to set initial objectives for CI require--ments which will, in turn, impact CMDB design.

desIGN CoNsIdeRATIoN No. 2FeDeRATeDSYSTeMSEven if first-phase CMDB deployments are single and centralized, most CMDBs will evolve into federated systems. As organizations need to accommodate many types of technology management investments, a CMDB will need to support not only multiple sources of data, but also different types of data from different vendors’ products. And because these various data stores are unlikely to follow the same data schema, federation is an effective design point for reconciling and integrating different types of data.

When planning a federated CMDB system, ask yourself questions such as these:> Which of my existing management tools

must be integrated into the CMDB? – Are these tools designed for, or sufficient

for, CMDB integration?– How reliably do these tools gather

accurate data? – How effectively do these tools deconstruct

data to show contexts for actions taken?> What standards are used in the management

technologies available to me and how committed are my vendors to standards for the CMDBs being considered?

> How do the vendors of my management products define federation, and is my investment protected?

> How do CMDB-related management prod--ucts integrate with other CMDB products?

Federation is an effective design point for recon-ciling and integrating different types of data.

> What are my priorities for CMDB federation?– Level of complexity versus quick

deployment? Many successful CMDB implementations build toward federation from a core, central CMDB that is sufficient for the initial CMDB task or discipline at hand, such as a CMDB focused specifically on change management for the data center.

��

– Level of complexity versus the near-term and long-term resources available for administration and support?

– Database design, performance, and scal--ability? In some cases, vendors replicate data; in others, data is accessed dynami--cally and reconciled through policies.

> How does the notion of federation map to:– Current processes?– Current or planned organizational dynamics?– Current or planned supplier relationships?

desIGN CoNsIdeRATIoN No. 3DATASCHeMAWhen you establish your data schema, which represents the content structure of your data, I recommend that you focus on phase-one requirements, while also keeping an eye toward a more comprehensive set of longer-term requirements. In the end, you’ll be more successful building from near-term accom--plishments than you will be spending many months, and possibly years, architecting a complete CMDB design before any real value is seen. Technologies and standards are both evolving, so in five years, your options for a complete CMDB system might be substantively different from today.

When planning data schema for the CMDB, ask yourself questions such as these:> What information can reside outside the

scope of my initial CIs but still relate to

those CIs? In many implementations, some resources, such as contractual information, asset-specific financial information, or trouble ticket details, reside outside the CMDB and are not treated as core CIs. The CMDB is linked to these resources so that it is updated when they affect critical parameters of CI status, such as service level agreement (SLA) violations or an open trouble ticket on a CI.

> What kind of modeling or schemas do my CIs require and at what level of complexity, in both the near and longer term? What kind of relationships must be captured and why? What standards are most likely to be relevant for me near-term and long-term?

> How dynamically and automatically can my CIs populate my CMDB?

> How can my CIs and their schema best optimize:– Immediate impact to services?– Immediate impact to consumers?– Automated triggers to operational policies?– Automated triggers to business policies?

> Is there a skill set required or a services tax to be paid for either integrating CIs or supporting complex modeling schema? Be sure to understand what your vendor provides and what you either need to do on your own or pay for through extra services. CMDB implementations can be complex, so one rule of thumb is never to invest in anything that you don’t first understand.

��

desIGN CoNsIdeRATIoN No. 4AUTODiSCOVeRYMuch information and insight about your systems and processes can be discovered in an automated fashion. Most autodiscovery tools are designed to gather specific information, and each type of discovery tool should be considered when you plan your CMDB. How you prioritize your autodiscovery capabilities will be influenced by the initial and future focus of your CMDB. Consider gathering information about the following, all of which can be relevant to the ITIL vision of the CMDB: > The physical and logical network> Systems and application components> Detailed configuration information for

each device or software component> Relevant modeling of infrastructure to service> Relevant modeling of service to

consumer population> Relevant modeling of business impact> Relevant modeling of associated depen--

dencies (service contracts and objectives)> Relevant modeling of operational depen--

dencies (who does what and when)> Relevant insights into consumer consump--

tion behavior so that operational and service planning can be optimized

Keep in mind that only some types of discovery will be needed for a CMDB core. Other infor--mation gathered through autodiscovery may more appropriately reside in federated data stores accessed by the CMDB.

desIGN CoNsIdeRATIoN No. 5DATAinTeGRATiOnAnDReCOnCiLiATiOnA CMDB demands integration across multiple sources, almost all of which have their own data stores and data schema. This multitude of data presents probably the single greatest challenge to planning and developing an ef--fective federated CMDB system.

Your system will require some level of data normalization, so that management applica--tions have a single, consistent way to access

data. Similarly, data normalization provides a common approach for representing CIs, so that services can be more effectively modeled. The data schema you choose for your core CMDB and the standards you adopt for appli--cation-to-application communication will dictate how data needs to be normalized throughout your CMDB system.

Data reconciliation is another challenge. Most IT organizations have many management tools that provide discovery capabilities that are redundant to one another. IT must reconcile the collective data so that the wealth of data is still available and the integrity and quality of the CMDB data is maintained as data is added, updated, and removed from the CMDB. Data reconciliation must address the unifica--tion of disparate data reported for the same CI. Data reconciliation must ensure that a CI is correctly identified, even if various manage--ment tools have named the same CI differently. Time dependencies and disparities of the data must be reconciled. And, finally, data recon--ciliation must maintain the ability to link and synchronize to extended data about a CI in response to a request from the enterprise level CMDB.

The greater the breadth of CIs supported, the greater the need to address data integration and reconciliation challenges in the near term. Prioritize your objectives, so you can develop a phased approach to meet the data integra--tion and reconciliation requirements of your CMDB system.

Most autodiscovery tools are designed to gather specific information, and each type of discovery tool should be considered when you plan your CMDB.

5TiPSFORCMDBDeSiGn

Data reconciliation must address the unification of disparate data reported for the same CI.

effeCTIve desIGN: CMdB As eNABLeRBy carefully considering your needs for con--figuration items, federated systems, data schema, discovery, and data integration and reconciliation, you can better ensure the effective design of your CMDB. A successful CMDB deployment will create a consistent, dynamic, and trusted data source that will enable new process efficiencies within and across your IT organization. n

DennisDrogseth,vice president, enterprise Management Associates, directs a team of analysts that focus on the development of networked services management. he has pio­­neered research in management strategies such as performance and availability, integrated security, changing organizational dynamics

in IT, and enterprise and service provider management issues. he has a Bachelor of Arts degree, magna cum laude, from Yale university.

ABOUTTHeAUTHOR

Be flexible in applying ITIL best practices,

using ITIL as a catalyst rather than a religion.

Be willing to re-evaluate your CMDB progress based on checkpoints

and results.

Be aware of technology options and how they support both process

and architectural requirements.

Focus carefully on the definition and

scope of CIs.

Follow open — not proprietary and

unpublished — data schemas.

��

ByFReDeRieKeC.M.WinKLeRPRinS

Getting things right at the outset of a service management initiative — in the process definition stage — is

vital to the success of the overall project. Many have turned to IT Infrastructure Library (ITIL®) processes to guide them in delivering and supporting their services. And while ITIL provides useful theoretical guidelines, it does not define the process flow.

Consequently, enterprises are struggling through the process definition phase, parti-cularly when in the midst of a configuration management and a configuration manage--ment database (CMDB) initiative. There is

good news, however. You can hit the ground running with your configuration management and CMDB initiatives by starting with a best practice process model.

At Service Management Partners, Inc. (SMP), we use a best practice process model to enable IT service providers to implement the CMDB, as well as configuration management and the other service support processes, in just 12 weeks. This comprehensive process model incorporates not only the ITIL guidelines but also the feedback from our partners and customers, who have contributed their ideas over the years to make it even better.

Usingabestpracticeprocessmodelspeedsupthedefinitionphase,whichreducescostsandhelpsyoutohitthegroundrunningwithyourconfigurationmanagementandCMDBinitiatives.

YOURCMDBiMPLeMenTATiOnWiTHAccelerAteABeSTPRACTiCePROCeSSMODeL

��

��

The sTANdARdIzed PRoCesses ChALLeNGeA well-defined process spells out roles and responsibilities down to the work instruction level. It defines the order of process steps, inputs and outputs of each process step, and the specific work tasks and functions performed at each step. A good process ensures that everyone who performs a given task does it in the same way, knows what to expect as input from the previous step, and delivers consistent output to the next step in the flow.

As a result, well-defined processes enable high-quality service delivery and accurate and detailed reporting that provides visibility into IT performance across the enterprise. More--over, well-documented processes support compliance with government mandates and industry regulations, often eliminating weeks of manual effort required to gather and collate

information for audits. Figure 1 illustrates the generic process model, as defined by ITIL.Defining and standardizing on process flows across multiple groups within IT can be a grueling and time-consuming effort. You must get the right people together, which means setting up meetings with representatives of all the groups that provide input, are respon--sible for process activities, or rely on output, and then getting consensus on a common process definition. Typically, each group already has its own way of doing things and may not be focused on integration with other groups and processes. Each group may have its own quality initiatives and may have fine-tuned its isolated procedures. Convincing people that they should change their way of working so they can integrate with other groups is not easy. Political allegiances often come into play, making it difficult to agree on a stan--dard approach.

Figure 1. The Generic Process Model Source: ITIL Service Support Appendix B: Process theory and practice, page 273

Process

ProcessControl

ProcessEnablers

Activities andSub-Processes

Quality Parametersand Key

PerformanceIndicators

ProcessOwner

ProcessGoal

Resources Roles

Input and InputSpecifications

Output and OutputSpecifications

��

how A BesT PRACTICe PRoCess ModeL heLPsA best practice process model combines field-proven processes with practical, detailed, and specific instructions on how enterprises sup--port and deliver their services. Starting with such a model doesn’t mean you eliminate the process definition phase of your service man--agement initiative. You still need to get the right people together in a room to review and agree on processes. It’s a different kind of meeting, however, because people recognize that the model represents processes that are already integrated and generally accepted as industry best practice.

The goal of the meeting is to see if there are improvements or changes that should be made to the model to optimize it for the unique needs of the organization. This eliminates a lot of

political hurdles and resistance to change. If someone suggests deviating from the model, the discussion more appropriately centers on the expected benefits to the enterprise that justify the additional cost to implement such variations.

Figure 2 shows a basic process flow for up--dating configuration items (CIs). This process would be represented as a single step in the change management process diagram. Your organization may need to modify this flow to meet a specific need or requirement. For ex--ample, if your requisition system supports automated CI registration, your team might decide to include CI registration as part of the CI requisition step, instead of as a separate process step. Your team can decide what spe--cific modifications are needed to support your unique requirements. All in all, it is definitely more efficient to spend precious time evaluating various process modifications than starting from scratch.

If you do start from scratch and don’t use a best practice model for your CMDB or con--figuration management initiative, you may

A best practice process model combines field-proven processes with practical, detailed, and specific instructions on how enterprises support and deliver their services.

Yes

Yes

Yes

Yes

No

No

Registration or update of contract required?

No

Update of existing Cls requested?

From ChangeManagement

To ChangeManagement

No

NoYes

Update of supplier information required?

Requisition ofnew Cls requested?

Cl Requisition

Registration ofnew Cls requested?

1

Cl Registration3Supplier InformationMaintenance2

Cl Update4

ContractAdministration5

Figure 2. Example Process Diagram —Configuration Item Update

�8

find that: a) you can’t get agreement from all the stakeholders on basic process flows and definitions, b) the various process flows may not integrate, and c) the service management applications you select may not be able to sup--port these custom processes without months of expensive application customization effort.

This best practice process model approach speeds up the definition phase, which reduces costs and enables you to begin reaping the rewards of a working configuration manage--ment process and CMDB more quickly.

The IMPoRTANCe of TooL INTeGRATIoNOnce the process definition is complete, you need to implement software that both auto--mates and enforces the agreed-upon process definitions. This implementation can turn into a lengthy and costly effort if the underlying software tools were not considered during the process definition phase. A best practice model that takes into account out-of-the-box software setup ensures that the software will support the standard processes your organization estab--lishes with little or no customization.

In cases where you have adjusted the model to accommodate the needs of your enterprise, you may have to make minor modifications to the tool. Minimizing the amount of customiza--tion, however, saves you time and money, makes for an easier upgrade path in the future, and no less importantly, reduces your risk.

While almost all ITIL service support and service delivery processes utilize tools that draw on the CI data in the CMDB, certain processes and tools utilize shared data more frequently. (See Figure 3.)

For example, the change management process relies heavily on CI data to identify related CIs and services for risk and impact analysis activ--ities. Standard work instructions predefined in the process should identify what specific CMDB data is needed at each process step.

You need to implement software that both automates and enforces the agreed-upon process definitions.

ProcessandTool CMDBDataUsage

Incident management CIs supporting the affected service and their relationships are used to decrease resolution times.

Problem management CIs and their dependencies are used to facilitate root cause analysis.

Change management CIs and services related to a change request are used to optimize risk and impact analysis.

service level management CI information is used to determine service dependencies.

Continuity management CI information is used to capture infrastructure information to be used if disaster strikes for one or more services.

Availability management CI information is used to track service availability.

Capacity management CI information is used to plan and track capacity utilization per service.

Figure 3. Process and Tools Most Dependent on CMDB Data

�9

AddITIoNAL KeYs To suCCessOnce you’ve created well-defined processes and automated them as much as possible, you should consider other critical success factors that help ensure the adoption of IT service management processes. They include main--taining data accuracy, monitoring and measuring performance, accommodating the needs of multiple groups, and training people on processes and tools.

Maintaining data accuracy. Applications and people that follow a standardized process both consume and generate data. If the data is not accurate, then the process may not perform as designed. You can ensure accuracy by clearly identifying what data is created and consumed at each process step, and by making the right people responsible for maintaining data accuracy.

Who are the right people? If the data is stored in the CMDB, then the right people are those who stand to gain the most from ensuring that a particular set of CI data is up to date. For example, the desktop support group needs information on the configuration of desktop and laptop computers. Consequently, that group has a stake in keeping desktop and laptop information current. Other groups

might include the Microsoft Windows server group, UNIX server group, and application development group. The bottom line is that you need to look at the CIs for each IT process, and assign responsibility for maintaining relevant CIs to someone in each group.

Monitoring and measuring performance. Enterprises often get so focused on imple--mentation activities that they forget about measuring performance. However, a best practice process model should include de--fined performance measures for overall process quality. Processes that utilize CMDB data should include the definition of key per--formance indicators (KPIs) that allow the IT organization to measure the success and effectiveness of a particular process. KPIs set the stage for ongoing adjustments that drive IT efficiency and make CMDB data more complete, more accurate, and more valuable. Figure 4 shows one example of a standard KPI for configuration management.

Also consider other critical success factors that help ensure the adoption of IT service management processes.

Figure 4. A Standard KPI for Configuration Management

KPi Definition Frequency Unit

Time required to up­­date CMdB

The average time it takes to get the status of a CMdB update task from “scheduled” to “Closed”

Monthly Number of work hours

�0

Accommodating the needs of all stakeholders. As enterprises implement configuration management and a CMDB, it’s essential to make sure that all the process owners and all groups that use the best practice process model continue to be involved in refining the processes and determining which CIs and CI attributes need to reside in the CMDB. Each service management discipline has unique needs for CI information.

If each group doesn’t have a voice in the imple--mentation or in any changes that occur, two problems can arise. First, the information needs of one or more groups might not be incorporated into the CMDB, which makes the CMDB less relevant for them. Second, the opposite could also occur, whereby one group makes assumptions for another group about their data needs. This leads to a CMDB populated with either unnecessary or too much data, making it more difficult and time-consuming to maintain.

Training on processes and tools. Lastly, and equally essential, enterprises need to ensure that they have time in the schedule and money in the budget for training. Training that covers process awareness, as well as how to use supporting tools, fosters broader organiza--tional acceptance and makes the transition to new or changed ways of working easier.

ResuLTs ThAT sPeAK foR TheMseLvesA best practice process model is a time-saving and money-saving shortcut to successful service management. SMP customers are saving at least four months of process defi--nition effort by using a standard model.

Using a best practice model accelerates the process definition phase, which not only en--ables you to begin realizing the benefits of the CMDB more quickly, but also reduces staffing costs by saving hours spent on the project. Once you have the CMDB in place, you can focus more of your efforts on im--proving your service to the business you support — and supporting the business is what it’s all about. n

FrederiekeC.M.WinklerPrins is a certified ITIL Master with more than 15 years of experience in the delivery of IT service management solutions to leading corporations and government agencies around the globe, including Avaya, dhL, Philip Morris, dutch Ministry of Justice, and the Royal British Navy.

she lectures regularly on the topic and co­founded service Management Partners (sMP) in 1998.

ABOUTTHeAUTHOR

Training that covers process awareness, as well as how to use supporting tools, fosters broader organizational acceptance.

5TiPSFORCMDBSUCCeSS

Establish efficient, repeatable processes,

including roles, responsibilities, and

individual tasks.

Define processes that take into account

the software tools that will support and

enforce them.

Monitor progress and measure results to identify areas for

improvement.

Give stakeholders responsibility for

keeping their own CI data up to date.

Provide training to ensure process

awareness and knowledge of how

to use the tools.

PeOPLe:

PeopleprovideinsighttobusinessprocessesandcreatealinktotheiTinfrastructure,helpingyoudevelopanaccurateservicemodel.

TheKeytoCRACKinGtheiTServiceModelCode

ByALexAnDReAVeLAR

��

��

Mapping IT service models for your configuration management data--base (CMDB) may seem like a dif--

ficult code to crack at first. Automated tools can facilitate collection of some of the infor--mation you need about the IT infrastructure, so you can build service models. Nonethe--less, it is the people in your enterprise that are the key to creating business relevance and cracking the service model code.

In a technology implementation, it’s some--times easy to get caught up with just that — the technology. However, in defining a service model, you also need the insights of experts and specialists from across the company who understand how the business process works and can create a link back to the IT infrastruc--ture. In essence, people can help you decode the IT service model puzzle and ensure that the model you create accurately represents the final process you want to implement.

To effectively gather information from a variety of people and groups, you will want to create a collaborative working environment. In addi--tion, you’ll need to ensure that your method--ology respects people’s other priorities and time commitments. In short, strive to get as much information as possible, in as little time as possible, so you don’t unduly interfere with people’s normal work activities.

CoLLeCTING INfoRMATIoNIf you are responsible for managing a CMDB project at your organization, your job is to collect the insights and knowledge of all groups that will use and benefit from the CMDB. Then, you must use this information to:> Create an accurate model of configuration

item (CI) dependencies and information linkages throughout the IT infrastructure, systems, and applications, and the busi--ness processes they support

> Facilitate collaboration among business users and IT professionals

> Allow immediate visibility of information workflow paths, CIs involved, conflicts, omissions, and weak points

As you go through the process of creating a service model, you need to encourage user participation and capture detailed process knowledge that will help establish a common language and unrestricted collaboration. Through ongoing dialog with all stakeholders, you can uncover real or perceived discrepancies and misconceptions in the current workflow model, and drive a heightened degree of common understanding among the process stakeholders. What’s more, you can create an opportunity for making the workflow more efficient and secure.

The people in your enterprise that are the key to creating business relevance and cracking the service model code.

As you create your model, intensive revision and reiteration will be required to identify all the right elements, attributes, and relationships, and to position them correctly in the service workflow chain. The complexity of most IT service models — from basic infrastructure to systems, databases, applications, services, users, and finally, to lines of business — requires constant change in the mapping process, until you have a final model that satisfies all stakeholders.

soLvING The PuzzLe: foCus oN The seRvICeCSC BRASIL recently mapped service models for a telecommunications company. The first business process we tackled was billing. There are many aspects to billing, so we divided billing into several subprocesses and started with the prepay subprocess. Even this one aspect has many facets, including multiple entry points, varying cycles, and links to many applications and databases.

5TiPSFORMAPPinGSeRViCeMODeLS

Our key contact was the client’s project manager, who identified the people who fully understood the process and the infrastructure components that support it. They included:> Process analyst — Understands the enter-

prise processes and uses this ability to map business processes

> Billing specialist — Manages the billing application and databases, as well as other applications that connect to the billing application

> Server software engineer — Has a view of the logical connections between servers, clustered and high-availability environments, and how service applications run

> Network specialist — Identifies which servers and network devices support the service, as well as the relationship between those servers and network devices (i.e., routers, LAN, WAN, etc.)

> Help desk administrator — Understands the relationship between events and the help desk notification process

To develop and document a complete service, you need to ask the right people a lot of questions.

By conferring with these experts, we gained insight into the multiple touch points between the prepay subprocess and the IT services upon which it relies. For example, people pre--pay either by purchasing prepaid cards using their credit card or by withdrawing directly from their bank accounts. Each payment method has different applications and IT systems supporting it. We learned how the servers are connected, clustered, and configured for the different payment methods. We learned that there are five cycles in the billing sequence and that each runs at a different time of the month. The model had to accurately represent each entry point, cycle, job schedule, and so forth.

Along the way, we worked with all stakeholders to fine-tune the model, uncover discrepancies, and correct errors. The end result was an ac--curate representation of the service that clearly showed what IT infrastructure was involved in supporting the prepay process.

Our final billing service model mapped every aspect of every subprocess — from the custo-mer’s request for the service to the comp letion of the billing for that request. Each person brought their own unique perspective in helping us decode the overall billing service model.

PeoPLe ARe The KeYAlthough automated tools are critical to map--ping infrastructure relationships that are stored in a CMDB, always keep in mind that people play a vital role in that mapping process. Dis--covery tools can collect information regarding components, such as infrastructure devices, configurations, and applications, but do not generally identify the relationships and rele--vance to the business. This information resides in people’s minds and is constantly changing. To develop and document a complete service, you need to ask the right people a lot of ques--tions. Also, remember that the service model of a particular type of business process will not be the same for all companies. You must create a unique service model for each unique situation, based on the business process requirements. n

AlexandreAvelar,a consultant with CsC BRAsIL, has a bachelor’s degree in mathematics from Rio de Janeiro state university and a bachelor’s degree in software development from estácio de sá university. he has 19 years’ working experience with mainframe and distributed system environments.

for the last 17 years, he has been involved with event management, and the last three of those years, he has focused on IT service management.

ABOUTTHeAUTHOR

Focus on a single process or subprocess.

Identify experts in a variety of roles

across the enterprise who understand the

process and the infra--structure components

that support it.

Ask the experts for specific detailed

information about their particular area

of expertise.

Take an iterative approach, revising and correcting the

model based on input from the experts.

Remember that the service model for

a particular business process will not be

the same for all companies.

��

You’ve decided to implement IT service management (ITSM) and a configura--tion management database (CMDB),

but now what? Where do you begin?

IT Infrastructure Library (ITIL®) best practices recommend that you start at your greatest pain point or where the greatest benefit can be gained. Incident management, problem management, change management, and the CMDB are the most common areas to start, and from a theoretical perspective, that makes sense. However, I contend that the place to start is with the definition of services.

vIsIoNs foR ITsM suCCessA service is essentially a human concept. There’s nothing you can point to and say, “This is a physical service.” A service is a collection of physical entities, activities, and roles to help provide a cohesive service to a customer.

start with service definitions andReapSuccess

ByBRADYORAnDBeginyourCMDBinitiativebydefiningyourservices,andincreaseyoursuccess.Thisarticleshowsyouhow.

��

��

IT service management is all about managing services — hence the name. Without the proper definition of services in the organization, all other ITSM initiatives, including the CMDB, will encounter difficulties.

When implementing any project, the first step is to establish your vision. Your vision can be either broad or highly specific. Making it spe--cific, however, enables you to better determine how your initiative is meeting its objectives and aligning to your vision. Therefore, for an ITSM initiative, your vision should align to the concept of services. People, processes, and technologies work together to provide services for your customers.

Many decisions in an ITSM implementation will be far easier if you have already defined the services involved. When you implement incident, problem, or change management, for example, you have many decisions to make. If you don’t look at the big picture of where you’re going, you will have to go back and rework those decisions once that vision is clari--fied. So if you start with an understanding of the services you are offering, then there’s less rework later.

Most IT organizations today are still in the technology phase — providing technology to support business. Most IT personnel are technologists first. They naturally want to im--plement technology and look at things from a technology standpoint. So, when defining services, you need to think differently — start looking at the real role of IT team members based on what IT does to support the business functions of the organization. For example, an employee’s title may be “database adminis--trator,” but this person’s role in the company is not limited to managing the database; rather, he or she supports financial operations, performs order fulfillment, or supplies the production line — whatever business service the data--base supports.

When adopting various ITIL processes, organi--zations face some common questions:> How do we classify incidents?> How do we communicate trends

to the business?> How do we know who the business

owners are?> What models do we need in our CMDB?> How do we organize the CMDB?> On what criteria do we base our reports?> Where should we send our reports?> Who do we talk to before implementing

a change?

People, processes, and technologies work together to provide services for your customers.

These questions and others can be answered more easily if they are considered in the context of their relationship to the business. Under--standing services also begins the culture shift within IT from a technology provider to a true service provider. The very exercise of defining and communicating services begins to trans--form the level of thinking about IT throughout IT and the business. It also improves the re--lationship between IT and the business that IT serves.

All too often, organizations that get excited about ITIL start a variety of initiatives to imple--ment various processes in their environment. One organization I worked with was in the midst of implementing change management, incident management, and problem manage--ment in parallel. However, these three parallel endeavors were being undertaken in three separate groups — without any communica--tion among them. In this case, the processes may have worked well within themselves, but the interactions between them likely would have been difficult, misaligned, and error prone.

After beginning its parallel endeavors, this or--ganization decided to develop a service catalog. During the discussions of services offered, IT leaders realized that they needed to re-evaluate

��

some of their earlier decisions. As a result, all three of the initial groups modified their individual processes based on whether the change request, incident resolution, or problem root cause analysis was related to a prioritized service. The interaction of those processes was dependent on the type of service offered, as well.

Although defining services may not completely solve this communications gap, it will go a long way toward establishing the vision for all of these endeavors and helping to ensure that they are consistent.

sTePs To CReATING seRvICe defINITIoNsWhen I help companies to create service de-finitions, first I gather all the IT stakeholders together and ask them what services they pro--vide to the business. They usually start saying things like, “We do change management,” or “We do patch management.”

I turn the conversation into a business discus--sion, and ask them to define the services that the business consumes. For example, a business does not buy change management or incident management. A business buys the ability to provide outstanding customer service or the ability to efficiently fulfill orders or to keep its production line operating smoothly.

Defining services is an exercise in getting dif--ferent minds to meet. IT needs to realize that the business doesn’t care about the details of patch management, change management, intrusion detection, or virus detection. Even though these are vital activities performed by IT, the business is not really concerned with

them. Rather, the business is focused on com--pleting its critical business processing. But if those critical IT activities weren’t performed, then the business would most definitely care — because their critical business pro--cesses would not be operating effectively.

When working with customers, I essentially run a brainstorming session with the stakeholders. Anything that IT does falls underneath one of the five basic services that occur within a business. (See sidebar.) We can identify what a company manufactures, for example, and we can identify the services that support manu--facturing. We might break down those services further so we can get more detailed reporting and understand exactly what IT is doing to help support the business.

If you start with an understanding of the services you are offering, then there’s less rework later.

The next step is for IT to identify its business partners, its customers, and the people who can affect change within IT from a business standpoint. Then IT says to these groups, “Here are the services we think we offer you.” For example, IT might say, “We provide you with this ERP system so you can effectively manage your financial system.”

The business might come back and say, “We don’t care about the ERP system. We only care about being able to get our jobs done, which includes order fulfillment. As long as it’s easy and it works, we don’t care what the back-end technology is.”

This discussion usually occurs with the owner of the service, otherwise known as the “customer.” It’s important to distinguish between a user and a customer. A user is a person who interacts with a service on a daily basis. The customer is a person (or department) who funds the service — paying money for that service on behalf of their people.

A business does not buy change management or incident management. A business buys the ability to provide outstanding customer service or the ability to efficiently fulfill orders or to keep its production line operating smoothly.

�8

Finally, we ask the executive team to identify the top three or top five services that support or enable their business strategy.

After focusing on the list of services — iden--tifying the services IT is offering and the cus--tomers it is serving — it becomes obvious to the people involved what the next steps are.

eLeMeNTs of A seRvICe defINITIoNA simple service definition might include the following: > Name> Description> Customer> User

5 BusINess seRvICesIn most businesses, five basic services are being provided:> Manufacturing — The process

used to create the product or service offered to the end customer

> Sales — The functions used to find and close business

> Order fulfillment — The process used to deliver the product or service to the paying customer

> Product support — The functions that make sure customers use the product and receive value

> Administration — Back-office functions, such as human resour ces, payroll, and finance, that keep a company running and executives out of jail

Service Customers

Service UsersBusiness

Service Publication

Communication

Delivery of Services

Support of Services

Service Definition

Service Modeling

Service Desk

FulfillmentSales SupportProductAdministration

Service Catalog

Supporting ITIL Processes

Configuration Management DatabaseCMDB

Start with a critical business service and then build out the service model or the dependencies within the CMDB that go behind that service.

Figure 1. Foundations of Service

5TiPSFORSTARTinGWiTHSeRViCeS

A more advanced service definition also might include such details as the business process that relies on the service and the promised service level. From these definitions, a more compalete service catalog can be developed as the service management initiative evolves.

veRTICAL sLICes foR BuILdING The CMdBFigure 1 shows the relationship between IT services, ITIL processes, and the CMDB. At the top level, the service catalog communicates IT services to the business. The next level is the service desk and the processes that communi--cate through it. At the bottom is the CMDB that supports all of those processes.

When developing a CMDB, you can be particu--larly effective by taking a vertical approach: Start with a critical business service and then build out the service model or the dependencies within the CMDB that go behind that service. You want to build one vertical slice first — from the network layer all the way up to the service — to make sure that model works, and then apply those lessons to different services.

Your service definitions will help you in making decisions for other IT service management processes, as well. For example, establishing the categories, types, and items (CTIs) for in--cident, problem, and change management can be made far easier once these services have been defined. In addition, basing your CTIs on services can improve your reporting capabilities.

As an example, suppose that an incident has been detected in your environment. If you describe the overall service first and drill down into the incident to determine whether it’s hard--ware or software, then you can use the physical

configuration item (CI), which is located in the CMDB, to determine exactly where that inci--dent occurred. At the end of the month, for each customer, you can generate the list of incidents that this customer experienced that month and the problems you resolved. You can also report the changes made to the various services this month for each customer. These reports help IT show the value it provides to the customer who’s paying for IT services.

Once the services have been defined, you will find that all other ITIL endeavors will flow far more easily through improved decision-making. These endeavors will also be better aligned with the long-term vision as well as with each other — and, as a result, the culture will begin to shift from a technology organization to a true service organization. n

BradyOrandis an IT service manage­­ment practice manager at Column Technologies Inc. Brady has more than 15 years’ experience in various aspects of IT service management, from development to consulting with large organizations. he is ITIL service Manager certified and is actively involved in supporting IT service management.

ABOUTTHeAUTHOR

Start with a list of basic services and drill

down from there.

Identify your business customers early.

Communicate with the business customers.

Build one vertical slice first, from the network layer all the way up to

the service.

Make sure the first model works, and then

apply those lessons to different services.

Once the services have been defined, you will find that all other ITIL endeavors will flow far more easily through improved decision-making.

DemystifyingCOnFiGURATiOn

Theconfigurationitem(Ci)isoneofthemostnecessary,yetproblematic,conceptsiniT

governance.itishighlyabstract:Anymanaged“thing”intheiTenvironment—froman

individualcomputerchiptoanentiremainframe—canbeaCi.Thisarticlehelps

sortthroughiTiL’svaguedataarchitectureandhelpspresentasimplifiedwayofcategorizingCisthatisusefulindesigning,populating,and

managinganeffectiveCMDB.

ByCHARLeSBeTz Items

80

8�

Anumber of process frameworks are currently available to assist you in effectively managing your IT infra--

structure: Control Objectives for Information and related Technology (COBIT), Capability Maturity Model (CMM), and the IT Infrastruc--ture Library (ITIL®). They provide a common language and accepted set of practices, des-cribing overall IT capabilities and processes.

However, there are limitations to pure process-centricity. When one is architecting systems (defined as combinations of people, process, and technology), the concept of data is critical. The frameworks imply shared data, but they do not go far enough in specifying concepts needed to implement a shared data model.

From an enterprise architecture perspective, the consequences of this are clear: Processes can’t be fully optimized because the “things” that the processes are managing are still unclear to the process stakeholders. In many cases, redundancy is the result: two processes may be managing the same thing, but calling it by two different names. Or, very different things may be lumped inappropriately together in a given process context — a particular problem with the configuration item (CI) concept.

exPLoRING ITIL CI defINITIoN shoRTCoMINGsThe ITIL definition of a CI is as follows: “Component of an infrastructure — or an item, such as a Request for Change, associated with an infrastructure — that is (or is to be) under the control of Configuration Management. CIs may vary widely in complexity, size, and type, from an entire system (including all hard--ware, software, and documentation) to a single module or a minor hardware component.”

The above sentences are imprecise from a data management point of view. Essentially, the CI, as it is viewed by ITIL, could be construed as any piece of data representing any IT concept. The phrase “item, … associated with …” extends the CI concept unmanageably —

every data element in the IT problem domain becomes a CI. There is then a paradox; if a Request for Change (RFC) is a CI, and a CI, by definition, is under Change Management, that means the RFC requires an RFC requires an RFC and so forth ….

The high level of generality makes the CI concept difficult to manage from the perspectives of process, data, and application.

Here is the ITIL specification as it describes the inter-relationships of CIs:

“Configuration structures should describe the relationship and position of CIs in each structure …. CIs should be selected by apply--ing a decomposition process to the top-level item using guidance criteria for the selection of CIs. A CI can exist as part of any number of different CIs or CI sets at the same time …. The CI level chosen depends on the business and service requirements.

“Although a ‘child’ CI should be ‘owned’ by one ‘parent’ CI, it can be ‘used by’ any number of other CIs ….

“Components should be classified into CI types …. Typical CI types are: software prod--ucts, business systems, system software …. The life-cycle states for each CI type should also be defined; e.g., an application Release may be registered, accepted, installed, or withdrawn ….

“The relationships between CIs should be stored so as to provide dependency infor--mation. For example, … a CI is a part of another CI[,] … a CI is connected to another CI [,] … a CI uses another CI ….”

This is again highly general. One issue in the industry is that some vendors have interpret--ed this specification to allow their end users too much freedom in defining CIs and their relationships. In some tools, a server might be “a part of” a RAM chip; a printer might be

8�

“connected to” a data model — connections that obviously do not make logical sense.

The high level of generality makes the CI concept difficult to manage from the per--spectives of process, data, and application. More rigor is necessary. This analysis refines the ITIL represen tation and makes it more specific by applying data modeling (metamodeling) principles.

A fINeR PoINT oN CIsI believe a better definition of a CI itself is quite simply “A managed, specific object or element in the IT environment.” A CI, by definition, is under change control. A CI’s lifecycle, while it may have stages, is also typically undefined in terms of time — unlike a Project or Incident, which are managed primarily in terms of prog--ress through their lifecycles and ultimate closure.

Servers and applications can have Incidents

and Known Errors – but can a Contract?

That means that certain things are not CIs, for example: > Events> Incidents> Requests for change> Projects> CI records (the representation is not

the object)

CIs should always be specific. “Oracle Financials,” if present in the environment, would be a logical CI, containing and using many physical CIs (e.g., software components and datastores). A Gener--ic “Human Resource Management Application” as a reference category would not be a CI.

Figure 1. Detailed Configuration Item Taxonomy

Conceptual Model Inheritance

8�

CIs have subtypes, and those subtypes in turn can have subtypes. Figure 1 illustrates one representation. The major types of CIs are:> Base CI> Operational CI> Production CI They are “nested,” which means that an Opera--tional CI is also a base CI, and a Production CI is also an Operational CI as well as a base CI (Figure 2).

Configuration Item

Conceptual Model CI Subtypes

Operational CI

Production CI

Figure 2. CI Subtypes

Subtyping is often over-applied. An important reason to subtype (in conceptual modeling) is if a subtype can have a relationship in which the parent does not participate. Figure 3 shows this clearly: A Change can apply to any CI or sub--type, a Measurement Definition can apply to an Operational CI or a Production CI, and an Event can only be associated with a Production CI.

These major types of CIs and their allowable relationships are shown in Figure 4.

This is a simplified representation compared to some industry standards; it is a conceptual model seeking to concisely cover a broad spectrum of IT concerns. It’s primarily about refining language and concepts. The goal is not technical precision, but rather resonance with common industry usages, which overlap and

are not well delineated. It’s an attempt to push common usage towards more rigor. It also deliberately omits a number of technical as--pects that would ultimately be necessary to realize a solution.

Note that there are other representations of IT data, such as standards from the Object Management Group (OMG), Distributed Management Task Force (DMTF), and Tele-Management Forum (TMF). This article represents a much simpler framework as compared to these highly complex standards.

TYPes of CoNfIGuRATIoN ITeMsThe base CI is the master category to which all CIs belong. It is any “thing” in the IT environ--ment that requires management (usually defined as being under change control of some sort).

CIs have differing levels of involvement in day-to-day service management and production processes. The base level CI includes docu--mentation and the definitions of service level measurements, objectives, and agreements. Any type of CI may be involved in an RFC; however, change control for items that are not Production CIs (i.e., Operational or Pro--duction) may or may not be formalized. For example, the service management group may

Conceptual Model CI

Figure 3. CI Subtypes and Key Relationships

8�

Figure 4. Major CI Types, Supporting ITSM Entities, and Their Allowable Relationships

define service offerings, or the asset manage--ment group may add new assets, without going through the highest-formality change processes reserved for Production CIs.

CIs have differing levels of involvement in day-to-day service management and production processes.

An Operational CI is distinguished from the other CI types (Document and Group) in that it is involved in day-to-day business processes,

Configuration Item

Operational CI

Production CI

Deployed Object

Deployed Software System

Service

Document

Metadata

Contains Uses

1 * * *

Conceptual Model

Risk

Service Offering

Ordered Service

ContractAgreement

Deploy Point

Component Datastore

Assembly CI

Measurement

OS Instance (Server)

Machine

Application

AssetTechnologyProduct

BusinessProcess

Strategy

Program

Release

Incident

Known Error

Change (RFC)

Project

Event

Problem

Service Request

Account

May tie to Configuration Item, Program, Project, Service Request, Service Offering, Service, Asset, and Contract. Other linkages possible

8�

can be measured, and is a primary entity in the Service Management workflow.

A Production CI, in turn, refines the concept of Operational CI to include the core CIs that may be involved in Incidents and have Known Errors. (Think data center, or production workstation.) Change control for production CIs is usually a formal, high-visibility process that is what most enterprise IT people think of when refer--ring to “the change process.”

LoGICAL ANd PhYsICAL CIsCIs can be logical or physical. Top down versus bottom up is another way to think of this dis--tinction: logical are top down, physical are bottom up.

Physical, in this case, means there is no ambi--guity about the boundaries of the CI (even if it is only transient bits on volatile storage). Logical means that some consensus is required to set the bounds of the CI. Applications (espe--

cially those built in-house), processes, and services (in the service catalog sense) are the best examples of logical CIs. Machines, com--ponents, files, and network-addressable Web Services are physical CIs. Managing logical CIs is challenging and requires a clearly defined process to establish the bounds of a potentially blurry “thing.”

PARTITIoNING The dATA ModeLThere are few, if any, vendor products currently on the market that cover the entire scope of this conceptual data model. The IT organization will therefore need to integrate two or more products. These integration points can be understood by simply drawing boxes around the entities, representing systems of record, and then observing where those boxes are crossed by relationship lines — that is where interfaces must be built.

For example, if service request management is handled by a different system than service

Figure 5. Partitioning Data Across Systems

Service Request Management System

Service ManagementSystem

may cause the initation of

Conceptual Model Partitioning

Ordered Service

Service Offering

ServiceRequest

Change(RFC)

Problem

Incident

5TiPSFORCATeGORizinGCOnFiGURATiOniTeMS

management, some service requests may result in formal requests for change (Figure 5). This, in turn, requires some sort of interface between the two systems to handle the relationship between Service Request and Change. The interface may be one of several types:> Service Requests requiring RFCs are auto--

matically moved from the Service Request management system to the Service Manage--ment system (automated interfaces can be difficult to build).

> Each Service Request is assigned an unam--biguous identifier, which is then manually entered into the RFC system (potential for human error).

> The Change is created and its identifier is manually entered into the Service Request (again potential for human error).

If no cross-reference is created, the service request is at risk if RFC approval is needed to complete it.

The creation of data silos that do not interop--erate is one of the most pervasive architectural failures in modern IT systems, and we shouldn’t add to the problem. Just remember that inter--faces are expensive to build and run, so don’t underestimate the cost of integrating several best-in-class systems.

BRIdGING The PRoCess fRAMe­­woRK ANd TeChNICAL sYsTeMsProcesses consume and produce data, which is not some mere technicality that can be de--ferred to vendors or developers. A proper data analysis only starts here. The definition and normalization of conceptual entity models, representing a user’s universe of discourse, is an essential part of any full process analysis, and is a key bridge between the process frame--work and the technical systems supporting it.  n

CharlesBetzis a senior enterprise architect for a fortune 50 corpora­­tion. Previously, he was the head of enterprise Repository services for the specialty electronics retailer Best Buy, and has also worked as an IT architect for Target Corporation and Accenture. he holds a Master of science in software engineering from the university of Minnesota,

and is a frequent speaker at industry events. he is the author of the www.erp4it.com weblog. This article is an excerpt from the book Making Shoes for the Cobbler’s Children: Using Architecture and Patterns to Enable IT Governance, by Charles Betz, copyright ©2006 Morgan Kaufmann. All rights reserved.

ABOUTTHeAUTHOR

Keep CIs specific.

Avoid over-applying subtypes. However, subtypes are impor--tant if a subtype can

have a relationship in which the parent does

not participate.

Remember that CIs — base, Operational, and Production —

have differing levels of involvement in day-to-day service management and

production processes.

Think of logical CIs as a top-down view.

Physical CIs are bottom up.

Integrate products to cover the entire scope of this conceptual data model, and don’t under-

estimate the cost of integrating several

best-in-class systems.

The creation of data silos that do not interoperate is one of the most pervasive architectural failures in modern IT systems.

88

Mission:ByVALSAnFORD

AdoptingapragmaticapproachtogatheringdatacanhelpyoucreateaneffectiveCMDB.Usetheseguidelinestoovercomewhatmight,atfirst,seemlikeanimpossiblemission.

Possible

89

Deploying a configuration management database (CMDB) can be a complex process that involves integrating in--

formation, processes, and people into a single cohesive system. Successful CMDB implemen--tations in today’s diverse IT environments focus on optimizing the most critical services that IT provides to the business.

However, even with a focus on key IT services, you may still find it challenging to effectively

aggregate data from a wide variety of sources in different formats. You must carefully identify, collect, and rationalize the data before it can be used effectively to operate your IT environment.

You may look at the obstacles and think this is a Mission: Impossible. However, adopting a pragmatic approach to gathering data can help you achieve “Mission: Accomplished” by creating a usable, effective CMDB solution.

GatheringtheRightDatainYourCMDBtoOptimizeiTServices

90

YouR MIssIoN, shouLd You Choose To ACCePT ITIndustry experts identify data gathering as one of the first steps in successfully deploying a CMDB solution.1 Taking this seemingly simple first step depends on dozens of decisions that must occur at both the organization and IT operational levels. Understanding these deci--sions, along with your organization’s priorities, is a prerequisite to effective data gathering.

The data gathering process can be broken into three key stages:

Data identificationData collectionData utilization and optimization

Proper planning is crucial in mitigating the in--evitable disruptions caused by the introduction of any enterprisewide system. Maintain a cross-functional planning team of IT and business stakeholders to help you plan the CMDB imple--mentation and evaluate it along the way. This cross-functional team will help accommodate business changes, ensuring that the CMDB remains a current, effective tool that increases your organization’s competitive advantage and market value.

Avoid trying to migrate all of your systems to the CMDB at the same time (it just may self-destruct like the tape in the movie Mission: Impossible). Get the most out of your imple--mentation by selecting, as a starting point, one service that IT provides to the business. After the successful rollout of a limited CMDB imple--mentation, you can use the expertise, planning materials, and process you developed for the first implementation to integrate other services into your CMDB.

Remember that the primary data sources will still be in place, and that you can migrate them in stages, according to the priority of the busi--ness services they support. By starting small, your organization is likely to see results much more quickly, thereby proving the value of

>>>

the CMDB and gaining support for it before deploying it to the wider organization.

dATA IdeNTIfICATIoNTo avoid getting bogged down in terabytes of data, narrow your focus to the data that support the most critical services that IT provides to the business. Think about the decisions your organization makes and what data is required to support those decisions. By focusing on the data that supports the IT service you’ve prioritized, you can more easily determine which data types are critical and which are not.

You can then select specific data to integrate into the CMDB, based on your organization’s priorities. It is important to create a target list that distinguishes between the key configu--ration items (CIs) that belong in the CMDB itself and the related or extended CI data, such as Web response times, server availability, CPU capacity, bandwidth utilization, database que--ries per second, and failed downloads. CIs are physical, logical, or conceptual entities in your environment and have configurable attributes, while related CI data describes or defines CIs.

QuesTIoNs To AsK duRING The dATA IdeNTIfICATIoN PRoCessPotential data sources span your entire organi--zation, but the data must meet a specific set of criteria to be included in the CMDB. You can define these criteria by answering questions, such as:

What services that IT provides to the busi--ness, such as Web banking, inventory management, or payroll, are most critical to our organization?Which applications and devices (collectively called “elements”) support these critical

>

>

1. Dennis Drogseth, “Analytics and the new structural approach to management,” Network World’s Network/Systems Management Newsletter, January 30, 2006.

To avoid getting bogged down in terabytes of data, narrow your focus to the data that support the most critical services that IT provides to the business.

services? Which of these elements should we store as CIs in the CMDB? What monitoring and management tools update these CIs?What specific data from each of these tools needs to be provided to our CMDB for each element?Which elements should we consider ex--tended CMDB data?What are the relationships between our CIs? How do we represent those relation--ships in the CMDB?Is all the data required to make business decisions already being collected? If not, what data is missing and how do we collect it?Is there complementary data in other sys--tems? (For example, if one system reports the status of a port, will another system re--port on the health of the server connected to that port?) Which applications will sub--scribe to the data available in the CMDB?

dATA CoLLeCTIoNOnce you’ve identified all of the data you want to include in your CMDB, the next stage is to collect that data. One of the first challenges is determining the actual collection methods available, since different tools provide different data extraction methods. Options range from using well-documented application program--ming interfaces (APIs) to using Web Services data migration or homegrown scripts. You’ll likely end up using a combination of methods to accommodate all the data sources. Cross-functional teamwork is just as crucial at this stage, and is likely to include the administrators of the tools that supply the data you’ve selected.

You’ll need to develop solutions and processes that have no negative impact on either day-to-day business operations or the CMDB project itself. Data collection options must also be compatible with network security protocols set by your company, and you must predict and manage capacity and performance issues.

As in the data identification phase, you must answer several sets of questions in the data

>

>

>

>

>

>

CASeSTUDY:THeCUSTOMeRSUPPORTWeBSiTe

The following case study illustrates the data identt

tification stage of the data gathering process.

The customer support Web site is a top corporate

priority for Business X. The company has released

seven new products and has signed a dozen new

channel partners. To facilitate the successful rollout

of new products and partnerships, it is critical that

Business X’s customer support Web site provides rett

liable access to knowledge base articles, downloadtt

able patches, documentation, and other resources.

Business X has assigned a crosstfunctional team to

define the data set for their CMDB. First, the team

must identify the applications that support the custt

tomer support Web site, including their customer

relationship management (CRM) system, trouble

ticketing system, content management system,

and Web portal application. The team must then

identify the elements that support these systems and

applications, including their primary and secondary

databases, servers, storage area networks (SANs),

firewalls, routers, switches, the LDAP server, and

etmail servers. By identifying these elements, the

team determines the configuration items to include in

the CMDB and notes their relationships to each other.

Next, the team must identify the additional data

Business X needs from both its monitoring and

management tools. For example, Business X has

decided to gather the following data from its

monitoring tools:

Configuration files and settings

Fault and availability alerts

Performance metrics

Security and intrusion detection events

Usertexperience metrics

Finally, the team must use this identification process

for each type of data needed in the CMDB. By suctt

cessfully identifying data their organization needs

to capture, the Business X crosstfunctional team is

taking the first step in ensuring a successful rollout

of a limited CMDB implementation.

•

•

•

•

•

9�

9�

collection stage. Pertinent questions involve choosing tools, addressing data compatibility issues, and choosing a data collection solution.

ChoosING TooLsWith so many potential sources of information in many different formats, a tools audit can help minimize network complexity, thereby reducing the number of inputs into your CMDB. Simplifying your network infrastructure also has the benefits of improving efficiency, reduc--ing costs, and ensuring the day-to-day stability of the disparate systems in your heteroge--neous environment.

Questions to ask about tools in the data collec--tion stage include the following:

What data is available for use by other systems?What methods are available for extracting that data?Are there license restrictions on data extraction that need to be addressed?What teams are using the tool today and how do they use it?Will configuring the tool to send data to the CMDB affect existing processes?

Even with the most efficient processes, you need to think about the possibility of losing some data when using tools to populate the CMDB. Questions to ask about handling data loss between tools and the CMDB include the following:

What level of data loss is acceptable?What actions can we take to deal with data loss?What impact will data loss have on the applications that rely on that data?Will processes need to change to accom--modate data loss?

>

>

>

>

>

>>

>

>

AddRessING dATA CoMPATIBILITY Issues In addition to resolving tool and data loss issues, you must also address data compati--bility issues. Managing the translation or nor--malization of data from source formats to a format usable by the CMDB is one issue, but there are other compatibility issues that need to be addressed.

Establishing a Data Resolution Protocol for reconciling data compatibility issues is critical to the success of the project. A Data Resolution Protocol is a hierarchical rule set that reflects decisions made about how disparate data is managed and valued. When establishing a Data Resolution Protocol, use a Janusian2 approach: Look at data from the bottom up, as well as from the top down. In other words, consider both the consumer and supplier points of view.

Questions to ask when developing a Data Resolution Protocol include the following:

How often does the extended data need to be collected? Daily? On demand? As changes occur? Does the age of the stored data have an impact on its validity?Are different systems reporting conflicting information about a CI? If so, why? Does one system get data automatically and one get data by way of manual input? Will weighting be applied to data based on business needs, age, collection method, or other factors? Is duplicate data being collected? If so, how should the redundant data be handled?

>

>

>

>

>

2 Rothenberg (1979) coined the term “Janusian thinking” (after Janus, the Roman god with two faces that looked in opposite directions) to refer to thinking contradictory thoughts at the same time; i.e., conceiving two opposing ideas to be true concurrently. Rex C. Mitchell, Ph.D. - Strategic Thinking www.csun.edu/~hfmgt001/st-thinking.htm

When establishing a Data Resolution Protocol, look at data from the bottom up, as well as from the top down. In other words, consider both the consumer and supplier points of view.

9�

What are the rules for normalizing con--flicting semantics between data sources? How are discrepancies in data flagged?

ChoosING A dATA CoLLeCTIoN soLuTIoN Once stakeholders in your organization have agreed to data selection requirements and collection methodologies, the next logical step is to perform a build-or-buy evaluation. In some cases, organizations may decide to create a data collection solution in-house. However, there are off-the-shelf solutions avail--able that may meet your needs. In either case, involve your vendors early in the process and set the expectation that they must work to--gether. Heterogeneous environments are more efficient and effective when vendors cooperate to deliver a system to you, the customer.

When considering which tools to buy or build, include both practical and strategic needs. Think about the rate of change in your infra--structure — dynamic environments need more flexibility than static ones. The size and variety of your infrastructure is also a factor. Be sure to think about both the short-term and future needs of the company.

Possible requirements for a data collection solution include the following:

Out-of-the-box support for the systems with which you need to integrateBidirectional, multidirectional, or unidirec--tional integration between tools Support for both real-time and batch collection

>

>

>

>

Use of existing standardsISO or IT Infrastructure Library (ITIL®) certificationRapid deployment, configuration, and optimization to ensure quick ROIAutomated auditing to help meet compliance effortsExtendibility and low service costs Automated data scrubbing to reconcile data based on your Data Resolution Protocol

dATA uTILIzATIoN ANd oPTIMIzATIoNThe ultimate goal of any CMDB implementation is to utilize the data in a way that optimizes your organization’s IT infrastructure and decision-making capabilities, and thus optimizes the services you provide to the business. Once you’ve completed the initial implementation of your CMDB, it’s time to take a step back and evaluate. Have you met your mission objective?

The evaluation process is twofold: First, re--view your objectives so you can measure your progress and identify areas for improvement. Second, determine whether you need to en--hance, enrich, or add to your initial data set so you can optimize your business services.

RevIewING YouR MIssIoN oBJeCTIveDynamic environments offer limitless oppor--tunities for improvement. Comparing perfor--mance against your mission objective offers you the opportunity to adjust your data set to continue to support your organization’s most critical business services.

Thinking about the objective of your mission and the results you expected when implement--ing the CMDB will help your cross-functional team think about ways to optimize the CMDB implementation for improving the level of service you provide to the business. If you’re

>>

>

>

>>

The ultimate goal of any CMDB implementation is to utilize the data in a way that optimizes your organization’s IT infrastructure and decision- making capabilities, and thus optimizes the services you provide to the business.

9�

not getting the results you want, use your mission statement as the basis of a decision-making process to help you determine the changes you need. Review your objectives, measure results against those objectives, and then review, optimize, and enhance your initial data set.

Your mission objectives may include:Reduce mean time to restore a service

Automate ticket openingAutomate prioritization of incidents based on business needsImprove root cause analysis

Improve service availabilityManage change by understanding priority and service impactAutomate communication and approval process for change requestsPredict outages and apply pre-emptive actionsSupport automated capacity planning and on-demand computing

Improve service level managementAutogenerate accurate and timely reportsLink service level agreements to IT components

Improve financial controlsApply service-based cost allocation of IT componentsDetermine total cost of ownership on IT assetsIdentify cost savings more easily

>––

–>

–

–

–

–

>––

>–

–

–

RevIewING The INITIAL dATA seT To oPTIMIze I.T. seRvICesThe initial data set may not provide all of the information you need to make all of the im--portant business, operational, and technical decisions for your organization. Changes in your IT environment or business needs, whether planned or unplanned, can affect data require--ments. When you implement a CMDB, consider incorporating an ongoing data assessment process. Two useful steps in the assessment are building use cases and defining an iterative process for data evaluation.

Building use cases for additional data can help you identify what might be missing. For example, if your data collection tool receives a network event from your enterprise management sys--tem for a device that does not yet have a CI in the CMDB, the collection tool could query the enterprise management system for additional data, create a CI in the CMDB, and populate the CI with appropriate attributes, such as device type, operating system, and so on.

The following iterative data collection process can help set the stage for enriching and enhanc--ing the initial data set you incorporated into your CMDB:

Consider incorporating an ongoing data assessment process.

5TiPSFORGATHeRinGDATA

For each service you provide to the busi--ness and the elements associated with that service, identify the conditions in which additional data may be neededIdentify the source of that additional dataIdentify the consumer of that dataRe-examine goals and objectives made in the initial project and adjust as necessary

Establishing such an iterative data collection process will help your CMDB evolve with your organization, thereby accelerating your ability to provide the most effective services to the business.

MIssIoN ACCoMPLIshed: AN effeCTIve CMdB ANd oPTIMIzed seRvICesAt each stage of the CMDB implementation process, there are specific challenges your or--ganization must overcome. Stringent manage--ment of data requirements and scope, as well as close collaboration with service and tool vendors, can mitigate pain points throughout the data selection and collection stages. More importantly, performing the implementation process in a pragmatic and iterative manner will reduce costs, minimize disruption, and ensure the successful adoption of any CMDB initiative. And success in implementing your CMDB is the first step to optimizing services that IT provides to the business. n

1.

2.3.4.

ValSanfordis vice president of pro­ducts for singlestep Technologies, Inc., a seattle­based software com­­pany that develops data integration and automation solutions. Prior to singlestep, val served as a vice pre­sident at Network Commerce, Inc., and as a director at versusLaw. she holds a Bachelor of Arts degree from whitworth College.

ABOUTTHeAUTHOR

Narrow your focus to the data that support the most critical ser--vices that IT provides

to the business.

Distinguish between the key CIs that

belong in the CMDB itself and the related or extended CI data.

Make sure your data collection solutions and processes have no negative impact on either day-to-day

business operations or the CMDB project itself.

Review your objectives so you can measure

your progress and identify areas for improvement.

Determine whether you need to enhance, enrich, or add to your initial data set so you

can optimize your business services.

Performing the implementation process in a pragmatic and iterative manner will reduce costs, minimize disruption, and ensure the successful adoption of any CMDB initiative.

BusinessService

Software

Hardware

9�

The data in a configuration management database (CMDB) can be divided into three distinct layers: hardware, software,

and services. So, what does this have to do with an Oreo® cookie? Read on, and you will see it’s not as far-fetched as it may at first seem.

Let’s start with the physical infrastructure — the hardware assets. Switches, routers, servers, frames, disks, supervisor cards, CPU cards, power distribution units, cables, and even lap--tops, desktops, monitors, and printers make up the foundation of the IT infrastructure. In most cases, these components of the infrastruc--ture are uniquely identified by serial numbers, have asset tags, and can be seen physically. Some hardware components plug into a chassis or frame and are dependent on that parent component to function. Software is installed on the hardware components in the infrastructure. Software installations cannot exist independent--

ly of the hardware hosts on which they reside. Technicians are dispatched to the location of the hardware — not the software and certainly not the business service.

The business service is enabled by hardware and software. The business service is logical in nature. There are no real tangible facets of the business service. A business service does not have a serial number, weight, color, width, length, or height. Business services cannot be physically moved, they are not purchased as a whole, and they are not physically installed or uninstalled.

The hardware components and the business service are the two chocolate wafers of the Oreo cookie, and software is the filling that holds the wafers together.

services, software, and hardware CIs:JustLikeanOreo®Cookie

ByJOnATHAnMARKWORTHTheCMDBisthecookiejarfortheOreo®cookiesthatrepresentyourbusinesssystems.Businessservicesandhardwarecomponentsarethetwochocolatewafers,andsoftwareisthefillingthatholdsthewaferstogether.

1. Oreo is a registered trademark of Kraft Foods.

!

9�

98

Software is installed on hardware and is most likely to be recognized as connected to the busi--ness service. Users often report issues to the service desk by referencing software by name. Software installations reside on hardware assets — the router, server, laptop, or desk--top. Operating systems, which are also soft--ware installations, define a group of hardware components as a host. Application software is installed into the operating system and, once operational, is able to provide the busi--ness service.

When you combine these three layers in the CMDB, the hardware components and the business service are the two chocolate wafers of the Oreo cookie, and software is the filling that holds the wafers together.

CMdB: The I.T. CooKIe JARI have been asked, “What is the right way to implement a CMDB?” The consultant’s standard answer is, “It depends.” But a few important guidelines can help you determine the best way to proceed.

First, and most importantly, have a clear under--standing of the business need for the CMDB. What problem is the CMDB going to solve? If you are implementing the IT Infrastructure Library (ITIL®) framework by the book, then the CMDB is mandatory — change impact assessments and configuration baselines used during release management both depend on the existence of a CMDB.

Beyond satisfying an ITIL requirement, look at the CMDB as the single source of truth for describing your IT infrastructure — much the same way as a production manager would look at a schematic describing a manufacturing line. For the production manager, the business issue is simple. Optimizing production requires a complete understanding of the components and their relationships that make up a complex production system.

Perhaps over-simplified, the manufacturing line here is like one of the cookies in the factory cookie jar. For the CIO, a business system — such as accounting, enterprise resource planning (ERP), customer relationship manage--ment (CRM), or even e-mail — can be looked at as a cookie in the IT cookie jar.

Second, try not to eat the whole jar of cookies at one sitting. I suppose all our mothers would probably agree that this is good advice. But if you think about it, the stomachache you would get eating a whole jar of cookies in one sitting is very similar to the feeling organizations can get when trying to tackle all the configuration items (CIs) for all business services in the CMDB across the entire enterprise in one giant step.

A better approach would be to rank your business services by importance, financial impact, and criticality, and then fill in the CMDB data — the services, software, and hardware — for a few of those business ser--vices at a time. Yes, you will make mistakes in modeling the CIs and CI relationships in the CMDB. Yes, you will need to make adjustments along the way. But if you really thought that you wouldn’t need to change the orientation of the CMDB sometime during the next ten years due to a radical change in infrastructure or business orientation … well then, I think you get my point.

Filling the CMDB one cookie at a time will de--crease the time it takes to demonstrate the successful use of the CMDB and will provide the traction needed for your configuration management program to mature. Biting off more than you can chew or stuffing your mouth with too many cookies will only cause prob--lems. It may even cause the business to lose interest and completely eliminate the funding you need to continue this effort.

Finally, don’t get too caught up in the right way to eat an Oreo cookie. How do you eat an Oreo cookie? Do you eat the whole cookie, unscrew

5TiPSFORFiLLinGTHeCMDBCOOKieCAR

the wafers, eat the wafers first, or eat the filling first? Does it really matter?

My point is this: If you have a rock-solid soft--ware asset management process in place where compliance is continually measured, then eat the center first (i.e., populate the CMDB with your software data and ensure you have the level of data and interfaces needed to support the operational processes you are focusing on).

If you have mature hardware asset manage--ment with an audited, verified, complete, and accurate hardware inventory, then eat one of the chocolate wafers first. If you have neither, but are getting hammered by the business need for transparency between its services and how IT aligns to these services, then perhaps eating the other wafer might be the best approach.

Your method of filling the CMDB is less im--portant than your understanding that the CIs are not complete until all three layers are re-presented — just as the Oreo cookie is not complete without the two chocolate wafers and the creamy filling.

BRING eNouGh To shAReA CMDB implementation is successful when all interested and concerned parties consider your CMDB the single source of truth for the IT infrastructure. It doesn’t mean all of the data is stored in one place. But it does mean that when a new infrastructure component is added to the environment through change and release management, the workflow includes more than just the IT organization. Finance, contracts, asset management, and other business groups should be included in the process flow.

Don’t underestimate the importance of any as--sistance that can be provided by mature asset, contract, and inventory management practices that may already exist in your environment. Contract and asset management are sources of funding for your CMDB. A mature asset in--ventory can be used to seed the CMDB or even extend the CMDB through federation. Some IT asset management staff resources and ex--pertise in maintaining inventories should be involved or even own the ongoing maintenance of the CMDB hardware and software inventory.

I think it is even more important to consider the financial impact of including contract manage--ment in the change management process. Most contracts require 60 to 90 days of notice before removing a line item from the schedule. How much can be saved by leveraging the for--ward schedule of changes in this situation?

Bring enough to share. Remember that the deployment of a CMDB will require resources. If your CMDB is going to be more than just a database that stores electronic inventory records, you will need the support of the busi--ness to commit to a formal configuration management program. Leverage the CI and its federation to other business data, and build around your CMDB the processs flows that make the business more efficient. n

If you have a complete and accurate hardware inventory,

a mature software asset management discipline, and/or a recent business impact assessment that

describes your critical business services, then

make use of them.

Make it easy on the people who need to be involved in both configuration and

asset management activities by defining workflows and

work instructions that accommodate both.

Define complementary processes —those that

seamlessly transcend disciplinary boundaries —

instead of loading more administrative responsibility an an already strained staff.

Keep in mind that it’s unlikely that automated

tools will completely replace the need for disciplined

lifecycle processes.

Pick one or two mission- critical business services to get started. It’s better to pick

one area of the business and build on success than fail to deliver any value.

JonathanMarkworthis a managing consultant with CompuCom systems, Inc. , headquartered in dallas, Texas. Jonathan has successfully performed a variety of functions in the IT industry during the last 20 years. he is certified in ITIL and six sigma, and is a certified Project Management Professional

(PMP). As part of CompuCom’s Integrated Infrastructure Management practice, Jonathan and the CompuCom Center of excellence team are responsible for deploying effective solutions for change, configuration, release, and asset management.

ABOUTTHeAUTHOR

A CMDB implementation is successful when all interested and concerned parties consider your CMDB the single source of truth for the IT infrastructure.

�00

CAPA

BILITIes

eNA

BLed

BY A

CMd

B

�0�

SeCTiOn�CAPABILITIes eNABLed BY A CMdB

“To provide real value in managing a changing infrastructure, you must identify the interdepencies between components.”

—Hans-HeinzWisotzky,MATeRnAGmbHinformation&Communications

“The configuration management process and the CMDB together create the foundation where components, systems, and configurations are brought together and understood.”

—PerrySellars,StrategicTechnologies

“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.”

—JulieManis,Accenture

“Implementing a CMDB along with an integrated set of tools provides companies a competitive advantage that enables IT organizations to not only respond to the needs of the business, but to proactively support the business.”

—KiaBehnia,BMCSoftware

“Integrating the CMDB with sources of identity information enables you to include in the CMDB information about the relationships of people to the IT infrastructure.”

—AhmadAbdel-Wahed,Microsoft,andBobWorner,BMCSoftware

“When information is federated between a centralized CMDB and various other applications that help you manage functional processes, the consumers and users of vast quantities of data are brought together.”

—KevinBehr,GeneKim,andGeorgeSpafford,iTProcessinstitute

“Implementing an integrated service management tool supported by a CMDB is a critical success factor in supporting an effective IT service management initiative.”

—TroyDuMoulin,Pinkelephant

“Integrating network configuration management information into your CMDB will help you integrate the network layer into your overall IT service model and better align IT service delivery to business needs.”

—JeffGibson,Voyence

“The CMDB should include data about the relationship of an event to the business customers who rely on a service, as well as the relationship of an event to the personnel required to resolve it.”

—TroyMcAlpin,invoqSystems

“By having business processes defined in the CMDB, the IT organization will now have increased visibility into the business.”

—DeveshSharma,Oracle

���

�08 ��0

���

���

��8

���

���

��0

�0�

�0�

Management:Thekeytoa

infrastructurePicturePerfect

WhenaCMDBisthecenterpieceofyourchangemanagementprocess,youcanmoreefficientlyandaccuratelychangeyouriTinfrastructuretomeetbusinessneeds.

ByHAnS-HeinzWiSOTzKY

Change

�0�

�0�

Your company’s IT infrastructure is in a constant state of change: new tech--nologies, new business models, and

changed work processes demand continual adjustments to the technology. To react quickly to the changing market situations and the resulting requirements of the business, you must implement changes to the IT infrastructure speedily and smoothly. Any delay can impede, or even paralyze, critical business processes.

The real challenge is striking the right balance between agility and control.

Nonetheless, changes must also be controlled. Hastily planned and implemented changes can do more harm than good. In fact, some market observers assert that up to 80 percent of all IT problems are caused by unauthorized or insufficiently controlled changes. Those outages impact the critical business processes that rely on IT.

The real challenge is striking the right balance between agility and control. This balance is found in the interplay between the people that make changes, the processes they follow, and the data and tools that support those processes.

Well-engineered processes provide other benefits as well. One benefit is that making changes to IT infrastructure is now “in scope” for a range of government regulations. An--other benefit is overall IT efficiency. While IT capital budgets are flat, businesses nonethe--less expect IT to support new strategic initia--tives. Your IT organization is not operating at peak efficiency if hastily implemented changes cause failures that result in expensive and labor-intensive repairs. Many IT organizations find that once they get better control of changes, they can squeeze budget out of operations to fund new initiatives.

LooK BeYoNd AsseT MANAGeMeNTOne of the central problems in striking the right balance between agility and control is that many companies don’t understand what their infrastructure looks like, what it should look like, and how the individual components affect each other. Nearly all IT service providers perform inventory and asset management, and both of these instruments provide a picture of the infrastructure.

However, neither provides an infrastructure view with enough detail to provide value to operations managers. Servers, clients, or ap--plications can be traced and registered during the inventory process. But pure inventory management is not in a position to differentiate between “good and evil,” or in other words, between authorized and non-authorized changes to the inventory. It only provides a single snapshot, which shifts out of focus as the infrastructure changes.

To provide real value in managing a changing infrastructure, you must identify the interde--pendencies between components. Asset management doesn’t care how the elements are interconnected to provide an IT service, nor does it focus on how a change can affect the whole infrastructure. Understanding the current state of the infrastructure helps you to reduce the risk of each change and helps you to in--crease the success of implementing changes.

shARPeN The foCus wITh CoNfIGuRATIoN MANAGeMeNT ANd The CMdBConfiguration management will help you extend asset management with information about the interdependencies between infra--structure elements. This will give you a sharply

To provide real value in managing a changing infrastructure, you must identify the inter-dependencies between components.

�0�

focused picture of the operating state of components. Configuration management is concerned with the target status of the IT infrastructure. It also forms an important interface for all IT service processes within the relevant frameworks, such as the IT Infrastructure Library (ITIL®).

The key element behind configuration man--agement is the configuration management database (CMDB), a repository that ideally mirrors the actual current target situation of the IT infrastructure. In many companies, confusion exists when configuration manage--ment and asset management are not clearly separated from each other. These companies operate configuration management solely on the basis of data from asset management — which is not a particularly healthy situation. For example, if you are implementing ITIL best practices, you can use asset management data as a starting point for configuration management, but you can’t simply take asset management data and use it for configura--tion management.

Understanding the current state of the infrastructure helps you to reduce the risk of each change and helps you to increase the success of implementing changes.

Similarly, the real value of the CMDB emerges when it is seen as a resource for IT service management. In fact, all IT service processes described in ITIL can benefit from the CMDB, including change management. Not only are

the individual configuration items (CIs) main--tained in the CMDB, but so are their status and relationship to other CIs.

With a CMDB, you can completely assess the results of any upcoming changes: which components will be influenced by a change, which connections have to be taken into con--sideration, and which business processes are affected.

CoMPose A CLeAR PICTuRe wITh ChANGe MANAGeMeNTEvery step in a change request can and should be closely interconnected with the underlying CMDB. Ideally, as soon as a request for change (RFC) is received in the change management process, it should be analyzed with information about the CI in the CMDB to get an immediate view as to whether the change is feasible. During prioritization, planning, and imple--mentation of RFCs, the logical target status description supplies valuable data for decision-making, as well. By using the CI relationships that are mapped there, you can recognize potential problems or conflicts early in every project phase, well before there are effects on productive systems, and thus, on users’ work processes.

This early identification provides you an excellent method of keeping service quality at a high level for the customer. The benefits are obvious: You avoid failures due to unsuc--cessful changes, and you simultaneously reduce the time from RFC submission to

�0�

making a decision and implementation. This enables you to quickly and successfully implement changes without losing control. When a change is successfully implemented, each change to existing or newly acquired CIs is documented in the CMDB.

When designing change manage-ment processes, always take into account information from the CMDB.

The CMDB serves as an important basis for change management in other ways, as well. It provides a suitable starting point when processes in change management have to be redesigned and regulated within your IT organization. For example, you can use the CMDB when introducing standardized ITIL-compatible IT service processes to make them traceable and free them from fault sources. When designing change management pro--cesses, always take into account information from the CMDB. This will achieve two objec--tives: The change process can be partly auto--mated by means of clear work steps, and the standardized procedure facilitates the search for faults when problems arise.

AvoId ouT­of­foCus IMAGes ThRouGh oNGoING CMdB MAINTeNANCe Even with integrated change management, you still need to perform maintenance on the CMDB to ensure that the quality of the infrastructure picture remains sharp. The gap between the target and current status of the IT infrastructure is ever widening, primarily as a result of users who, on their own, install programs and adapt their PCs or field service notebooks. A CMDB can be out-of-date in just two hours; you’ll need to keep the current status up to date through regular audits, and then compare the current status with the CMDB’s target status.

With the appropriate tools, the audit can be carried out automatically in many cases. Here’s the difficult part: The audit will likely uncover

rogue changes that do not reconcile with CI data in the CMDB. You’ll need to decide which of those rogue changes should be updated in the CMDB and which rogue changes should be removed as quickly as possible. You can’t really automate this much, since many of the decisions have to be made and carried out by a member of the IT staff.

In any case, you’ll need to ensure that all changes to the infrastructure flow back into the CMDB as updates to related CIs, as this is the only way to ensure that the CMDB always mirrors the current status. If the current status deviates from CI information in the CMDB, you’ll find yourself looking at an out-of-focus image.

CAPTuRe The PeRfeCT PICTuReA picture perfect infrastructure is within your reach. Use asset management as a starting point, and build upon asset management data to effectively map your configurations. Populate your CMDB with the configuration data, and use the CMDB to determine the feasibility of each proposed change before moving forward with the change. The result will be fewer, if any, failed changes, resulting in less disruption to the business, and ultimately, better service to the business you support. n

Hans-HeinzWisotzkyis vice president of the Competence Center service Management at MATeRNA Gmbh Information & Communications, an IT service provider. his main interests are Business service Management, IT service Management, and ITIL.

ABOUTTHeAUTHOR

Use the CMDB to determine the feasibility of each proposed change before moving forward with the change.

5TiPSFOReFFiCienTCHAnGeMAnAGeMenTUSinGACMDB

Use asset management data as a starting point for configuration

management.

Identify the interdependencies

between components.

Use the CMDB to determine the

feasibility of each pro--posed change before moving forward with

the change.

When designing change management

processes, always take into account information from

the CMDB.

Maintain the CMDB and ensure that all

changes to the infra--structure flow back into the CMDB as

updates to related CIs.

�08

TheCMDBismorethanastaticrepositoryofinformation.itisanintegralpartoftheconfigurationmanagement(CM)process,providingthefoundationforotheriTprocessesthatenablethedeliveryofbusinessservices.WhenyoustartyourCMDBproject,makesureCMispartoftheequation.

Remember

ByPeRRYSeLLARS

“CM”inCMDB

the

�09

Creating a configuration management database (CMDB) and loading con-figuration item (CI) data into it takes

a significant amount of time. But don’t stop after you’ve populated the CMDB. Although you’ll have an accurate snapshot of the in--frastructure at that moment, you’ll lose the reliability of the CMDB information after just one undocumented change. Ongoing control and management of your IT infrastructure requires a process that is both owned and improved over time.

The CMDB is not the end point or nirvana of a configuration management process im-plementation. An accurate CMDB provides component or configuration information to other service management processes; that is, change management (effective impact analy--sis) and incident and problem management (event correlation). This interdependency places configuration management as the foundational element in an effective service management strategy.

The CMDB provides common infor-mation and a shared view of the IT infrastructure, including information about each infrastructure component.

The CMDB enables you to share critical infor--mation across the IT organization. However, to create value, you must integrate the CMDB at two levels. First, you need to integrate the CMDB with other IT service support and ser--vice delivery functions. The CMDB provides common information and a shared view of the IT infrastructure, including information about each infrastructure component: its function, operating state, history, and relationship to other components. Access to this information allows IT functions to work together, enabling end-to-end service management.

Second, you need to identify the linkages or relationships that exist between IT services and infrastructure and the business functions

��0

they support. From accounting to order pro--cessing to customer relationship building, IT enables business functions. To make basic cost-versus-risk decisions and resource allocation determinations, IT needs information about what business function is supported by an IT service or component.

An effective configuration management pro--cess can help you integrate IT with the service provided to the business. Configuration man--agement also helps you to build and maintain an accurate and relevant CMDB.

whY You Need CoNfIGuRATIoN MANAGeMeNT wITh A CMdBWhen you set up your CMDB, make sure con--figuration management is part of the process. Configuration management includes a variety of functions:

Planning. Define the process and decide how your organization will implement configuration management. Planning includes the strategy, policies, scope, and objectives, as well as organi-zation roles and responsibilities. Thoughtful planning provides a sound foundation from which to maintain a manageable and con--trollable CMDB. Many organizations hurry through this very important activity and end up with a CMDB that lacks supporting configu-ration management processes, resulting in an unmanageable and soon to be out-of-date data--base filled with unusable and inaccurate data.

Identification. Break down and uniquely define the infrastructure components or configuration items. A minimum set of identification infor--mation includes owner, dependency relation--ships, basic attribute data, and revision or version number. Identification enables you to control, record, and report configuration items to the level the business requires. As a rough

ASSeTVS.COnFiGURATiOnMAnAGeMenTIt’s important to distinguish between configutt

ration and asset management. Typically, IT

Operations directs the CMDB and the configtt

uration management process, which is focused

on proper function of the IT infrastructure.

Procurement or Finance directs asset managett

ment, which is focused on financial accounting

of IT capital assets.

Asset management is concerned with details

such as: When did we acquire the asset? How

much did it cost? Is there an asset tag on it?

What’s the depreciation level? If it is an IT

component in production but not considered

a capital asset, it is no longer tracked by asset

management. Additionally, if it is in production,

but fully depreciated and not considered for

property tax, it’s no longer tracked.

Configuration management, on the other hand,

is more concerned with questions such as:

Who is using this particular configuration item

or component? What service is this component

a part of, and what business function does it

support? Is it a single point of failure? What

is the servicetpack level of this component?

If you are using the CMDB only to control

components from an asset perspective, then

you are not utilizing the CMDB to its fullest

potential. Use configuration management

to unleash the power of the CMDB — to help

IT track important configuration information,

and ultimately, to explain to business partners

how a particular component is critical to a

business service.

An effective configuration management process can help you integrate IT with the service provided to the business.

���

Figure 1. IT Service Support and Benefits of Integrated Practices

guide, identify components or CIs to the lowest level of independent change.

Control. Establish guidelines to record and maintain only authorized and identifiable CIs in the CMDB. You’ll want to identify processes that update CI data, such as change manage--ment, discovery, and reconciliation, as well as people authorized to modify CI data directly. This activity ensures the data integrity of the CMDB to enable meaningful impact analysis, event and problem correlation, and service continuity planning.

Status accounting. Perform the all-important management reporting activity. For all CIs under control in the CMDB, you need to track changes to CIs and make sure records are traceable. Status data should include the current ver--sion or revision number, the functional status (development, testing, production, retired) of

the CI, and its change history. Status reports can establish baselines prior to major change events or releases into the infrastructure, and can help reduce investigation time for incident and problem management. Status reports can serve as the snapshot in time if a fallback is required.

Verification and audit. Review the CI data in the CMDB and verify the effectiveness of the configuration management process that is responsible for maintaining accurate data. If the results of scheduled or random audits are published and reviewed at department meetings, the entire organization can share a sense of responsibility for maintaining an accurate CMDB.

function Challenge as standalone practice Benefits of integrated practice

service desk and Incident Management

service desk doesn’t have critical information to quickly and efficiently process the request, creating an extended outage while researching.

with information about the state, history, and configuration of the infrastructure component of the service in question, the service desk is more efficient and effective.

Problem Management

80 percent of problems are related to a recent change.

Access to change history for the failed component and other dependent components helps quickly identify the root cause of failure. event correlation is made possible through correctly identified CIs and the ability to match common incidents.

Change Management

Making a change without a risk assessment can lead to unplanned outages.

Knowing the success rate of past similar changes, what other infrastructure is dependent on the com­­ponent about to be changed, and which business users rely on the component significantly improves the change success rate.

Release Management and software Control and distribution

Releasing a software or operating system patch to an unknown configuration is risky.

full knowledge of the hardware, software, and settings of a component improves the release process and provides a way to quickly understand the patch level of the infrastructure.

���

CoNfIGuRATIoN MANAGeMeNT esTABLIshes The fouNdATIoNAL PRoCess foR MoRe effeCTIve I.T. seRvICe suPPoRTService support ensures that your customers have access to appropriate IT services that enable their business function. The service desk is a key part of your service support strategy, because it provides your IT organization’s face to the customer. Service support processes help you deliver high-quality service, enabling consistent availability of the applications that customers want and more immediate response time to failures if they occur. Without confi-guration management, these service support functions cost more and deliver less value since you must repeat steps to solicit or hunt down component information.

Figure 1 on page 111 shows the functions of IT service support, the challenges of implementing

each function as a standalone process, and the benefits of integrating the function with configuration management.

Service support processes help you deliver high-quality service, enabling consistent availability of the applications that customers want and more immediate response time to failures.

Service support processes are more effective when they have accurate component-level information. However, these processes require access to information created in many places and functions within IT. Consolidating all of this information in a single CMDB enables faster resolution of problems, higher success rates for changes, and fewer unplanned outages. You’ll likely have happier customers, as you’re more likely to achieve higher service levels, and you’ll also reduce the labor required to contin--ually hunt down component-level information.

Figure 2. IT Service Delivery and Benefits of Integrated Practices

function Challenge as standalone practice Benefits of integrated practice

service Level Management (sLM)

service level agreements related to individual components limit effectiveness of sLM.

Nested service levels all relating back to an IT service or business function provide an integrated view that is increasingly demanded by business budget owners.

Capacity Management

Capacity management of silos is increasingly recognized as insufficient.

Composite capacity management of a collection of infrastructure components enables support of critical business services.

service Continuity Management

Continuity management often misses critical elements that render the partial plan insufficient to respond to an actual crisis.

An entire picture of all components and users of a critical business service enables effective continuity planning.

Availability Management

Availability of a server or application in isolation is meaningless to a business user.

end­to­end availability management delivers on a basic business user requirement.

financial Management, not just Asset Management

financial management of individual assets meets accounting require­­ments but does not enable strategic decision­making.

financial management and understanding of service costs help IT make cost vs. benefit and resource allocation decisions that deliver competitive advantage.

���

CoNfIGuRATIoN MANAGeMeNT eNABLes MoRe effeCTIve I.T. seRvICe deLIveRY fuNCTIoNsService delivery ensures consistent operation of the IT infrastructure upon which the busi--ness depends. With an effective and accurate CMDB, you can greatly enhance important service delivery functions, such as service level management, service continuity, and capacity management.

Figure 2 shows the functions of IT service de-livery, the challenges of implementing each function as a standalone process, and the benefits of integrating the function with con--figuration management.

Many service delivery functions cannot succeed without accurate configuration information. However, this information is created in a broad range of places and functions within IT. Consoli-dating all of the information in a single CMDB enables systems-level capacity and availability management, continuity and risk planning, and better overall financial management of IT resources. You also can more effectively utilize scarce IT resources to improve service levels and service quality. As a result, you can spend less on IT back-office functions and more on new strategic initiatives to better deliver service.

CoNfIGuRATIoN MANAGeMeNT eNABLes CoNTRoL of CRITICAL BusINess fuNCTIoNsWhen you undertake an initiative to implement a CMDB and configuration management, begin by examining the services provided by IT to the business. Take a top-down view, rather than

Figure 3. Mapping Business Process to Configuration Items

DocumentBusiness Process

Internal

External

Archival

GL

AP

AR

Orders

Procurement

Service

DetermineWorkflow

Communication

CustomerPortal

IdentifyServices

Map to ITInfrastructure

FSC

2 node Oracle RAC

Storage Foundation for Oracle RAC Storage Foundation for Oracle RAC v210 Infra v210 Infrav210 Infra

v440app DBs

v210web and midVVR

F12K-dmdapp DBs

F12K-dmeapp DBs

v210mid

v210web

v210web

v210mid

6 Node VCS Cluster 2 Node VCS Cluster

1 node Oracle RAC

TCA

E-mail

SAP

OracleApps

Business Impact Service Definition Service Continuity Disaster Recovery

Finance

Storage Foundation HAOracle Enterprise Agent for VCS Custom Agents for VCS (including PECS, FDM, IMS,BID, MedForms, PTO)

GLOBAL CLUSTER OPTION

ORACLE DATA GUARD

With an effective and accurate CMDB, you can greatly enhance important service delivery functions.

���

a bottom-up or component-level-up view. Start with your most critical business services — maybe two or three — and focus your efforts on the components that make up those services.

Consider e-mail, for example. Just like picking up the phone and receiving a dial tone, e-mail is a critical communication link for most com--panies. In fact, some organizations are almost completely shut down by e-mail outages, resulting in lost revenue and customer dis--satisfaction. Therefore, to ensure that you keep this critical service up and running, you’ll want to break down the service into configurations and CIs. Figure 3 on the previous page illus--trates the mapping of a business service to CIs.

When your CMDB houses information about a service and its components, the information is readily available to various IT functions, there-by improving the efficiency and effectiveness of those functions. Some examples follow:

Change management. Suppose Microsoft releases a new version of Outlook or a patch for Outlook. You may have 20 Exchange servers in your organization at different service pack levels. If you don’t have a CMDB that’s up to date, how do you know which servers this next service pack affects? Using the “patch and pray” approach to determining what servers need the service pack is not appropriate for business-critical functions such as e-mail. With an effective configuration management process, you can interrogate the CMDB and learn that the service pack is required on ser-vers one, two, three, and four, but does not apply to any other servers because they were already updated.

Additionally, an effective change management process, coupled with an effective CMDB, allows you to evaluate the impact that taking down these servers will have on your business cus--tomers. You can perform a risk assessment by looking at the compatibility of this service pack with any others previously applied.

Release management. When you release the service pack to the identified servers, are you going to do a delta release or a package release? By using the data in the CMDB, you can de--termine whether applying a package release will have a low impact and risk. Without effec--tive configuration management, you end up with a spot check.

You might apply the release on one server with the intent that if it doesn’t fail for a month, you’ll apply it to the rest of the environment, whether it’s needed or not. If it fails, something specific to that one server may have caused the failure. In other words, it may not have failed on any of the other 20 servers because they don’t have that same issue. Those other 20 servers could be the ones that are running an application for the majority of the business users. Perhaps the server that failed is used only by the development organization. The other 20 servers could fail, too, but you just don’t know when that’s going to happen. The CMDB makes release management much more efficient and effective.

When your CMDB houses information about a service and its components, the information is readily available to various IT functions.

5TiPSFORenSURinGCMiSPARTOFYOURCMDB

Incident management. If the server goes down and Outlook fails, your incident management process identifies the failing CIs. A customer can open an incident with the service desk. You know an Exchange server went down, but you can’t tell which one. You identify a patch to resolve the problem. Again, how do you determine which servers this patch applies to? Do you apply it just to the one that’s down? Or do you interrogate the CMDB so you can apply the patch to other servers that haven’t failed yet, allowing you to proactively take care of this incident and keep another failure from occurring?

If you have used a CMDB to identify and control what version of Outlook you’re running, you have the information at your fingertips. You don’t need to physically check every server. That easily leads you to a request for change: You need to apply service pack ABC to servers one, two, three, four, and five.

Continuity management. Suppose a company has a business continuity plan that lets the IT team move their operations from point A to point B, but they can’t move the connection to their customers from point A to point B. If a disaster occurred, their customers would not be able to connect to the alternate site. How would business continue in this case?

The configuration management process and the CMDB together create the foundation where com-ponents, systems, and configurations are brought together and understood.

An effective configuration management process will help identify such gaps. When approaching service continuity management, first identify your business services, breaking them down into IT environments or configurations. These can then be further divided into components or configuration items. Is this starting to sound familiar?

If the company in this example had an effective configuration management process, it would have identified the users of that service. Then it would have identified the infra--structure that provides user connectivity for that service and noticed that it was missing from the service continuity plan.

CMdB seTs fouNdATIoN foR KNowLedGeThe configuration management process and the CMDB together create the foundation where components, systems, and configurations are brought together and understood. As a result, IT knows the pertinent details about each CI important to a particular service provided to the business. Such knowledge enables you to more efficiently and effectively provide IT service support and IT service delivery. You can save time and money, and focus on new stra--tegic initiatives that facilitate business services. n

PerrySellars,a consultant with strategic Technologies, is a pub­­lished author, featured speaker, ITIL Certified Master, and an IseB accredited ITIL tutor. he has 23 years of experience in IT, system, and network management, and has con­­ducted ITIL maturity assessments and implementation consulting

for customers since 1996. Perry may be contacted at perry.sellars@stratech.com.

ABOUTTHeAUTHOR

Establish the vision — why the

organization is making a commit--

ment to service management.

Start with the service and identify the infrastructure

components or CIs that are part of

the service.

Record and maintain only authorized and identifiable

CIs in the CMDB.

Track changes to CIs and make

sure records are traceable.

Review CI data in the CMDB and verify effectiveness of

the configuration management pro--cess responsible for maintaining accurate data.

���

facilitating effective i.T.AssetManagementwith the CMdB: Anine-StepApproach

���

Awell-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 1DeFineTHePURPOSeOFTHeCMDBStart 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,

DesigningaCMDBthatalsofunctionsasanassetmanagementrepositoryrequiresbroaderdefinitionsoftheconfigurationitemsincludedinatraditionalCMDB.FollowthesestepstosuccessfullyscopeandmanagetheassetmanagementaspectsofaCMDBinitiative. ByJULieMAniS

7

1

4

step

step

step

2

8

5step

step

step

3

6

9

step

step

step

Define thepurpose

of the CMDB

Identify allstakeholders andcreate a CMDBreference group

Define the roleof the CMDB in

IT servicemanagement

Define thescope for

configurationitems and assets

and the differencesbetween them

Definefunctional

requirements

Create astrategy for the

CMDB

Start small,think big

for design andimplementation

Consider tooloverlap and

organizationalgaps

Remembercritical plan

functions

Figure 1. Steps for a Successful CMDB

��8

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 2iDenTiFYALLSTAKeHOLDeRSAnDCReATeACMDBReFeRenCeGROUPThe 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 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 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 3DeFineTHeROLeOFTHeCMDBini.T.SeRViCeMAnAGeMenTWhen 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 4DeFineTHeSCOPeFORCOnFiGURATiOniTeMSAnDASSeTSAnDTHeDiFFeRenCeSBeTWeenTHeMYou’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--

��9

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

��0

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 5DeFineFUnCTiOnALReQUiReMenTSOnce 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 6CReATeASTRATeGYFORTHeCMDBAfter 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 federated 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 7STARTSMALL,THinKBiGFORDeSiGnAnDiMPLeMenTATiOnYour 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, personAfter 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 8COnSiDeRTOOLOVeRLAPAnDORGAnizATiOnALGAPSRemember 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 9ReMeMBeRCRiTiCALPLAnFUnCTiOnSAn 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 CMdBDefining 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.

Combining asset and CI records in a federated repository eliminates duplication of data and lowers the cost to maintain and manage multiple data stores.

5TiPSFOReFFeCTiVeASSeTMAnAGeMenTWiTHTHeCMDB

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

JulieManisis an operational lead in asset management for the Global Architecture and Core Technolo­­gies group at Accenture. she has more than 20 years of experience delive ring high­value lifecycle man­­agement solutions, ITIL standard process solutions, and enterprise systems management solutions.

ABOUTTHeAUTHOR

Define the data the CMDB will store, the functional requirements of the CMDB system, your structural approach, and your plan for turning your vision into reality.

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.

���

You wouldn’t write a check without making sure you had enough money in the bank to cover it. When you do

home banking, you expect that your bank has accurately recorded your deposits and with--drawals. Each time you add or take out money, you assume the transaction worked flawlessly, and that changes to your account are updated accurately. This high degree of accuracy and timeliness can help you decide how much mon--ey you should add to your account to cover big expenses and when you must make deposits to cover these expenses. Unfortunately, IT decisions are not always made based on this same high standard of data integrity. Perhaps this is because many people are unaware of the power of a configuration management database, also known as a CMDB.

What is a CMDB and why do you need one? The IT Infrastructure Library (ITIL®), a frame--work for best practices in Service Management, recommends that organizations consider the value of using a CMDB. A CMDB provides a common data model for storing IT configu--ration item information and their relationships. It offers a single source of record with a logical

model of the IT infrastructure and services. This model is used to identify, manage, and verify all configuration items and their rela--tionships in the environment. This concept of a CMDB serving as single source of data, or “truth,” is its greatest strength. Without a cen--tralized foundation of accurate configuration information, IT organizations will continue to work in isolation, and may not have data need--ed to better align their activities with business objectives. In continuing the banking analogy, consider the CMDB as the general ledger, the main record for the bank accounts, including accounts receivable, accounts payable, and expenses.

However, not all management data related to configuration items are appropriate for storage in the CMDB. This is why organizations should consider a CMDB based on a federated data model. Why? Just like links within the general ledger to financial details stored in the accounts receivable system, a federated CMDB links to IT details. For example, a federated approach allows for other useful management infor--mation — such as service level agreements, purchase orders, incident and problem tickets,

ByKiABeHniA

CMDBBusinessValueUnfortunately,iTdecisionsarenotalwaysmadebasedonahighstandardofdataintegrity.PerhapsthisisbecausemanypeopleareunawareofthepowerofaCMDB.

���

���

performance and utilization data — to be linked to the configuration items within the CMDB. As a result, a federated CMDB can help IT drive down the cost of mean-time-to-repair, minimize downtime and improve responsive--ness to business requirements without becom--ing a bottleneck to those activities.

There are a variety of ways that a federated CMDB can help IT organizations manage their infrastructure and services from a business perspective. Six of them are listed here:

No. 1MAKeSi.T.MOReReSPOnSiVeTOBUSineSSneeDSA CMDB can transform the way organizations conduct business by helping them be more responsive and efficient. Having central, up-to-date information about configuration items enables IT departments to make better planning decisions in response to business needs. This is important for planning data center migrations, server consolidation, merging of infrastructure due to merger and acquisition activity, and other key business needs.

No. 2PROViDeSASeRViCe-ORienTeDVieWOFTHei.T.inFRASTRUCTUReIn addition to storing configuration information about the physical IT infrastructure, a CMDB should store information about the configu--ration items’ logical relationships to each other and to the business services that the IT infra--structure supports. This information provides business context for processes and activities so that the risk is assessed correctly and activi--ties are prioritized according to business needs. Service level agreements can be maintained and measured on the business service, as well as the IT infrastructure components upon which a business service relies. Having these logical services defined in the CMDB allows for better decision-making and it positions the IT organization for more effective auto--mation in the future. For example, when as--sessing a known vulnerability on a server, by using the information in the CMDB, an orga--

nization can assess risk based on both the severity of a patch, as well as the business context of the systems that are vulnerable. This capability allows IT organizations to pri--oritize patches to machines that support the business services and ensure that business-critical systems are secure.

No. 3FACiLiTATeSCOMPLiAnCeAnother driver for a CMDB is its ability to help IT organizations audit an environment quickly and accurately. Some of this concern is focused around regulatory compliance areas, such as Sarbanes-Oxley and HIPAA, as well as to more cost effectively manage assets. A CMDB helps to ensure that asset information is accurate and up-to-date because it provides the enabling technologies needed to tie together IT service management processes. A CMDB, coupled with an integrated change management process, can enable IT organizations to provide control over critical changes and monitor the history of changes made to their environment.

Having a central, federated repository of all the configuration information and their relationships helps avoid downtime, because you can plan changes more effectively and understand the impact of a change.

No. 4ReDUCeSTHeiMPACTOFCHAnGeSThe number of IT changes in an environment will increase as the environment becomes more complex. The changes are both planned and unplanned, such as the preventative release of a security patch and the reactive release of a patch in response to a new virus. At the same time, the maintenance window of when changes are acceptable to the business con--tinues to shrink. People are more mobile and often work weekends and nights. As companies become more global, there is never a good time to implement changes. However, a CMDB (coupled with effective change management processes and configuration automation)

���

provides the ability to effectively manage the dramatic increase in the number of changes in an environment. Having a central, federated repository of all the configuration information and their relationships helps avoid downtime, because you can plan changes more effectively and understand the impact of a change.

A federated CMDB allows for sharing of config-uration data across the organization so that processes can operate with access to all of the configuration data and the system dependencies.

No. 5HeLPSCOnneCTTHe“iSLAnDSOFinFORMATiOn”WiTHinTHei.T.DePARTMenTIn many organizations, IT functions are spread across silos, with each group utilizing a set of tools to perform a specific set of tasks. Often, these tools have a partial view of the environ--ment, which makes problem isolation and troubleshooting difficult. As IT departments adopt processes that span silos, there is a need to share critical data about the infrastructure and the services the infrastructure supports. A federated CMDB allows for sharing of con--figuration data across the organization so that processes can operate with access to all of the configuration data and the system dependen--cies. For example, the accurate data within a CMDB helps ensure that routine network maintenance does not cause outages across systems that are connected to the network. Without this capability, outages can occur as a result of unreliable or incomplete data, even if the IT staff follows otherwise effective processes.

No. 6CReATeSSYneRGYAMOnGPROCeSSeS,DATAAnDAUTOMATiOnTOOLSBy eliminating the islands of isolation, IT organi--zations can now use an integrated approach with tools that increase awareness of data and processes. When various groups use different tools with different data, the diagnostics are too often done in isolation. One group in IT may inadvertently step on the toes of another

group. The security team, for example, may pick one weekend to send patch upgrades and then inadvertently disrupt database backups that had been planned by another team in IT. The CMDB, however, enables teams to coor--dinate processes, utilize the common data in those processes, and help automate them.

Implementing a CMDB along with an integrated set of tools provides companies a competitive advantage that enables IT organizations to not only respond to the needs of business, but to proactively support the business. It helps IT to be respected as the enabler of business-critical technology. Departments will move faster, companies will be able to more easily integrate the infrastructures of companies they buy, and businesses will be more responsive to customers and other dynamic business pressures with a CMDB in-house. In addition, IT organizations can make sure they are not writing any checks they can’t cash by better managing risks, avoiding unnecessary down--time, and becoming more efficient. n

KiaBehniais the Chief Technology officer for the Change and Config­­uration Management solutions for BMC software. Prior to joining the company, he was CTo for Marimba. earlier in his career, Behnia was one of the principal technologists for Tivoli systems. he can be reached at kia_behnia@bmc.com.

ABOUTTHeAUTHOR

Copyright 2005, Line56.com

��8

LeveragingiDenTiTYinformationThroughtheCMDBAnidentitymanagementsolutionunifiesandmanagesinformationaboutpeoplewhohaveaccesstotheiTinfrastructure.Byleveragingidentitymanagement,youcanachieveacomprehensive,accurate,andup-to-datesourceofpeopleinforma--tionfortheCMDB.

The volume of information maintained by a configuration management data--base (CMDB) is rapidly increasing in

scope. Initially, the CMDB was purely an asset store that described the assets in the IT infra--structure: what they are, where they are, and their configurations. Then the CMDB evolved to include the physical and logical relationships and dependencies of the assets. Today, the CMDB includes the relationships of assets to the business services and the business pro--cesses they support. The CMDB continues to evolve, and the next necessary step in its evolution is the addition of people as configur-ation items (CIs).

People are an integral part of the IT environment. They interact with and impact the IT infrastruc--ture in many ways, depending on their roles and responsibilities. People access the IT in--frastructure and modify the information that resides in it. People who are IT staff members may even change the infrastructure itself as they add resources and update or retire existing ones.

In this article, we’ll discuss how an identity management solution can provide a compre--hensive, accurate, and up-to-date source of people information for the CMDB.

The ChALLeNGe: uNIfYING ANd NoRMALIzING dATAEnterprises already have a great deal of people information residing in their IT infrastructures. Platforms and applications maintain data about employees who have access privileges. Net--work directories include user authentication information (user IDs and passwords) and authorization information (access privileges) for the systems within their purview. The human resources (HR) system maintains location, job title, contact information, certifications held, and other employee data.

The information is voluminous and complex. Employees in diverse groups and departments have access to different applications. Access privileges vary widely depending on people’s

ByAHMADABDeL-WAHeDAnDBOBWORneR

��9

��0

responsibilities within their roles. Managers, for example, may have access to salary infor--mation in the HR system whereas nonmana--gerial employees do not. Certain members of the IT staff not only have access rights to IT resources but also are authorized to change the IT infrastructure.

The challenge in leveraging this information is that it is fragmented and scattered across the enterprise in disparate systems, each with different ways of representing data. Moreover, it is in a constant state of flux as people enter and leave the organization, and change their roles and responsibilities. So how do you unify and normalize this information? That’s where identity management comes in.

The soLuTIoN: IdeNTITY MANAGeMeNTAn identity management solution unifies and manages information about people who have access to the IT infrastructure, enabling you to control and manage that access effectively. The information falls into four areas:

Who are the users?What do they have access to?Who approved that access?What are they doing with that access?

An identity management solution gathers identity information from across the enterprise, normalizes it, and consolidates it into a single data store. The identity management data store can also hold other information about users, such as their roles and contact information.

One of the most important identity manage--ment functions is to ensure that identity in--formation is comprehensive, up to date, and consistent. To assist in this area, some solutions automatically discover identity information from the many sources across the enterprise. Automatic discovery streamlines information gathering and keeps the information in the identity data store up to date by continually

>>>>

scanning the environment and recording any changes it detects.

An identity management solution also brokers data between multiple identity and resource repositories, ensuring that all instances of a particular data item, such as a user’s e-mail address, are consistent in all locations where that item is distributed. If a change is made in one location, the solution propagates that change to all relevant locations.

The CMDB continues to evolve, and the next necessary step in its evolution is the addition of people as configuration items.

With the identity management solution in place, you can manage user access from a single point, enabling more effective access control and greater agility in accommodating change. For example, from the data store, the solution can determine all systems to which a particular user has access. This is important when an employee terminates his or her relationship with the company. The administrator can use the identity management system to immediate--ly and completely revoke all access privileges on all relevant systems, and eliminate lingering access, which is a common security hole.

IdeNTITY INfoRMATIoN ANd The CMdBWell-designed CMDBs, like their identity data store counterparts, are built on a federated architecture that permits consolidation and maintenance of information without actually moving it to the CMDB. In this way, the CMDB can leverage the vast amount of information currently available across the IT infrastructure without having to replicate the data and store it internally.

In addition, like identity management solutions, CMDBs offer autodiscovery capabilities that scan the IT environment, gathering and con--solidating information regarding the makeup of the infrastructure. The more advanced CMDBs automatically discover the physical and logical relationships and dependencies among assets. Some even include the relationships of the assets to the business services they support through integration with service impact model--ing tools.

Vendors are working to extend the reach of autodiscovery even further to include the re--lationships between the IT assets and the business processes they support. This can be accomplished through integration with busi--ness process management tools such as the Business Process Execution Language (BPEL).

It is possible to leverage the federated archi--tecture and autodiscovery capabilities of the CMDB to extend its reach into the people infor--mation that is available in the identity manage--ment data store. Integrating the CMDB with sources of identity information enables you to include in the CMDB information about the relationships of people to the IT infrastructure. This information can then be made available through the CMDB to systems-based solutions that support IT management processes.

Identity information can add considerable value in a number of IT management areas. Here are just a few examples:

Change management. The change manage--ment team can determine which users will be affected by a planned change; notify them about the impending change; keep them informed of status; and notify them upon successful com--pletion. The business role of users affected by

Integrating the CMDB with sources of identity information enables you to include in the CMDB information about the relationships of people to the IT infrastructure.

���

���

a proposed change and information regarding the application targeted for the change can help you determine the impact to the affected users, and you can arrange alternative change schedules, if necessary.

As an example, development platforms used by application development teams should not be targeted for change near the end of a devel--opment cycle — possible impacts to the devel--opment schedule caused by an unsuccessful change would be much more severe than impacts occurring earlier in the development cycle. These functions can be automated by a systems-based change and configuration management solution. The change management team can also determine the availability of people who have the skills to implement planned changes so the team can develop meaningful schedules.

The business role of users affected by a proposed change and information regarding the application targeted to change can help you determine the impact to the affected users.

Incident and problem management. The service desk can determine which support engineers support which IT assets and obtain such con--tact information as telephone numbers and e-mail addresses. This information increases the efficiency and speed of incident resolution. Another common scenario is to have the iden--tity management solution provide a self-service function that previously was provided through the service desk (e.g., password reset, appli--cation access request). Using the identity link, the service desk system can be updated with either successfully completed transactions (closed tickets) or system issue tickets in the case where the self-service action fails to com--plete (opened tickets). For the purposes of auto--mating this process, the identity data of the

CMDB is instrumental in providing data relevant to the individual as part of the ticket creation.

Capacity planners can determine which business applications are associated with which assets and work with the business application owner to determine current and future capacity requirements.

Service level management. The service level management team can determine which users access which applications and work with those users to establish meaningful service level agreements. In addition, the team can proactively inform business users when those agreements are in danger of being missed and propose corrective action.

Capacity management and provisioning. Capacity planners can determine which busi--ness applications are associated with which assets and work with the business application owner to determine current and future capaci--ty requirements. For seasonal businesses, the employee turnover rates are cyclical and ca--pacity can be planned based on the expect--ed usage level determined by the business application owner.

The possibilities are virtually limitless and certainly exciting. n

���

OFLeVeRAGinGiDenTiTYinFORMATiOnTHROUGHTHeCMDB

5BeneFiTSAhmadAbdel-Wahedis a program manager in the Microsoft Identity and Access Management group. Ahmad is a longtime Microsoft ve teran who has a great deal of indus try experience.

ABOUTTHeAUTHORS

BobWorneris the director of solution Line Management, Identity Management Business unit, for BMC software. with more than 20 years of experience in software architecture, design, and develop­­ment, Bob is responsible for long­term market analysis and business development of BMC software’s

identity management product solutions.

You can include in the CMDB information about the relationships of people to the IT infrastructure.

You can manage user access from a single point, enabling more effective access control and greater agility in accommodating change.

You can better manage changes, because the change management team can determine which users will be affected by a planned change

and communicate with them throughout the change process.

You can increase the efficiency and speed of incident resolution, because the service desk can de--termine which support engineers

support which IT assets.

You can establish meaningful service level agreements and

determine capacity requirements, because you can know which

users are associated with which applications and assets.

���

CMDB:TheKeytoJump-StartingiTiLSuccess

ByKeVinBeHR,GeneKiM,AnDGeORGeSPAFFORD

ThreeexpertsdiscusstheirVisibleOpsmethodology,whichoffersasimpleapproachtoimplementingiTiLinfourpracticalsteps.inthismethodology,theCMDBisakeyfactorindrivingquickwins.

���

Since 2000, we have met with and observed hundreds of information technology (IT) organizations to find

those operating most efficiently and effectively. We identified eight high-performing IT teams with the highest service levels, best security, and greatest operational efficiencies. We document--ed how these highly efficient and effective organizations work so that others can jump-start their own IT Infrastructure Library (ITIL®) implementation efforts.

What makes high-performing organizations different from average organizations, both qualitatively and quantitatively? We looked for practices that were universal to all eight high-performing organizations, and we turned to ITIL as a process framework to normalize the terms the different groups used. In the high-performing organizations, common processes occurred in change, configuration, and release management, as well as in inci--dent and problem management.

All of the high performers had repeatable and verifiable processes to release infrastruc--ture components with a known working con--figuration. They had a culture of change management as a primary way to do work, and they all used causality in their incident and problem resolution processes. Here are the characteristics we identified in each of the high-performing organizations:> Server to system administrator ratios greater

than 100 to 1 — In high-performing orga--nizations, each system administrator controls more than 100 servers. In contrast, organi--zations not using effective processes have ratios of 15 or fewer servers to one system administrator. Figure 1 illustrates the server to system ratio benchmark.

> Low ratio of unplanned to planned work —In high-performing organizations, unplanned work is only 5 percent of operational ex--penses. Our research showed that average organizations spend 25 to 45 percent of their total operational expenses on unplanned, unscheduled work.

> Higher staffing early in the IT lifecycle — High-performing organizations deploy more resources and staff in the preproduction build phase, where the cost of defect repair is least expensive.

> Collaborative working relationships between IT operations and IT security — In high-performing organizations, IT operations and IT security work together to solve common objectives. IT operations performs most of the work, and IT security acts as coach and consultant. Low performers, in contrast, have a combative relationship between teams whose objectives are not aligned.

> Posture of compliance — In high-performing organizations, IT operations and auditors typically have a trusted working relationship because controls are visible, verifiable, and regularly documented. In low performers, the absence of controls causes auditors to ask questions and make suggestions, which often creates an adversarial relation--ship with operations.

> Culture of change management — There is a ubiquitous understanding throughout high-performing organizations that changes must be effectively managed to achieve business objectives. Organizations that have large amounts of unplanned work and uncontrolled change have yet to realize the causal relationships between changes and incidents.

OPERATIONS METRICS BENCHMARKS:BEST IN CLASS: SERVER/SYSADMIN RATIOS

SERVER / SYS ADMIN RATIO

“Best in Class” Ops and Security

SERV

ERS

0

100

1,000

10,000

10

1 20 40 60 80 100 120 140

Efficiency of Operation

Size

of O

pera

tion

Figure 1. Server to System Administrator Ratio

���

> Culture of causality — Through the use of controls and metrics, high-performing organizations identify and solve problems by logically studying cause and effect. In contrast, many average organizations have a culture of “let’s see if this works.”

> Management by fact — High-performing organizations value controls and metrics, not only to aid effective problem-solving, but to also aid fact-driven decision-making, as opposed to “management by belief” or “management by the honor system.”

wheRe do I sTART wITh ITIL? After studying these top performers, we set out to develop a methodology to answer the urgent question that everyone was asking: “Where do I start with ITIL?” Although ITIL provides a wealth of best practices, it lacks significant prescriptive guidance about the order in which, as well as how, the processes

should be implemented. Many of the ITIL best practices are seemingly dependent on other practices already in place. Compounding the confusion, much of the third-party information that is publicly available on ITIL isn’t based on what’s been done by top performers, and is often too general and vague to effectively aid organizations.

We assume that you may be following some of these practices already, but you may not have a centralized or unified configuration management database (CMDB) in place. A CMDB is critical to creating the linkage between functional groups. This linkage enables the top-performing organizations to provide real business value.

One key to successfully implementing ITIL is effectively utilizing information about the peo--ple, processes, and technology that make up

visible ops Practice CMdB enables you to:

StabilizethePatient – Reduce access to the production environment

> Identify CIs in the production environment quickly and easily> Limit access rights to production CIs> Create maintenance windows for production CIs

electrifytheFence – Prevent unauthorized changes

> Identify relationships between people CIs, infrastructure CIs, and change history

> Produce regular change reports about all production CIs> Compare approved change list to detected change list

ModifyFirstResponse – Link incident and problem management to recent changes

> Accompany incident ticket with history of recent changes to related CIs

> If no changes were authorized for the CI, then expand the investigation circle to the next ring of related CIs

CreatetheChangeTeam – Manage change resources

> standardize on an approval and communication process, impact assessment, and forward scheduling changes —all based on CMdB CI and relationship data

UtilizeaChangeTrackingSystem– enforce auditable process

> Create and store a history of change approval and change history related to each CI

Figure 2. Capabilities Enabled by CMDB for Visible Ops Practices in Phase 1

IT. An enterprise CMDB consolidates this in--formation and enables you to take action on it. We developed the Visible Ops methodology based on four key phases. In each phase, use of configuration item (CI) data contained in a unified CMDB enables the people and processes to effectively implement some of the key practices.

PhAse 1STABiLizeTHePATienTThe goal of the first phase is to reduce the amount of unplanned work as a percentage of total work to less than 25 percent. You curb the number of surprise system outages by freezing change outside of scheduled main--tenance windows. To reduce mean time to repair (MTTR), you also ensure that incident and problem managers have all change- related information at hand to determine the cause of an outage.

CI data contained in the CMDB enables the people and processes to effectively implement some of the key practices in this phase. (See Figure 2.)

COMPLiAnCeAnDTHeCMDB

An increasing number of regulations and

privacy laws directly affect IT. As a result, key

processes must be defined, and IT personnel

must follow the defined processes. The

processes must include activities to mitigate

identified risks. And the process and results

must be auditable.

The CMDB provides a central store of data

that helps you meet compliance requirements

in several important ways. First, the CMDB

and IT service model can help you quickly

identify what is in scope for various IT audits.

Second, CMDB data can help you confirm

that the controls function as designed. And

third, the CMDB can help you verify that

changes and configurations are controlled

to the specification of audit requirements.

Without a CMDB, you’ll need to audit various

data stores and IT processes separately,

driving up costs. A unified CMDB can help

support common processes, which are

more easily documented and controlled,

across the entire IT organization. Finally,

you can reduce the impact of control and

audit requirements on IT functions when you

have a central CMDB and data. The result is

faster compliance and lower ongoing cost

of implementing and maintaining effective

controls in IT.

A CMDB is critical to creating the linkage between functional groups.

���

��8

PhAse 2CATCHAnDReLeASe;FinDFRAGiLeARTiFACTSIn this phase, you inventory CIs and services to identify those with the lowest change success rates, highest MTTR, and highest business downtime costs. You identify fragile artifacts — those infrastructure items that are difficult and costly to support and maintain, are tied to an audit requirement, or are critical to the busi--ness. You treat these fragile artifacts with extra caution to avert risky changes and massive episodes of unplanned work.

If you haven’t yet started a CMDB implementa--tion, the key here is to identify the fragile artifacts and populate your CMDB with information about those CIs first. The CMDB can enable many capabilities, as shown in Figure 3.

PhAse 3CReATeARePeATABLeBUiLDLiBRARYIn Phase 3, you establish a repeatable build process for the most critical CIs to enable a “cheaper to rebuild than repair” philosophy. By this phase, you typically can reduce un--planned work to less than 15 percent and dramatically reduce the number of different configurations in the production environment.

You’ll reap the highest return on investment from implementing effective release manage--ment processes, but you’ll need to complete the first two phases to successfully get through this phase. You will have to define build mech--anisms, create system images, and establish documentation. The result is a repeatable process for building infrastructure from “bare metal.” CI data contained in the CMDB enables the implementation of some of the key prac--tices in this phase. (See Figure 4.)

VisibleOpsPractice CMDBenablesyouto:

CatchandRelease – Audit and tag all infrastructure components

> serve as a central location to store information about each identified CI

> enable identification of dependency information about related CIs> enable centralized storage of key CI attribute data

FindFragileArtifacts – Identify and label critical or hard­to­repair components

> Correlate and analyze change history and change success rate of each class of CI

> enable a change risk assessment of planned changes to historically fragile CIs

PreventConfigurationMutation – Prevent out­of­process changes

> enforce the change process in Phase 1 as a way to enforce the update of the CI inventory in the CMdB

Figure 3. Capabilities Enabled by CMDB for Visible Ops Practices in Phase 2

��9

PhAse 4enABLeCOnTinUOUSiMPROVeMenTIn the previous phases, you progressively built a closed loop between the release, control, and resolution processes. This final phase implements metrics to enable the continuous improvement of all of these processes to best meet business objectives.

Philipp M. Nattermann wrote in The McKinsey Quarterly that if all you are doing is adopting best practices, then eventually, all you are going to get is competitive parity.1 To really excel, you need to optimally apply all your resources to achieve the real business goals.

The CMDB is IT’s knowledge repository and, as such, is a critical enabler of cross-functional performance measurement. When information is federated between a centralized CMDB and various other applications that help you manage functional processes, the consumers

and users of vast quantities of data are brought together.

We recommend a core set of performance metrics based on what we learned from studying top performers. Much of this data can be found in a CMDB or integrated from other data stores:

ReLeAse MeAsuRes> Time to provision known good builds —

How long does it take to build and provi--sion the infrastructure from bare metal? Shorter is better, and should be shorter than any MTTR requirement.

> Number of turns to establish a known good build — How many times must the build be modified before it is acceptable for deployment? Lower is better. A high number indicates the need for a more automated process.

visible ops Practice CMdB enables you to:

enableaReleaseTeam – deploy reliable configurations into production

> Identify production CIs > Identify functional state of CIs> Provide clear picture of target release environment

to ensure successful release

CreateaRepeatableBuildProcess –streamline production release

> Clearly identify CIs in the preproduction and production environments

> Identify CIs in a build catalog> Create a documented build process CI associated with

each item in the build catalog

MaintainaDefinitiveSoftwareLibrary(DSL) – standardize storage of approved builds

> Identify production CIs not in the dsL and those that don’t have a related build process CI

> Inventory CIs found in the dsL

CreateanAcceptanceProcessContract – Get approval from preproduction and post­production resources

> store the contract as a revision­controlled CI

MovefromProductionAcceptancetoDeploymentforallapprovedbuilds

> Process request for change (RfC) for system rollout —including risk analysis, forward scheduling of changes, etc.

Figure 4. Capabilities Enabled by CMDB for Visible Ops Practices in Phase 3

1. Philipp M. Nattermann, “Best practice does not equal best strategy,” The McKinsey Quarterly, 2000 Number 2. www.mckinseyquarterly.com/article_page.aspx?ar=809&L2=21&L3=35

��0

> Shelf life of builds — How long will each build be in production until it is replaced? Longer is typically better, because it enables release management teams to stay out of reactive mode.

> Percentage of systems that match known good builds — According to the detective controls, how many production systems actually match their corresponding golden builds? Higher is better, because it indicates the absence of uncontrolled production configuration drift.

> Percentage of builds that have security signoff — How many configurations are approved by security? Higher is better, because it indicates that security is involved in the standard “blessing” process.

> Number of fast-tracked builds — How many builds are rushed into production through the emergency change process? Lower is better, because each fast-tracked build represents a deviation from the in--tended process.

> Ratio of release engineers to system ad--ministrators — What percentage of staff is deployed on preproduction processes? Higher is typically better because the cost of defect repair is much lower in preproduction.

ChANGe ANd CoNfIGuRATIoN MeAsuRes> Number of changes authorized per

week — How many changes, as measured by the change management process, are implemented? In general, higher is better, as long as the change success rate remains high as well.

> Number of actual changes made per week — How many changes, as measured by detective controls, are implemented? In general, higher is better, but should not be higher than the changes authorized by the Change Advisory Board (CAB).

> Number of unauthorized changes — How many changes circumvent the change process? This is typically measured by using the detective controls, or worse, through unplanned outages. Lower is better.

> Change success rate — How many changes are successfully implemented, without causing an outage or episode of unplanned work? Higher is better: Best-in-class orga--nizations achieve better than 99 percent.

> Number of service-affecting outages — How many changes result in service im--pairment or an outage? Lower is better.

> Number of emergency changes — How many changes require using the CAB emergency change process? Lower is typically better, since it indicates a higher percentage of planned work.

> Number of “special” changes — How many changes, for whatever reason, are made outside of the change process? Lower is better, because these indicate that a change process is not fully func--tional and that management is allowing certain categories of changes to bypass change management entirely.

> Number of “business as usual” changes — How many low-impact changes occur? This metric reflects the number of changes that have been identified as “standard” and do not require review. This metric also reflects the number of changes that can pass through without requiring change management scrutiny, but are still logged. In general, higher is better.

> Change management overhead — How much effort (in hours or staffing) is the change management function consuming? In general, this number should be low. A high number may indicate a bureau--cratic process, rather than one that enables productivity.

> Changes submitted versus changes reviewed — What is the ratio of evaluated change requests against the total change requests turned in? A lower number is better.

When information is federated between a centralized CMDB and various other applications that help you manage functional processes, the consumers and users of vast quantities of data are brought together.

OFUSinGACMDBTOSUPPORTiTiLPROCeSSeS

5 BeneFiTS

INCIdeNT ANd PRoBLeM MeAsuRes> Mean time to repair (MTTR) — The average

time to restore service after an interruption.> Mean time between failures (MTBF) —

The average time between service incidents.

CMdB eNABLes ToP PeRfoRMeRs The practices we learned from top-performing IT organizations illuminate an approach to solving IT operational process issues. Top performers have repeatable and verifiable processes for release management, a culture of change management, and incident and problem resolution processes that rely on causality. The data contained in a unified CMDB enables people and processes to effec--tively implement these practices, and the four phases of Visible Ops can provide a practical framework for more effectively implementing ITIL. We are confident that if you follow these steps, you will be able to replicate the trans--formation that other IT practitioners have achieved with their organizations. n

A CMDB consoli--dates and enables

you to act on the in--formation about the people, processes,

and technology that make up IT.

A CMDB enables key practices

that help reduce the amount of

unplanned work.

A CMDB helps you to better correlate and

analyze change history, assess the risk of planned changes, and enforce the change process.

A CMDB helps you identify CIs and

their status so you can establish a re--peatable process for building your

infrastructure.

As the knowledge repository for IT,

a CMDB is a critical enabler of cross-functional

performance measurement.

KevinBehris the CTo and chief operational strategist for IP services at the IT Process Institute. he cofounded the ITPI with Gene Kim. Kevin is an active member of the Information systems Audit and Control Association. Kevin is a frequently invited speaker called on to address a broad range of

technology and management framework topics. Kevin is co­author of The visible ops handbook.

ABOUTTHeAUTHORS

GeorgeSpaffordis the managing director of spafford Global Consult­­ing. he is a recognized expert in IT process and audit. he is a prolific author, contributing articles to a wide range of IT publications. his daily News e­mail list subscribers include high­level executives from fortune 500 and international com­­

panies. George is co­author of The visible ops handbook.

GeneKimis cofounder of the IT Process Institute and is also the CTo and cofounder of Tripwire. Gene co­chaired the Best in Class security and operations Roundtable (BIC­soRT) with the software engineering Institute. he is co­author of The visible ops handbook and is a primary researcher for the

IT Controls Benchmarking survey.

This article is based on “The Visible Ops Handbook, Starting ITIL in 4 Practical Steps” written by the three

authors and published by the Information Technology Process Institute (ITPI).

Top performers have repeatable and verifiable processes for release management, a culture of change management, and incident and problem resolution processes that rely on causality.

���

Justasaresortcondominiumsetsahigherstandardforhousing,theCMDBraisesthebaronhowiTaccessesdataaboutiTapplicationandinfrastructurecomponents.Theresultisabetterabilitytobreakdownorganizationalsilosandprovideend-to-endiTservicemanagement.

ByTROYDuMOULin

CMDB: TheResortCondominiumfor IT

���

An evolution is taking place in informa--tion technology (IT) organizations across the globe. The interest in IT service

management, the passage of business legisla--tion that impacts IT (such as the Sarbanes-Oxley Act of 2002), and the interest in standards are symptomatic of something much more fundamental.

At the root of this focus on service, process, and legislation is a growing awareness that there is no true separation between business processes and the underlying IT services and systems.

IT has become so vital to business that com--panies literally cannot function without it. For several years, organizations have increasingly relied on IT to optimize the cost and efficiency of business processes. It’s clear that no one is likely to revert to manual processes. Ultimately, this means that every business process — whether it is banking, energy production, pro-duct shipping, invoicing, or something else — is dependent on business applications and infrastructure services. And, if the way a spe--cific critical IT component enables or disables a business process is not understood, then the IT function cannot truly claim to be aligned with business.

TodAY’s I.T. ChALLeNGes Three key challenges are placing new demands on the way IT is managed. First, customers of services supported by IT have become more savvy. They demand faster response times and error-free use of the wide variety of applications found in a corporate environment. Users ex--press frustration when they receive answers such as, “The server is up. Try calling the net--work folks.” Also, business managers who care little about underlying infrastructure and

operations issues (and rightly so) are de--manding budget and cost visibility while in--sisting on end-to-end service guarantees and performance-based service level agreements.

Second, the siloed approach to managing IT is inefficient. While budgets have remained flat, IT organizations still must support new business initiatives. They face greater pressure to increase efficiency and reduce costs in in--frastructure maintenance and IT operations. Different parts of the organization are often unaware of what is happening in other areas, and, as a result, groups work at odds with each other. Planning and procurement occur at a de--partmental level instead of an enterprise level, causing IT tools, such as monitoring software, incident management systems, and inventory products, to be purchased redundantly by indi--vidual groups. The operations group implements changes that undo security patches. Managing solely by silo or technology domain creates artificial barriers. If one part of the organization holds information that another part needs to be efficient, then silos create friction and expense.

Third, IT organizations must meet new com--pliance and audit requirements that are applied to all parts of the IT function. If each silo has a different change management process, all must be documented and audited separately. The cost of each team following a different approach has increased.

As a result of these inefficiencies and new re--quirements, many IT organizations are moving away from a technology-focused approach, which emphasizes the cost optimization of technical domains and components. Instead, they are adopting the cross-functional service management practices of service support and service delivery, which focus on how techno-logy is bundled into consumable services that support business needs.

The move to end-to-end service management cannot be efficiently and reliably achieved when disparate data sources are spread across the

There is no true separation between business processes and the underlying IT services and systems.

���

organization for the sole purposes of the func--tional groups that maintain them. What’s need--ed is a central repository of record of all IT infrastructure components: a configuration management database (CMDB). While, from an IT culture perspective, this may seem like a drastic move, you simply have to look at the enterprise resource planning (ERP) systems IT has been installing for the business for the last ten years to see the same model.

CMdB As ResoRT CoNdoMINIuMLet’s compare the current state of data manage--ment to every IT domain group managing its own data on a separate island, accessible only by rowboat. Imagine that each group has built a home for this data. In some rare cases, this home is represented by an exclusive, state-of-the-art resort. However, on most islands, these data stores are represented by unique and disconnected structures that meet the needs of those nearby, but prevent easy connection to the world beyond.

Now, let’s tie this island scenario back to the business problem: A number of processes require information from these disconnected data stores, but there is limited or no access to them. In fact, in some cases, the rowboat — the only means of accessing the islands — has been hidden or the oars have been removed. This very issue has spawned an entire cottage industry of rowboat networks and integrations to tie these islands together. However, when--ever the seas get rough the rowboats must head back to the harbor.

Building a CMDB is about taking those who live in an isolated structure and moving them to a resort condominium (a.k.a. the CMDB). First, because of the numerous amenities pro--vided, it’s a better place to live. Second, the

resort condominium (CMDB) ensures that these new “residents” still own the data in their in--dividual condominium — so they don’t have to relinquish control. However, they will need to comply with condominium association rules.

With a resort condominium (CMDB), all the data is now under one structure and can be accessed through adjoining rooms, hallways, and elevators. If a unique, exclusive resort with specific functionality already exists, a perma--nent bridge is built between the exclusive resort and the condominium to improve bidirectional access. The key benefit to the condominium owners is that they now are granted member--ship access to the island resort. At this point, the condominium (CMDB) is in a position to support the various business requests and IT process needs.

CRoss­fuNCTIoNAL seRvICe MANAGeMeNT sTRATeGIes BRING New ChALLeNGesHowever, there is a problem. These new resi--dents are not accustomed to the new cultural demands of living in a shared condominium complex. While they own the condominium and are free to decorate the inside of their con--dominiums to their own tastes, they must follow guidelines that did not apply to their individual island homes. Restrictions, such as building and fire codes, now apply, and the condominium occupants must undergo annual inspections (audits). As a result of these restric--tions, many of these residents resist the move to the central condominium or long to return to the carefree island life.

Going back to the business issue, many IT managers may not be accustomed to the new cultural demands of integrated IT processes and shared data systems. Functional managers can own data in a CMDB, but they must follow guidelines that did not apply when they man--aged that data in isolated stores. Data struc--tures and maintenance procedures must be followed by all.

Given the business risk, inefficiencies, and costs, IT can no longer justify maintaining silos of data.

���

The resulting resistance to maintaining con--figuration item (CI) data in the CMDB creates a challenge for IT managers. Nonetheless, given the business risk, inefficiencies, and costs, IT can no longer justify maintaining silos of data.

The new residents have to find a way to adapt to the new living arrangement. The move to the condominium is more about culture, manage--ment, and behavioral change than it is about changing a mailing address.

Similarly, the data owners in the silos need to adapt to the new processes that are imple--mented as a result of the shift to a service management strategy. New horizontal man--agement roles, such as service and process ownership roles, are grafted on top of existing domain-based organizational structures. This requires the re-engineering of IT processes, as well as the changing of organizational structure and culture. These changes involve a number of difficult challenges:

Defining repeatable cross-departmental processes and overlaying them across domain-based organizational structuresRedefining job descriptions to include new areas of accountability and responsibilities for process-based activitiesProviding generalized business knowledge and awareness of how roles impact other functions — not only the skills required for specialized activities Changing values, beliefs, and corporate cultures from unconstructive depart mental competition to customer-focused cooperationRewarding and compensating individuals, as well as departments, on the basis of process participation Adopting collaboration tools that automate workflow and multiprocess data integration

Without a doubt, the most difficult task facing IT executives is to convince IT professionals that they don’t manage boxes and applications in isolation. For example, to the IT organization that is focused on managing and optimizing technology domains, the processes represen-

>

>

>

>

>

>

ted by the IT Infrastructure Library (ITIL®), as well as the introduction of service management tools, such as the CMDB, may seem like an incredible overhead. This type of organization will not realize the real value of the CMDB and may look at it as something that merely creates more work and has questionable benefits. Questions will be raised, such as “Where is the return on investment in implementing these processes and tools?”

However, if IT understands its relationship to the business and perceives itself as a service provider, then these processes and the sup--porting CMDB are simply the cost of doing business. The question then becomes, “How can IT even attempt to be a service provider without them?”

Implementing service management tools that integrate the links between silos can help IT overcome the challenges represented by the transition away from a technology-centric management approach. Service management tools can also be used to help encourage behav--ioral change and process-oriented accountability.

INTeGRATed seRvICe MANAGeMeNT TooLs eNABLe CRoss­fuNCTIoNAL PRoCess INTeGRATIoNEffective management of the IT environment requires a shift in approach, culture, and tools. The condominium model represents a move away from island-based point solutions to an integrated suite of IT tools.

Silo-based organizations have historically used domain-focused IT solutions and tools

Implementing service management tools that integrate the links between silos can help IT overcome the challenges represented by the transition away from a technology-centric management approach.

���

for management and monitoring. Now organi--zations realize the need for an integrated suite of tools that enable IT service modeling, process integration, and shared data access.

As organizations strive to automate the IT processes that define, support, manage, and control IT services, ITIL is becoming the global de facto standard for IT management best practices. Figure 1 represents the ITIL process--es from a tool perspective.

As shown at the center of Figure 1, ITIL estab--lishes the process of configuration management to manage, control, and provide information to all other IT processes relating to inventory, financial asset data, and relationships between

physical components and IT services. The CMDB is the repository for this information.

Other processes, such as incident and prob--lem management, focus on the support of IT services. Security, change, and release manage--ment focus on the control of exposure, changes, and the deployment of new or modified com--ponents into the production environment. Processes such as availability, capacity, IT ser--vice continuity, and financial management enable a day-to-day operational view, as well as tactical planning, modeling, and costing.

Finally, service level management translates technology components to elements of IT services and provides reporting, quality management,

Figure 1. ITIL Processes from a Tool Perspective

Service Level Management

Change Management

Security Management

Configuration ManagementRelationships

InventoryWhat / Where

Asset& TCO

CapacityManagement

ServiceDesk

IncidentManagement

Service ContinuityManagement

Financial Mgmt.for I.T.

ReleaseManagement

AvailabilityManagement

ProblemManagement

���

and relationship management between the business and the IT organization.

From a tool perspective, the relationships be--tween the ITIL processes require condominium-like connectivity as opposed to island-based point solutions that focus on a single technical domain. The concept of an integrated best prac--tice framework, such as ITIL, takes on a whole new meaning when considering the implications on the underlying automating technologies.

The benefits of a condominium model can be especially appealing to an organization sensi--tive to cost and risk:

The shared facilities and infrastructure of the condominium can be funded by the consolidation of multiple island groups. This will allow the condominium association to focus on and fund specialized projects around accessibility, high-speed transpor--tation, and the look and feel of the resort.Communication and possible evacuation and recovery become much more manage--able when the data owners all live under one roof.By taking potential changes to the condo--minium association board for voting and approval (the change management process), it is well understood how each proposed change will affect the community as a whole. The condominium association will have a better understanding of the cost struc--tures, making condominium fees much easier to define.And, most importantly, a beautiful central foyer with a directory (service catalog) provides a single entrance for visitors who wish to engage with the individual condominium owners.

>

>

>

>

>

Human Resources OrderManagement

Financial

MarketingSalesSupply

Procurement Service

Customers, products, andeverything else

Figure A. Central Data for Many Processes

LeSSOnSFROMBUSineSSinTeGRATiOnViAeRPSYSTeMS

The business has experience using software to help

break down silos and streamline processes. The widett

spread adoption of integrated enterprise resource

planning (ERP) solutions is a primary example of this

experience. ERP solutions focus on a central principle:

An organization should manage data about the busitt

ness in one repository of record that supports and

is connected to the workflow management records

and transactions for all major business processes.

(See Figure A.)

Most business processes require access to the same

data, but replicating this data in several sources is

difficult, risky, and prone to error. These complications

have encouraged the trend toward a data management

model in which a central data repository is understood

to be the warehouse of record, or truth. When necestt

sary, based on unique functionality requirements,

this central repository receives data from a collection

of child repositories for consolidation, management,

harmonization, and improvement.

IT faces the very same challenges that prompted the

business to move toward the ERP model.

Like business processes, various IT management

processes require access to data about technology,

people, and business relationships from different

perspectives. For example, information about an

application or a server should, in principle, be stored

in one database record. Depending on the process

that requires this data, the data may be viewed

differently or even called different names.

Procurement might refer to the server, for example,

as an inventory record that focuses on attributes

such as the lifecycle, owner number, and location.

Asset management uses an asset record to contain

attributes of the server, such as cost, leasing, contract,

and licensing information. Change management

might refer to the server using a configuration item

record, in which the focus is on relationships and the

business impact of that server. The principles of data

management dictate that regardless of which prott

cesses control and manage data, the data should be

stored and managed only once.

��8

5TiPSFOROVeRCOMinGi.T.SiLOS

Create a central re--pository of record of all IT infrastructure

components: a CMDB.

Re-engineer IT pro--cesses and change the organizational structure and culture as needed

to shift to a service management strategy.

Convince IT pro-fessionals that they don’t manage boxes

and applications in isolation.

Implement service management tools that integrate the

links between silos.

Support the relation--ships between the ITIL processes by

using cross-functional connectivity rather

than point solutions that focus on a single

technical domain.

INTeGRATed seRvICe MANAGeMeNT TooLs BeCoMe MIssIoN CRITICALWhen organizations integrate IT processes with the CMDB, they can more efficiently deliver end-to-end service management. Implement--ing an integrated service management tool supported by a CMDB is a critical success factor in supporting an effective IT service management initiative.

As more and more elements of IT service management become dependent on the work--flow and data, the service management tool becomes a primary workflow management and productivity application for many core IT business processes. The service management application graduates from a “nice to have” solution to a mission-critical business appli--cation. Such a tool enables cross-functional processes and the integration of IT silos. n

TroyDuMoulinis an experienced executive consultant with a solid and rich background in business process re­engineering. Troy holds the Management Certificate in ITIL and has extensive experience in leading service management pro­­grams with a regional and global scope. his main focus at Pink elephant

(www.pinkelephant.com) is to deliver strategic and tactical­level consulting services to clients based upon a demonstrated knowledge of organizational trans­­formation issues. Troy is a frequent speaker at ITsM events and is a contributing author for the ITIL book Planning to Implement IT Service Management.

ABOUTTHeAUTHOR

When organizations integrate ITIL processes with the CMDB, they can more efficiently deliver end-to-end service management.

Don’tForgetthenetwork

networkconfigurationmanagementisanimportantfunctionthatshouldbeintegratedwithanoverallconfigurationmanagementandCMDBstrategy.ForasuccessfulCMDBinitiative,followathree-stepapproachforpopulatingtheCMDBwithnetworkdata,andusepurpose-builtnetworkconfigurationmanagementtools. ByJeFFGiBSOn

��0

���

We often think that IT services rely solely on servers and applications. However, those servers and appli--

cations sit on top of the critical communications infrastructure that comprises network devices, such as routers, switches, load balancers, and firewalls. Integrating network configuration management information into your configu--ration management database (CMDB) will help you integrate the network layer into your over--all IT service model and better align IT service delivery to business needs.

NeTwoRK CoNfIGuRATIoN ANd ChANGe MANAGeMeNTIf you look at the complete picture of IT-to-business alignment — starting with business priorities and mapping down through business processes, applications, servers, databases, and virtualized environments — the network layer is the foundation, as Figure 1 illustrates. If this communication infrastructure is not properly configured and running with nearly flawless execution, the business-critical appli--cations and the multitiered Web-centric com--puting environments on which they reside will not work. When network information is included in the CMDB, you can explicitly identify these dependencies to help improve the overall management of the IT infrastructure, as well as the business processes that rely on properly functioning networks.

The management of the network layer is critical. Changes at this layer have very high risk, and failure can have broad impact. The lower the component’s position on the pyramid, the larger the number of users that will be affected by a failure. Network failures can affect thou--sands of users instantly. Unintended failures caused by misconfiguration can take entire offices, regions, and continents offline. Based on conversations with customers, we’ve found that a configuration change on a network de--vice is the most common cause of network downtime, and accounts for a staggering 50 to 90 percent of all outages, depending on the type of business.

Changes at the network layer have very high risk, and failure can have broad impact.

Network configuration and change management (NCCM) systems centralize the management of this layer and are designed to manage and control the critical configuration files. (See the sidebar, “Configuring Network Devices.”) With NCCM systems in place, you can determine the exact configuration of every network device deployed in the network environment without reading configuration files directly. These app-lications are designed to manage a variety of configuration file formats, and include the discovery and storage of configuration data for network devices.

Figure 1. The Entire Computing Stack Built on Network Devices

NCCM provides a change control and change history function that is needed to implement revision control of configuration files, as well as physical network system changes. This com--prehensive provisioning records every change that is made to that configuration or source file, and stores a copy of each configuration file revision so that you can revert to previous versions to restore working configurations. You can also schedule and automate updates to configuration files across multiple devices by various means. And, you can apply policies that check for configurations that are not allow-ed or that enforce required configurations on the devices.

You should integrate the network change and configuration process with broader IT-wide change and configuration processes. However, the network-specific aspects of the information can be included in a federated CMDB strategy so that you can share critical network information with other IT service management functions, while keeping information needed for NCCM applications separated in a local database.

CMdB eNABLes NCCM INTeGRATIoN wITh I.T. seRvICe MANAGeMeNTIntegrating NCCM solutions with a broader IT service management portfolio provides significant benefits. As organizations move away from siloed technology management, integration of network operations and appli--cation dependencies enables a complete end-to-end service management approach.

Logical connections between network compo--nents and other configuration items (CIs) are a key source of relationship dependency data in the CMDB. Including network components in the CMDB provides contextual relationships

COnFiGURinGneTWORKDeViCeS

Most router or switch configurations are stored in

files that are usually contained in the device’s flash

memory. These files are used when the device is

started and are reread when necessary to pick up

a configuration change. The files contain instructions

that configure the devices to operate in a certain

manner — much the same way as operating system

configuration files and application configuration

files. These files are full of details and are often

difficult to read except by network engineers.

Network engineers and administrators frequently

change the configuration of network devices. They

add, remove, and change content in these critical

files that determine the operation of the router itself.

They may also change the board and cards within

the hardware, and such changes will appear as

changes in the configuration files.

During the past few years, multifunction devices

have become prevalent. For example, single devices

may provide routing and switching capability, or

a single device may have many blades, appearing

as multiple devices in the same chassis. These dett

vices, along with firewalls and load balancers, yield

various configuration schemes that are often more

complicated, adding to the complexity of the mantt

agement of the network layer.

Many network device vendors offer simple tools

that support changes to their products. Other ventt

dors offer tools that help manage other aspects

of network device configuration. However, to stantt

dardize and structure the management of these

critical devices across the enterprise, organizations

often deploy purposetbuilt network configuration

and change management (NCCM) applications

that allow the IT organization to take control of the

network at the device level.

Logical connections between network components and other configuration items (CIs) are a key source of relationship dependency data in the CMDB.

���

���

that enable you to view the business impact of network components. You will know exactly which components of the network infrastruc--ture support specific business services.

A federated database of network CIs supports the IT Infrastructure Library (ITIL®) framework for change and release management as it re--lates to network infrastructure elements. As a result, you can control changes to that in--frastructure in accordance with ITIL-defined processes. This provides greater availability, reliability, and security for business services and ensures that the services do not become isolated islands of value.

You can better set and deliver systemwide ser--vice level commitments for various IT functions by leveraging a centralized CMDB that contains shared information about CIs, including all network devices. Some of the common integ-ration points with other IT service management functions that leverage network-related CI data in a CMDB include:

> Integration with change management — All network change requests should go through the enterprisewide change manage-ment systems. The NCCM system can initiate the change request. After risk analysis, approval status can be passed back to the NCCM system, which can then implement the change, provision the new configura--tion file at a predetermined time, and store a copy of the new configuration file revi--sion. After successful implementation, the enterprisewide change system can close the change request.

> Integration with incident management — NCCM policy violations can automatically generate an incident ticket with the service desk. You should resolve each network configuration policy violation following the enterprisewide incident and problem management process.

> Integration with service impact manage--ment — The logical dependency relation--ships of the network are critical to providing a business-relevant picture of IT services. Router configuration changes don’t always affect the whole router, but can be limited to traffic on certain routes. With detailed network dependency information in the CMDB, you have a specific view of busi--ness impact.

ThRee­sTeP APPRoACh foR PoPuLATING The CMdB Data about network components is stored in a centralized CMDB as CIs. You should add network data to the CMDB only if it helps iden--tify business impact and enables alignment of the IT infrastructure with business priorities.

Some network data should not be in the CMDB. For example, specialized data needed to manage network interconnects — such as vendor-specific device settings or control and provision--ing of configuration files that require additional

COnFiGURATiOnMAnAGeMenTTeRMinOLOGYITIL configuration management focuses

on maintaining accurate information in

the CMDB. You could also think of this

as configuration item (CI) management.

Network configuration management focuses

on the settings in configuration files that

control the proper function of a network

device. Another way to look at it is as settt

tings management.

Thus, network configuration management

is related to overall ITIL configuration

management, but is function specific

(focused on networks) and more concer ned

with provisioning and known good contt

figurations (settings).

You should add network data to the CMDB only if it helps identify business impact and enables align-ment of the IT infrastructure with business priorities.

OFinCLUDinGneTWORKDATAinTHeCMDB

5 BeneFiTS

attribute data — is best stored in the network configuration management tool database.

Network data should be added to the CMDB in phases as you build up related tools and analy-tics. A three-step approach is recommended.

sTeP 1ADDneTWORKDeViCeSIn the first step, you should add network devices, such as routers, switches, firewalls, and load balancers, to the CMDB. The goal is to inventory what network devices are in the production environment. At this point, you can begin to draw critical impact relationships and integrate change management with the rest of the IT infrastructure.

Some agentless discovery tools may find basic information about network devices. Other, more specialized tools may find detailed configura--tion information about both the hardware and configuration settings of the device. Other tools may also find firewall and application server software that may be considered part of the network. A combination of discovery tools can be used to populate the CMDB with baseline information about what makes up the network.

sTeP 2 ADDDeTAiLeDHARDWAReDATAIn Step 2, or as a parallel step to Step 1, you should add more detailed hardware data for those devices, such as cards or memory. The cards and the memory are subcomponents of network devices. They are frequently changed and should be identified as CIs in the CMDB.

sTeP 3 ADDLOGiCALCOnFiGURATiOnReLATiOnSHiPSIn the final step, you should add logical con--figuration relationships, such as the actual network interfaces on the devices. Adding relationship and dependency information enables you to view the service impact rele--vant to network data in the CMDB in a much more granular manner.

For example, numerous network interfaces will reside on a single device. Many times, these interfaces (you can think of them as logical ports) have independent configura--tions. One interface may be to the services of a certain set of applications and databases, while another interface may impact relation--ships to a different set. Adding this logical information to the CMDB allows for much finer-grained impact relationships, which is a more accurate view of the service model. From this information in the CMDB, you will gain a picture that includes the physical device, the physical connectivity, and the logical connec-tivity to applications that are used as part of business processes.

The deeper logical configuration data should remain with the network configuration appli--cations. But down the road, when the analytics surrounding CMDBs become more sophisti--cated, this could be centralized as well.

NeTwoRK dATA IN The CMdB foR BeTTeR I.T. MANAGeMeNT The network is the foundation of the IT infra--structure. In the modern business, the network is so critical that even interaction with the out--side world is dependent on it. Without it, nothing functions. Therefore, bringing network data into the CMDB should be a top priority of any business — especially those seeking to better manage their resources through ITIL and other best practices. n

JeffGibsonhas more than a decade of experience in software development in both product development and enterprise IT. he currently leads a team at voyence focused on integrating the company’s network change and configuration management product with other vendor technologies to produce higher­value solutions for customers and partners.

ABOUTTHeAUTHOR

You gain insight into contextual relation--

ships, which enables you to view the busi--ness impact of net--work components.

You gain a picture that includes the

physical device, the physical connectivity, and the logical con--nectivity to various

applications that are used as part of busi--

ness processes.

You can explicitly identify dependencies to help improve the overall management

of the IT infrastructure.

You can control infra--structure changes in accordance with ITIL-defined processes,

enabling greater avail--ability, reliability, and security for services.

You can better set and deliver system--wide service level commitments for

various IT functions.

���

The configuration management database (CMDB) is fast becoming the unified source of information for IT service

management functions. The CMDB provides an important store of information about assets and configuration items (CIs) in the IT infra--structure, including their relationships and dependencies. The CMDB also contains infor-mation about the alignment of IT resources with an enterprise’s business needs. IT personnel increasingly rely on such a data source to effectively manage the incident, service, and support processes.

CanPeopleBeConfigurationitems?

���

GetmoreoutofyourCMDBand

streamlineyouriTservicesupportby

maintainingadynamicrepositoryofinforma--

tionaboutthepeopleinvolvedin,andaffectedby,

theincidentmanagementprocess. ByTROYMcALPin

��8

Can people be CIs too? The answer is an over-whelming “yes.” People can — and should — be CIs because they represent an organization’s human assets. Therefore, the CMDB should include data about the relationship of an event to the business customers who rely on a ser--vice, as well as the relationship of an event to the personnel required to resolve it in the incident management process. This relationship information relies upon data about People CIs.

People CIs are an obvious extension to the data you already include in the CMDB. Personnel, after all, are some of the most expensive resour-ces in IT. Information about people can improve your organization’s ability to resolve incidents and provide IT services to the business.

PeoPLe CI dATAWhat information about people should you maintain in your CMDB? You’ll want to include their duties, skills, certifications, and interests, as well as the services they use and the services they support. Relevant contact information, such as phone or pager number, e-mail address, instant messaging handle, location, language, time zone, and schedule, should also be inclu-ded. In other words, People CIs should include the following information about the people who consume and provide services: who they are, what they do, how you find them, and the events and services that are pertinent to them.

People CIs have attributes that help you under-stand who the best person is to help resolve an incident. The attributes also can indicate that a person is an end user of IT, is associated with a particular service, and wants to know about an impact or a potential service level agreement (SLA) violation, for example.

Sometimes, a person will play different roles depending on the event. Someone may be a direct impact person for one type of event because of a dependence on a particular asset or service. But, for another type of event with a different asset, that person may be respon--

sible for resolving incidents. For example, if a network component fails, the network support or operations team is primarily responsible. However, the network security group may also need to be informed about the failure. You have to understand the person’s relationship to the service and the different components that make up the service, as well as the role the person will play.

Because a person’s functions can change often, all of this information can get complicated. For example, travel plans or schedule changes affect someone’s availability. If someone gains additional technical certifications, that person can now assist on different types of events. Maintaining People CIs in your CMDB can help keep all the information straight.

AuTodIsCoveRY of PeoPLe CI dATAWhen you populate the CMDB with normal asset configuration information, you probably use an autodiscovery tool. However, discovering the relevant information about your people assets, their attributes, and the relationships affecting the incident management processes, while equally important, would likely be accom-plished in a different manner.

Discovering your People CIs can be especially challenging. These CIs are mobile. They get on airplanes; they move around often; they travel from time zone to time zone; they speak different languages; they are globally dispersed; and their interests and contact methods change. You need to have a “people” equivalent to auto--discovery: a self-service collection mechanism.

People CIs are an obvious extension to the data you already include in the CMDB.

The mechanism should have a front-end user interface that allows the owner of a service, or someone who is involved in incident or service management, to provide specific infor--mation. Using the self-service functionality,

5TiPSOnPeOPLeCis

individuals would state: This is who I am, this is when I’ll be available, and this is how you find me when the events I care about occur. Because your human assets are mobile and ever-changing, don’t expect a one-time static load of People CI information to be sufficient. Stale data in the course of an event is useless data. Therefore, you should make it easy for people to access and update the information as necessary.

IT assets and tools — because they’re ma--chines that don’t have feelings — don’t care how many times they get pinged during auto--discovery. Humans, on the other hand, tend to be a little more upset when they get pinged often. Participants will be more satisfied with the process if the updating of People CI infor--mation is accomplished through a straight--forward, Web-based, self-service mechanism. If you need a more forcible approach, remind them periodically that they need to confirm the accuracy of their CI information, and auto--matically invalidate unconfirmed data on a timed basis.

MATChING PeoPLe CIs To INCIdeNTsUsing People CI data can benefit incident ma-nagement and support. Not only can this data help you identify the best person to resolve an incident, but it also can help you determine which people are the users of the service affec-ted by an incident. Such knowledge facilitates better communication with these users.

Storing the People CI information in your CMDB enables other service impact and systems management applications to use it. For ex-ample, say an original event is dispatched as a low-severity ticket, and appropriate people are assigned to work on the problem. However, the attempted resolution fails. Perhaps the severity of the incident changes, an SLA is about to breach, or something changes the way the event is proceeding. Proactive communi--cation to the business users of the affected service is now necessary.

The content of your communication is very important — you need to relay appropriate information to the right people. Knowing attri-butes about people and their roles in different processes will help you deliver context-sensi tive information.

As a result, business users of the services IT provides will have a higher degree of satisfaction because you will be able to target information more specifically and reduce the all-too-com--mon noise of the incident management process. When users receive messages that are filtered and relevant to them, they are unlikely to tune out the information. Your messages to them should be few and pertinent — sent only when there is a direct impact to the services they need.

A LooK To The fuTuReIncident resolution and notification can become an automated process. Events and incidents detected by management applications can be enriched from the CMDB and matched against personnel who are best suited to cure the in--cident. Those personnel can be located, notified, and enabled to resolve the event based on the expert information in the CMDB. The service desk, service owner, business service owner, and other impacted stakeholders can be pro--actively notified with relevant information about the incident. As a result, you can reduce the number of support tickets, increase service levels, and ensure personnel assets are focused on important business services. n

TroyMcAlpinis the founder, chief executive officer, and chairman of Invoq systems. The company develops and provides automated, broad­scale notification and inter­­action solutions to customers in a wide range of industries.

ABOUTTHeAUTHOR

Include information in the CMDB about

your personnel assets (People CIs).

Capture the attributes, interests, skills, and duties for the people involved in, or affec-ted by, the incident

management process.

Establish a self-service collection mechanism for gathering and up--dating People CI data.

Use the CMDB to match incidents with the personnel best-

suited to resolve them.

Let the CI data help you communicate

the appropriate information to the

right people.

��0

Lego® revolutionized building blocks by providing a set of standardized pieces with uniform connectors that children

of all ages can assemble to create large struc--tures of nearly infinite variety. Service-Oriented Architectures and Web Services have brought a similar revolution to application development.

The Web Services model offers a building-block approach in which each “block” delivers a particular business service, such as credit card verification. Like Lego blocks, these services have standard interfaces, so you can easily combine them to create larger services. For example, you can integrate a credit card veri--fication service with other services to create an online order entry service. Such services are also called composite services.

Web Services have some interesting properties that make them a valuable building block for the IT-intensive enterprise. First, once devel--oped, a Web Service can be reused many times, which drives down development costs and cuts development time. Second, Web Services are independent of both location and platform, so you can combine services even if they reside on different servers, in different organizations around the world, running different operating systems and applications. Third, independent

software vendors have added standard Web Services interfaces to their applications, ex--posing application functionality as a Web Service. As a result, business application programmers can now take advantage of Web Services to integrate applications and third-party systems.

The Web Services model offers a building- block approach in which each “block” delivers a particular business service.

What makes this really powerful is the addition of tools and standards that allow the execution of these services to be combined into a process flow. A standard that creates a common ap--proach to process-based execution of Web Services is the Business Process Execution Language (BPEL). BPEL is an XML-based programming language designed to utilize the Web Services interface that connects to applications and third-party systems. BPEL is now backed by major industry players, such as BEA Systems, IBM, Oracle, and SAP. BPEL enables programmers to define entire business processes that execute though a managed series of Web Service calls. The processes designed in BPEL can be easily combined to create even higher-level processes — to any level of hierarchy.

WhenCMDBinformationlinksaBPeL-designedbusinessprocesstoWebServicesandunderlyingiTservices,youcandramaticallyimprovethealignmentofiTwiththegoalsofthebusiness.

TOMAnAGei.T.FROMTHeBUSineSSPeRSPeCTiVeByDeVeSHSHARMA

using BPeL, BsM, and the CMdB

���

Two sIdes of A GReAT sToRYBPEL enables you to take a giant leap forward in business process and application development. You can now develop business applications from the top down by starting with a simple definition of the business processes you want to enable. These processes can transcend the boundaries of traditional packaged business applications, paving the way for the develop--ment of composite applications that span multiple traditional applications. What’s more, BPEL makes it easier for IT to work closely with business managers in developing business applications because it provides a common means of communication that both parties can understand.

But enhancing business application develop--ment is only half the story. The other half is equally exciting. BPEL enables you to take a giant leap forward in aligning IT with the goals of the business. A BPEL-designed business process, by definition, identifies the underlying Web Services needed to execute the process. Those Web Services are tied to and executed on specific IT infrastructure components. Therefore, BPEL provides the link between the business process and underlying IT services and infra--structure. That link is critical to managing and prioritizing IT resources from a business per--spective. With the combination of BPEL and Business Service Management (BSM), your IT organization can step up the service maturity ladder and manage IT services from a business process perspective.

You can now develop business applications from the top down by starting with a simple definition of the business processes you want to enable.

CMdB — A NATuRAL LINK, A NATuRAL evoLuTIoNThere is a natural place in the IT service management infrastructure to link IT service management tools and solutions with BPEL.

That place is the configuration management database (CMDB). In fact, BPEL awareness is a natural next step in CMDB evolution.

The CMDB evolved from an IT asset repository to a more sophisticated data source that houses not only assets but also their physical and logical topologies. Today, the CMDB is evolving further to include the relationships among assets and the business services they support. This evolution has been enabled primarily by a corresponding evolution of autodiscovery tools that populate the CMDB. These tools have advanced from discovering assets to discovering the physical and logical relationships of the assets. And, like the CMDB, autodiscovery tools are continuing to evolve to discover the relationships of the assets to business services.

By having business processes de- fined in the CMDB, the IT organization will now have increased visibility into the business.

The natural next step in CMDB evolution is the discovery of the relationships between business services and business processes. This step will be enabled primarily by the evolution of autodiscovery tools to capture these relationships from BPEL processes. Another exciting possibility is to evolve infra--structure monitoring tools to permit them to leverage the BPEL information in the CMDB to monitor the availability and performance of business processes, and pass the information to a business activity monitoring (BAM) system.

By having business processes defined in the CMDB, the IT organization will now have in--creased visibility into the business. This means that knowing the real-time impact of IT events on business processes is now possible. IT can prioritize its response based on the importance to the business, rather than follow the all-too-common first-in, first-out incident management approach. In addition, the planning of IT-related changes can now take into consideration the

���

impact to specific business processes. This, then, allows IT to act in partnership with the business to assess the most appropriate time for the change, and to route the approval through the process owner. Finally, the inclu--sion of business processes in the CMDB greatly enhances regulatory compliance by providing auditors and process control departments with direct line of sight from the process to the supporting infrastructure. Through automation with autodiscovery tools and the CMDB, you have also reduced the burden on the IT department.

BeTTeR ANd BesT The implications of a BPEL-aware CMDB are enormous for virtually all IT service management disciplines. A broad range of IT service man--agement functions are greatly improved with the addition of CMDB information about the relationship of various IT infrastructure components. However, those functions are dramatically improved with the addition of CMDB information about how those IT infra--structure components are used in the course of executing a business process.

For example, IT staff focused on incident and problem management are more productive when they are armed with relationship information about the infrastructure. But they become instantly business-aware when they can determine priorities for addressing prob--lems based on the effect those problems will have on business operations. For example, if two server problems are reported concurrently, the staff can see which business processes are supported by each server, and make informed decisions about which problem to address first based on business impact. It is the CMDB information linking the BPEL process to Web Services and underlying IT services that makes this dramatic improvement in efficiency and business alignment possible.

Another example is in the functional area of change and configuration management. With information about the relationship of infrastructure components to Web Services and business processes, the staff can deter--

mine, up front, the business risk and potential impact of a proposed infrastructure change. As a result, the staff can implement the change in a way that minimizes —or even eliminates —disruption to the business, through forward scheduling of changes and proactive com--munication to potentially affected business users. Without a link from business process to IT infrastructure, that level of effective change management is just not possible.

In infrastructure and application management, the operations staff can look beyond the infra--structure and applications themselves to see the more relevant business picture. With this visibility, the staff can monitor and manage capacity, availability, and performance from a perspective that is aligned with business priorities.

BPEL-aware discovery will greatly facilitate reporting to auditors, making it easier and less costly to comply and to demonstrate compliance.

In addition, BPEL-aware discovery tools will per--mit the IT staff to immediately determine and document the relationships among IT infrastruc--ture components and business processes. This mapping, which is essential for com--pliance with government mandates, such as the Sarbanes-Oxley Act, is currently consuming many hours of IT staff time because it typically must be collected and organized manually. BPEL-aware discovery will greatly facilitate repor-ting to auditors, making it easier and less costly to comply and to demonstrate compliance.

What’s more, the discovery tools will be able to detect changes made to either the infra--structure or to the BPEL processes, and can update the CMDB accordingly. This will not only ensure the validity of the CMDB infor--mation, but also will make the organization more agile in adapting both business processes and the supporting IT infrastructure to changes in the business environment.

As with Lego building blocks, the possibilities are limitless — and the fun is just beginning. n

OFBPeL,BSM,AnDTHeCMDB

5 BeneFiTSBUSineSSPROCeSSexeCUTiOnLAnGUAGe

Business Process Execution Language (BPEL) is an XMLtbased programming language

and execution environment that is built on top of Web Services specifications. It enables

programmers to define portable business process definitions for Web Services Definition

Language (WSDL)tbased processes. These processes can be used and reused, as well

as combined into larger processes.

What’s the difference between BPEL and business process modeling tools? BPEL

actually executes processes that are based on Web Services. A process modeling

tool is generally used to depict processes. Those processes may be based on BPEL

processes, some other programming environment, or simply a process model that

is not linked to any specific technology. Because process modeling tools can be used

to design and model processes that do not include their execution components, such

a process model may differ from the actual processes being executed, whereas BPEL

brings together the offline modeling capability with actual execution (so long as the

model is driven by Web Services).

BPEL is derived from the combinaton of two similar languages: Web Services Flow

Language (WSFL) from IBM and XLANG from Microsoft. The two companies decided

to integrate their languages into a new language, BPEL4WS. In April 2003, BEA Systems,

IBM, Microsoft, SAP, and Siebel Systems submitted BPEL4WS 1.1 to the Organization

for the Advancement of Structured Information Standards (OASIS) for standardization.

The OASIS WStBPEL technical committee voted in September 2004 to release the

standard specification, named WStBPEL 2.0.

Today, a number of engines run standard BPEL processes, including engines from IBM,

Microsoft, Oracle, and SAP. Some of these engines permit graphical representation

of the processes and their interrelationships.

DeveshSharmais senior principal product manager for oracle fusion Middleware. his areas of focus include business process manage­ment, service­oriented Architecture, and applications integration. he also spearheads oracle’s strategy for business process modeling and simulation tools. devesh has more

than 14 years of diverse experience in the IT industry.

Jihadel-Assaad,PierreGermain,andMatthewSelheimer also contributed to this article.

ABOUTTHeAUTHOR

Enhanced ability to prioritize and address problems, based on

business impact.

Increased agility in adapting both busi--ness processes and

the IT infrastructure to changes in the busi--ness environment.

Improved ability to comply with govern--

ment mandates through reporting of relationships among infrastructure compo--nents and business

processes.

Enhanced monitoring and management of process availability and performance.

Greater insight into how proposed

changes will affect business processes.

���

In the first edition of VIEWPOINT, we intro--duced you to Dr. Henry, CMDB. In case you missed that article, you should be aware

that Dr. Henry is a fictional therapist, with a specialty in infrastructure management. He has great credentials for dealing with pain in the enterprise. Unlike other experts, Dr. Henry started his career as a CMDB (configuration manage--ment database) before becoming a therapist to help patients deal with CMDB troubles.

What? How can a CMDB be a therapist? The answer actually makes a lot of sense, once you analyze some basic concepts. A therapist helps you deal with pain, understand rela--tionships, and focus on what’s important to you. A CMDB provides the single source of accurate information about your infrastruc--ture, finds meaning in relationships, helps you manage those relationships, and does what’s

necessary to enable your IT organization to realize its full potential. Dr. Henry offers the best of both worlds.

Dr. Henry recently met with me to discuss questions he has received from patients on some of the most pressing issues facing IT organizations today:

Q: “I’m having real problems with my rela--tionships. I can no longer sort out how one configuration item relates to another. It’s stress-ing me out. Any advice you can give me?”

Dr. Henry: While other therapists may tell you that your problem with relationships stems from issues in your childhood, I have more practical suggestions that will actually help you. You should consider using a CMDB, which provides a common data model for

Are your CMDB relationship problems keeping you up at night?

Dr. Henry, fictional therapist, helps you deal with pain in the enterpriseJust ask Dr. Henry

���

storing IT configuration item information and their relationships. This single source of record provides a logical model of your IT infrastructure and services. With this model, you can identify, manage, and verify all configuration items and their relationships in your IT environment.

Q: I’ve tried to implement a CMDB multiple times and I keep getting the same results. There’s more data in my CMDB than I know what to do with. This can be overwhelming. I know I should get rid of some relationship data, but I just can’t seem to discard anything because I might need this information some--day. What should I do?

Dr. Henry: You’re suffering from the classic “pack-rat” syndrome. I see this all the time. People with this condition tend to keep big piles of magazines they never throw out, hang on to really old computer diskettes

(yes, diskettes), keep food in their refrigerators until it starts to smell, and have a real affinity for saving old shopping receipts. They have every computer they ever purchased stored in their offices, along with old printers that no longer work. Fortunately, there is hope for this condition, so pay attention.

With a CMDB, you can identify, manage, and verify all configuration items and their relationships in your IT environment.

First, you have to understand the problem. You must accept the fact that you have more data than you know what to do with — and that you need to store less critical data outside of the CMDB. For example, do you need to have CD-ROM drive information for every desktop in your organization in the CMDB?

ByLinDADOnOVAn

���

Probably not. And if you do, you can store it somewhere else, just in case you need this information in the future. It means letting go of the old hoarding habits and freeing up your CMDB to focus on the data you need. So, put the less-relevant information into an extended data layer, which is available if your CMDB is based on a federated data model. With this federated approach, the data is always there for you if you need it. It’s like cleaning out your closet and storing in the garage the things you don’t use every--day. You still have the things you can’t bear to throw away, but they are not cluttering up your home.

Q: It’s too difficult to keep track of the location of different systems, PCs, and other items in my enterprise. So, I wind up buying more equipment, and my costs are getting out of control. I’m so upset about this that I can’t sleep at night. Any suggestions?

Dr. Henry: Let’s talk our way through this problem and take action. What you’re really looking for is a way to get control of all this data. Aren’t you aware of the great potential of a CMDB to track elements in your infrastructure and sort out how these elements are related? I don’t want to brag, but I’ve got this situation all figured out.

Here’s what you should do. Think about how using a CMDB with asset management will reduce costs. The CMDB, along with other solutions, will help you to track which assets are used for which purposes, or identify the availability and service problems related to certain types of assets. It’s too expensive and unnecessary to have to buy more assets than you need. With a CMDB, and other solutions that work with it, you can get the maximum advantage out of your IT assets and software. It offers an accurate view of available assets and how these assets are being used.

Q: Our IT organization just can’t respond fast enough to business needs. My business-side customers are screaming that we’re unrespon--sive, and my budget is being cut. Can you help?

Dr. Henry: Hmmm….I think this calls for some regression therapy. If I were treating you as an individual, I’d ask you about your childhood, how you handled challenges over the years, and what made your life difficult. But this isn’t about you — it’s about your enterprise. So let’s understand how your IT organization got into this situation in the first place.

Chances are you probably had a lot of changes happening all at once. The CMDB should be able to ease the pain by providing a single source of truth for change management, incident management, and configuration management, so that transactions and changes that support one area of the business don’t have a negative impact on another area.

You know, that brings me to an important point about relationships: honesty and truthfulness. These two attributes are critical to relationship success, and the CMDB provides that single source of truth. With central, up-to-date infor-mation about configuration items, IT departments can be more responsive to business needs and have greater ability to support service management processes.

With central, up-to-date information about configuration items, IT departments can be more responsive to business needs and have greater ability to support service management processes.

���

Put the less-relevant information into an extended data layer, which is available if your CMDB is based on a federated data model.

Q: I couldn’t wait to get results from our CMDB, so I tried just to get everything implemented as soon as possible. The process was chaotic. It was keeping me up at night worrying. I even had a nightmare that I went to turn on my computer and it started to attack me. I just couldn’t take it. Halfway through the project, I gave up. There was just too much to do and so little time. Can you help me?

Dr. Henry: It’s been awhile since I’ve done dream therapy, so bear with me. You have a lot of anxiety about this project — to the point you’re dreaming that the computer is attacking you. That’s not a good sign, especially since your livelihood is based on computers and what they represent.

It’s obvious that you tried to implement a CMDB without following the recommended phased approach. You would have been much more successful if you tried to more fully understand the scope of the project and break it down into manageable chunks. Maybe you didn’t ask the right questions when you first began the project, so you didn’t fully understand the data require--ments. Perhaps you forgot to go to the IT Infra--structure Library (ITIL®) to learn about best practices before the project was underway. Maybe you didn’t comprehend the state of your infrastructure, or you had unclear definitions of the IT services and their alignment with the business. And, perhaps you got too many people involved in the project, without clearly identifying their roles, and it spun out of control. Remember, a phased approach is a healthy approach.

Well, our session is ending, so be sure to reflect on what I’ve said. Define the scope of your activities. Write down your thoughts

about how you plan to do an implementa--tion in phases. And make an appointment to meet with me next week. n

ABOUTTHeAUTHORS

LindaDonovanis a senior strategic marketing manager who manages the BMC software Thought Leadership Council, a group of experts tasked with providing commentary, analysis, and insight for IT executives and their teams. Linda has broad experience in the enterprise software and aero­­space industries, including expertise

in IT program marketing, communications, and strategic analysis. she has been the editor of a variety of corporate publications and has taught communications courses at three universities.

Dr.Henry,CMDB, is an accomplished CMdB therapist with more than 15 years of experience in the software industry. his practices are worldwide and he resides in cyberspace.

CONTRIBUTORS

We greatly appreciate the contributions of the following people and companies:

Ahmad Abdel-Wahed, MicrosoftAlexandre Avelar, CSC BRASILKia Behnia, BMC SoftwareKevin Behr, IT Process InstituteCharles BetzTom Bishop, BMC SoftwareDavid Chiu, BMO Financial GroupLinda Donovan, BMC SoftwareDennis Drogseth, Enterprise Management AssociatesTroy DuMoulin, Pink ElephantV’Ali Ford, EMSJeff Gibson, VoyenceGene Kim, IT Process InstituteJoe Lord, AliantJulie Manis, AccentureJonathan Markworth, CompuComTim Mason, TRM AssociatesTroy McAlpin, Invoq SystemsJavier Leyva Novoa, Quitze TecnologíaJason Odden, WiproBrady Orand, Column TechnologiesCraig Piercey, AliantFrederieke C.M. Winkler Prins, Service Management PartnersVal Sanford, SinglestepPerry Sellars, Strategic TechnologiesDevesh Sharma, OracleGeorge Spafford, IT Process InstituteSelma Turki, IBMKyle Ward, AliantHans-Heinz Wisotzky, MATERNA GmbH Information & CommunicationBob Worner, BMC Software

Editor-in-Chief: Elaine KornSenior Editor: Leanne BantsariTechnical Editor: Kurt MilneTechnical Reviewers: Brian Emerson, Dave WiltEditorial Team: Wendy Assatourian, Linda Donovan, Elizabeth Ferrarini,

Paul Mangione, Sheila Mangione, Suszi McFaddenCreative Design: Liora Blum Graphic DesignCover Photograph and Design: Della CalfeeCreative Direction: Michele Floriani, Della CalfeeSpecial Thanks: Kim Bigler, Kelly Blice, Kimberly Chihaoui, Michael Cotignola,

Jihad El-Assaad, Karl-Anders Falk, Pierre Germain, Ali Ghazanfari, Jan Hagge, Rhonda Hagstedt, Margaret Henry, Dan Hoffmann, Eric Holliday, Susana Landeira, Maggie McLening, Paul Peissner, Faye Rukstales, Matthew Selheimer, Tanya Solomon, Molly Thiel, Andy Walker

Call 800-841-2031. Learn how BMC Software BSM solutions can help your business.

©2006 BMC Software Inc. All rights reserved.

ACKNOW

LEDGEMEN

TS

Industry luminary Malcolm Fry and a team of experts, including David Chiu, Troy DuMoulin, Brian Emerson, Jeanne Morain, Michael Nicoletti, Maria Ritchie, Michael Os, Angie Massicotte, and Ken Turbitt, will guide you in the forthcoming book, Step-by-Step Guide to Building a CMDB. Filled with best practice examples and practical advice, the book details 25 steps for deliver-ing a CMDB:

1. Obtain CMDB knowledge2. Review and agree on CMDB goals3. Create a CMDB mission statement4. Review and identify governance requirements5. Review and select supporting best practices6. Identify inventory and asset requirements7. Identify and address potential problems8. Review and define benefits9. Final scoping objective and expansion planning10. Define service catalog CMDB requirements11. Define requirements for other processes, including non-ITIL processes12. Define configuration item level — IT service model13. Define configuration item relationships14. Define configuration item attributes15. Design IT model blueprint16. Select technologies for your CMDB17. Calculate and present ROI18. Construct your CMDB19. Create configuration item lifecycle management process

20. Identify and install metrics — KPIs, CSFs, and reporting

21. Build supporting processes

22. Select tool to automate CMDB population

23. Populate your CMDB

24. Train the CMDB configuration management team

25. Create a continuous service improvement program

Malcolm Fry is a recognized IT industry luminary with more than 35 years experience in information technology. He serves as an independent executive advisor to BMC Software. Malcolm is the author of four best-selling books on IT service and support, he has had many articles and papers published, and he is regularly contacted as a source of information by technology journalists. In addition, he is the solo performer in a highly successful, best-selling video and DVD series made for the Help Desk Institute. He is an original contributor to IT Infrastructure Library (ITIL®) and has Masters-level ITIL certification.

The other contributors are respected subject matter experts.Step-by-Step Guide to Building a CMDB is scheduled to be available in Sep-tember 2006. For more information about this book, and to register for a free copy, please go to www.BMC.com/StepByStep.

COMING SOONSTEP-BY-STEP GUIDE TO BUILDING A CMDB

CMDB Business Value

A Planning Checklist for CMDB Success

Demystifying Configuration Items

Implementing a CMDB-based IT Service Structure

6 Tips for Managing the “People” Factor

Published by BMC SoftwarePublished by BMC Software

A Compilation of Articles by Industry ExpertsA Compilation of Articles by Industry ExpertsVIEW

POIN

TFocus on: C

MD

B Leadership

VO

LUM

E TWO

About BMC Software

BMC Software helps IT organizations drive greater

business value through better management of

technology. Our industry-leading Business Service

Management solutions ensure that everything IT

does is prioritized according to business impact, so

IT can proactively address business requirements

to lower costs, drive revenue and mitigate risk.

BMC solutions share BMC Atrium™ technologies

to enable IT to manage across the complexity of

diverse systems and processes — from mainframe

to distributed, databases to applications, service

to security. Founded in 1980, BMC has offices

worldwide and fiscal 2005 revenues of more than

$1.46 billion. BMC Software. Activate your business

with the power of IT. For more information, visit

www.bmc.com.

This publication was created by BMC Software.

Focus on CMDB LeadershipFocus on CMDB Leadership