Downloaded 58 times
![12
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 acquis-
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 devices
Software
Database
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/UsedBy
Used By
Uses
Uses/UsedBy
Connected to
Runs on (Installed on) Runs (Contains)
Runs (Contains)
Member of / Consists of Member of / Consists of
Governs Governs Governs Governed by
Connectedto
DataExchange
Creates
Datafeed
Receives
Datafeed
Backsup/Backedupby
Connectedto
Uses/UsedBy
Runson/Runs
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
LogicalCIs
SubsystemsSystemsServices
Physical/VirtualCIs](https://image.slidesharecdn.com/9e2ebbd6-6dd4-486c-9ecb-fc7a424c3b7e-150804223803-lva1-app6892/85/BMC_VIEWPOINT_II_Focus-on-CMDB-13-320.jpg)
![82
A
number of process frameworks are
currently available to assist you in
effectively managing your IT infras-
structure: Control Objectives for Information
and relatedTechnology (COBIT), Capability
Maturity Model (CMM), and the IT Infrastruct-
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
Shortcomings
The 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 hardw-
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 applyi-
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 produ-
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 inform-
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 interprete-
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](https://image.slidesharecdn.com/9e2ebbd6-6dd4-486c-9ecb-fc7a424c3b7e-150804223803-lva1-app6892/85/BMC_VIEWPOINT_II_Focus-on-CMDB-83-320.jpg)
Uploaded byJavier Leyva Novoa
BMC_VIEWPOINT_II_Focus on CMDB
This document provides an overview of a compilation of articles focused on CMDB leadership. It contains two sections - the first with practical advice for deploying a CMDB, including planning checklists, implementation steps, design considerations, and tips for success. The second section discusses various capabilities enabled by a CMDB, such as change management, configuration management, asset management, and using a CMDB to facilitate ITIL implementations. The document was created by BMC Software and contains contributions from various industry experts on topics related to implementing and using a CMDB successfully.
More Related Content
BMC_VIEWPOINT_II_Focus on CMDB
- 1. CMDB Business Value A Planning Checklist for CMDB Success Demystifying Configuration Items Implementinga CMDB-based IT Service Structure 6Tips for Managing the “People” Factor Published by BMC Software Published by BMC Software A Compilation of Articles by Industry ExpertsA Compilation of Articles by Industry Experts VIEWPOINTFocuson:CMDBLeadershipVOLUMETWO 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 doesisprioritized 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
- 2. CONTRIBUTORS We greatly appreciatethe contributions of the following people and companies: Ahmad Abdel-Wahed, Microsoft Alexandre Avelar, CSC BRASIL Kia Behnia, BMC Software Kevin Behr, IT Process Institute Charles Betz Tom Bishop, BMC Software David Chiu, BMO Financial Group Linda Donovan, BMC Software Dennis Drogseth, Enterprise Management Associates Troy DuMoulin, Pink Elephant V’Ali Ford, EMS Jeff Gibson, Voyence Gene Kim, IT Process Institute Joe Lord, Aliant Julie Manis, Accenture Jonathan Markworth, CompuCom Tim Mason, TRM Associates Troy McAlpin, Invoq Systems Javier Leyva Novoa, Quitze Tecnología Jason Odden, Wipro Brady Orand, Column Technologies Craig Piercey, Aliant Frederieke C.M. Winkler Prins, Service Management Partners Val Sanford, Singlestep Perry Sellars, Strategic Technologies Devesh Sharma, Oracle George Spafford, IT Process Institute Selma Turki, IBM Kyle Ward, Aliant Hans-Heinz Wisotzky, MATERNA GmbH Information & Communication Bob Worner, BMC Software Editor-in-Chief: Elaine Korn Senior Editor: Leanne Bantsari Technical Editor: Kurt Milne Technical Reviewers: Brian Emerson, Dave Wilt Editorial Team: Wendy Assatourian, Linda Donovan, Elizabeth Ferrarini, Paul Mangione, Sheila Mangione, Suszi McFadden Creative Design: Liora Blum Graphic Design Cover Photograph and Design: Della Calfee Creative Direction: Michele Floriani, Della Calfee Special 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. ACKNOWLEDGEMENTS 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 knowledge 2. Review and agree on CMDB goals 3. Create a CMDB mission statement 4. Review and identify governance requirements 5. Review and select supporting best practices 6. Identify inventory and asset requirements 7. Identify and address potential problems 8. Review and define benefits 9. Final scoping objective and expansion planning 10. Define service catalog CMDB requirements 11. Define requirements for other processes, including non-ITIL processes 12. Define configuration item level — IT service model 13. Define configuration item relationships 14. Define configuration item attributes 15. Design IT model blueprint 16. Select technologies for your CMDB 17. Calculate and present ROI 18. Construct your CMDB 19. 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 SOON STEP-BY-STEP GUIDE TO BUILDING A CMDB
- 3. 05 A Messagefrom Tom Bishop Chief Technology Officer, BMC Software Section 1 PRACTICAL Advice for DEPLOYING A CMDB 08 The IT Service Structure: Insight Gained through Implementing a CMDB A 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. By David Chiu 16 Ensure CMDB Success With a Planning Checklist Ask the right questions before you start your large enterprise CMDB implementation, and the project will be much smoother. Use this checklist as a guide. By Selma Turki 22 Four Practical Steps to a Successful CMDB Implementation You 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. By Joe Lord, Craig Piercey, Kyle Ward 28 A Milestone-Based Approach to a Rapid CMDB Definition- to-Deployment Initiative You 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. By Jason Odden 36 Advice for Achieving Quick Wins with Your CMDB Implementation Identify and achieve quick wins to realize greater success with your CMDB implementation. By V’Ali Ford 42 Using ITIL’s Configuration Management Activities for CMDB Success Use 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. By Javier Leyva Novoa 50 Six Tips for Effectively Managing the “People” Factor Successful 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. By Tim Mason tableofcontents Focus on: CMDB LeadershipFocus on: CMDB Leadership
- 4. 56 FiveDesignConsiderations fora CMDB Get 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. By Dennis Drogseth 64 AccelerateyourCMDB Implementation with a Best Practice Process Model Using 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. By Frederieke Winkler Prins 71 People:TheKeytoCracking the IT Service Model Code People provide insight to business processes and create a link to the IT infrastructure, helping you develop an accurate service model. By Alexandre Avelar 74 StartwithServiceDefinitions and Reap Success Begin your CMDB initiative by defining the services that IT provides to the business, and increase your chances of success.This article shows you how. By Brady Orand 80 DemystifyingConfiguration Items The 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. By Charles Betz 88 MissionPossible: Gathering the Right Data in Your CMDB to Optimize IT Services Adopting 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. By Val Sanford 96 Services,Software,andHardware CIs: Just like an Oreo Cookie! 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. By Jonathan Markworth tableofcontents
- 5. tableofcontents Section 2 Capabilities enabled byA CMDB 102 Change Management: The Key to a Picture Perfect Infrastructure When a CMDB is the centerpiece of your change management process, you can more efficiently and accurately change your IT infrastructure to meet business needs. By Hans-Heinz Wisotzky 108 Rememberthe“CM”inCMDB The 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. By Perry Sellars 116 Facilitating Effective ITAsset Management with the CMDB: A Nine-Step Approach Designing 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. By Julie Manis 124 CMDBBusinessValue Unfortunately, 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. By Kia Behnia 128 Leveraging Identity Information Through the CMDB By leveraging identity management, you can achieve a comprehensive, accurate, and up-to-date source of people information for the CMDB. By Ahmad Abdel-Wahed, Bob Worner 134 CMDB: TheKeytoJump-Starting ITIL Success Three experts discuss theVisible 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. By Kevin Behr, Gene Kim, George Spafford 142 CMDB:TheResort Condominium for IT Just 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. By Troy DuMoulin 150 Don’tForgetthe Network Follow a three-step approach for populating the CMDB with network data and using purpose-built network configuration management tools for a successful CMDB initiative. By Jeff Gibson 156 CanPeopleBeConfiguration Items? 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. By Troy McAlpin
- 6. 160 UsingBPEL,BSM,andthe CMDB toManage IT from the Business Perspective When CMDB information links a BPEL- designed business process toWeb Services and underlying IT services, you can drama- tically improve the alignment of IT with the goals of the business. By Devesh Sharma postscript 164 Dr. Henry CMDB implementations keeping you up at night? Just ask Dr. Henry… By Linda Donovan tableofcontents
- 7. Welcome to thesecond edition ofVIEWPOINT.Ourfirstedition focused on the value of a configurat- tion management database (CMDB) and provided expert advice on how to achieve a successful CMDB implem- mentation.We received a very posit- 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 rangeofarticlesfromBMCcustomers, 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 yourtransitiontoastrategic,business- focused IT organization. SelmaTurki of IBM identifies the quest- tions to ask before you start a large enterprise CMDB implementation and provides a checklist that you can use as a guide.AlexandreAvelar 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 guidel- 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 ofAccenture discusses a nine-step approach for using the CMDB to facilitate effective IT asset management. Perry Sellars of Strat- 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 busin- 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 handf- 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 usef- 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 cont- tributions from many of you now reading this. You may also be interested to know the CMDB has become such an imp- portantresourcethatBMCandseveral other leading companies have joined together to create a new interopera- abilityspecificationdesignedtoenable customers to federate and access informationfromtheircomplex,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 Bishop ChiefTechnology Officer, BMC Software ABOUT TOM BISHOP Tom 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 leadi- ing organizations including UNIX International, Tandem Computers, and CompuCare Management Syst- 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 IBMTivoli’s Embedded Solutions business unit. A Message from tom bishop Chief Technology Officer, bmc software
- 8.
- 9. “The power ofa 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.” — David Chiu, BMO Financial Group “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.” — Selma Turki, IBM “The CMDB is enabling us to deliver improved service and availability to the business that depends on us.” — Joe Lord, Craig Piercey, and Kyle Ward, Aliant “The key is to prioritize and start with those processes that have the greatest expected improvement from integration with the CMDB.” — Jason Odden, Wipro “Achieving a quick win can help you establish greater efficiencies and increase your pace toward reaching your ultimate CMDB goal.” — V’Ali Ford, EMS “Providing accurate and consistent information about CIs and their relevance to the business ultimately will enable the business to meet its goals.” — Javier Leyva Novoa, Quitze Tecnologia “To a large degree, successful implemen- tation and long-term viability depend on how effectively you manage the human aspects of the CMDB.” — Tim Mason, TRM Associates “Your CMDB can significantly empower your organization — once it is a consistent, dynamic and trusted data source.” — Dennis Drogseth, Enterprise Management Associates “A best practice process model is a time- saving and money-saving shortcut to successful service management.” — Frederieke C.M. Winkler Prins, Service Management Partners “The people in your enterprise are the key to creating business relevance and cracking the service model code.” — Alexandre Avelar, CSC BRASIL “Start with a critical business service and then build out the service model or the dependencies within the CMDB that go behind that service.” — Brady Orand, Column Technologies “CIs have differing levels of involvement in day-to-day service management and production processes.” — Charles Betz “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.” — Val Sanford, Singlestep “A CMDB implementation is successful when all interested parties consider your CMDB the single source of truth for the IT infrastructure.” — Jonathan Markworth, CompuCom Section 1 PRACTICAL Advice for DEPLOYING A CMDB 64 16 71 22 28 36 42 50 74 80 88 96 8 56
- 10. a CMDB ACMDB-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. By David Chiu InsightGained through Implementing The I.T. Service Structure:
- 11. 10 T he power ofa configuration managem- 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 consolid- 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 inform- 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, applic- 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 serv- 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. ServiceManagementevolution Let’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 transa- action flows across the IT infrastructure, and complicated to figure out how different techn- nology components depend on each other. If you’ve ever been involved in a data center consolidation, you know how hard it is to pred- 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 relat- 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.
- 12. 11 This IT servicestructure 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 busin- 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, perform- 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 Structure You’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 CIs Defining 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 techn- nology assets as CIs in a CMDB.To have a comp- 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.
- 13. 12 An important aspectof 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 acquis- 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 devices Software Database 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/UsedBy Used By Uses Uses/UsedBy Connected to Runs on (Installed on) Runs (Contains) Runs (Contains) Member of / Consists of Member of / Consists of Governs Governs Governs Governed by Connectedto DataExchange Creates Datafeed Receives Datafeed Backsup/Backedupby Connectedto Uses/UsedBy Runson/Runs 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 LogicalCIs SubsystemsSystemsServices Physical/VirtualCIs
- 14. 13 Network and networkdevices Documentation Facilities 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 servers The logical relationships, such as which virtual servers are hosted on which physic- cal servers The 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 complexity of functional relationships to be defined and managed.The situation is similar to the comp- 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 det- 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 int- 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.
- 15. 14 Categorization enables youto deal with the volume and complexity of relationships and present data in a straightforward, understanda- 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 exa- 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 Payoff With the IT service structure defined and maint- 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 unders- 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 compon- 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 managem- ment often becomes complicated when multiple incidents simultaneously are subm- 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 probl- 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.
- 16. 5tips for implementing acmdb Capacity management — Capacity managem- ment is typically done at the infrastructure component level.With a service structure in place, you can conduct capacity mana- 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 cons- 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 serv- 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 busin- ness of the enterprise. Bottom line: IT no longer just supports business operations; it becomes a key player in advancing business goals. n DavidChiuisaseniorbusinesstech nology specialist at BMO Financial Group. David was one of the proc cess architects for many of the ITIL processes implemented in BMO duringthelastfiveyears,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 statisticalprocesscontroltechniquesandotherquality improvementmethodology.Davidwon“BestITILCase Study”awardsatthe7thand8thAnnualInternational ITServiceManagementConferences.Heisalsoacon tributingauthorforHDI’sbook,ImplementingService andSupportManagementProcesses:APracticalGuide. ABOUT THE AUTHOR Establish technology CIs in the CMDB, including physical assets (servers, PCs, network equipment), logical assets (software, documentation, contracts) and attribute information (configuration, cost, and location of hardware CIs). Group CIs by their hierarchical relations- 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 repres- 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.
- 17. 16 Ask the right questionsbefore you start your CMDB, and your implementation will be smoother. Use this checklist as a guide. By Selma Turki CMDB Success withaPlanning Checklist Ensure
- 18. 17 I f you arethinking about implementing a configuration management database (CMDB), you are probably wondering, “How do I get started in a way that will ens- sure success?”The answer is, “By asking the right questions up front.” In particular, for large, geographically dispersed organizat- 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 implem- 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 inform- 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 Scope Implementing 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 overa- 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 maint- tained manually? How should we approach, review, and analyze the many disparate data sources that are collecting configuration item (CI) data throughout the enterprise?
- 19. 18 What isthe 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 comp- 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 busin- 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 telec- 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 sign- nificant impact on getting others to buy in. correlatingPeople,Processes, TECHNOLOGY, AND Information People, processes, technology, and informat- tion all come into play in the CMDB. For that reason, I find that adopting a model and approach correlated to all four — and reflecti- 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 app- 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?
- 20. 19 Have youthought 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 outsourci- 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 certif- 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 rep- porting requirements. Limiting the Number of Data Sources When 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 buildi- 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 exa- 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 eff- 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 unn- necessary data, consolidated where they could, and ultimately ended up with six data sources that were relevant to the CMDB.
- 21. 20 Strong leadership and ITILExpertise 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 iss- 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 ext- 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-inandCommitment Communication 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. Switchi- ing from their familiar spreadsheets, databases, and paper-based systems is unsettling at best. Effective communication explains how elimin- 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 busin- 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 mana- agement processes: Strong executive sponsorship and communication from executives displaying support
- 22. 5tips for success E-mailcampaigns 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 worki- 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 SUCCESS Building 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 recommend- dations presented here as a starting point, but feel free to add your own. n Selma Turki has ten years of experience working in computer technology. She has been with IBM for seven years, starting at IBMCanadaLtd.asanITspecialist. In 2000, Selma transferred to IBM Belgium as an IT architect. Selma concentrates on assisting clients in the consulting, planning, design, andimplementationofservicemanagementandasset management solutions, based on the ITIL framework and the Worldwide IBM IRMa best practices. ABOUT THE AUTHOR Carefully scope out the project and come up with a well-defined plan. Consider people, process, information, and technology when building your approach. Weed out unnecessary 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.
- 23.
- 24. 23 M anaging a configurationmanagem- ment database (CMDB) implement- 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 stakeh- 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 der- 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 1 Identify the Requirements The requirements phase involved defining the project scope; that is, detailing and documenti- 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 By Joe Lord, Craig Piercey, and Kyle Ward You 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. SuccessfulCMDB Implementation Practical Steps4 toa
- 25. 24 also wanted toavoid 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 proc- cess, so that moving forward, any changes to the infrastructure would be captured in the CMDB.We were adamant about this app- 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 cert- 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 stakeh- holders understood the importance of conc- 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 mana- 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 mana- 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 Design In 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 stand- dard operating procedure document. We also defined and built compliance reports to ensure that the outlined processes for conf- figuration management would be followed.
- 26. 25 These compliance reportsalso 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 processes Ensure that the processes would be followed on a continual basis Verify that any required post-implementation reports would be built and ready Our biggest challenge at this phase was ens- 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 requirem- ments document in cases where we determined the business need was critical. Step 3 Build In the build phase, we gathered data to popu- 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 everyo- 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 straightf- forward. In this phase, we first finalized a standard operating procedure for configuration mana- agement for the mainframe from a service delivery perspective.We wrote this document with input from all the groups, taking informat- 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
- 27. 26 wasn’t the timeto 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 custome- 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 Takeaways Don’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 implem- 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 des- 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 commun- nicate with everyone involved in, or affected by, the implementation. Ensure that they und- 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.
- 28. 5tips for a smooth implementation 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 beginn- ning the design. Communicate the scope and benefits with everyone involved in, or affected by, the implementation. Joe Lord is the team lead for the Configuration Management team and the Configuration Managem ment process owner within Aliant. Hisresponsibilitiesinvolveproviding guidance to, and overseeing his team’s involvement in, several ITIL processinitiatives.Joehasworked in IT for six years and is currently certified as an ITIL Practitioner. ABOUT THE AUTHORS Craig Piercey is 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 expertiseiswithsystems-managed storageandvirtualization.Histeam supports the ICT environment and delivers ICT solutions. Craig has been a key contribut tor to ISO certifications and ITIL implementations. Kyle Ward is 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.
- 29. 28 M ost IT departmentshave 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 progr- 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. A Milestone-Based Rapid CMDB Approach to a Definition-to-Deployment Initiative
- 30. 29 They load theCMDB 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- proach 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. You really can implement a CMDB initiative that achieves both thoroughness and quick results. This eight-phase approach, each with an accompanying milestone, describes how. By Jason Odden
- 31. 30 This approach providesa complete definition- to-deployment plan for a rapid CMDB implem- mentation at a reasonable cost.The output of each phase is a milestone that represents a significant achievement and value, empoweri- 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 previo- ous milestones.That allows you to take a holistic, flexible approach toward your CMDB initiative. Phase 1 Identify CMDB Providers, Consumers, and Processes To 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 framew- 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 managem- 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 proc- cesses should align with each other. Another useful activity is to prioritize processes and scope areas, keeping them reasonable, cons- servative, and repeatable. Project phases should be sensible and align with external depend- 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 cont- 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 nece- 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.
- 32. 31 Phase 2 Quantify theNumber of CIs and Their Relationships (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 adm- ministration, you might want to go back to phase 1 and refine the scope. Again, if you have multiple releases of the CMDB identif- fied, these releases can be realigned to bala- 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 3 Define a High-Level Data Model The 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 comp- 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?
- 33. 32 Milestone for phase3 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 sol- lution. Make sure the benefit of having the data justifies the cost of customization.You might want to change the phasing of the integ- 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 struct- 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 actua- ally required — a much smaller set of data than everything all providers have to offer. This required set of attributes can then be compared to the technology in a simple gap analysis exercise. Phase 4 Define the Relational Class Model The 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.
- 34. 33 Phase 5 Model theData Reconciliation The 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 reconc- 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 reconc- ciliation rules that are unrealistic to create and maintain. Implementation phasing and stages should also be in line with provider data availa- 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 6 Extend CMDB Attributes and Structure In this phase you will perform the CMDB attrib- 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 prov- 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 implem- 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.
- 35. 34 Phase 7 Migrate andConvert Data This 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 cons- 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 integrat- tions are created. Checkpoint.Training, testing, and user accept- tance will reveal whether you have successf- 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 8 Deploy the CMDB The 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.
- 36. 5tips for defining anddeploying a cmdb Milestone for phase 8 CMDB is successfully in production. Checkpoint. Production system is live and int- 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 unt- tapped and the organization gets shortchanged. Successful Definition to Deployment This 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 Jason Odden is a principal solutions architect at Wipro. He is a certified RemedyApprovedConsultant(RAC) and has more than nine years of Remedy® experienceanddozens of successful implementations in a wide array of environments. In addition 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. ABOUT THE AUTHOR Know what delivers value to your custome- 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.
- 37. 36 D o you embracethe idea and promise of the configuration management datab- 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 inform- 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 Method Populating 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.
- 38. 37 Identify and achievequick wins to realize greater success with your CMDB implementation. Here’s how. Advice for Achieving Quick Wins with Your CMDB Implementation By v’ali ford
- 39. 38 Your most maturemethod 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. Services In addition to identifying your most mature data collection method, create a service catal- 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 prov- vide outstanding customer service through a customer support application that is always available. It might also be access to the Intern- 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 proc- 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 Item 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. 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 gathe- 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 netw- 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.
- 40. 39 Reconcile Multiple DataSets If you have created a topology tree for each service, you need to pull in other data sources so you can create a more accurate represent- 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 authori- 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 incid- dents and problems and changes through the discovered items in the CMDB. It’s at this point that organizations really start to see improvem- ment in IT infrastructure management. Success Story: Convert Data and Establish Discovery Feed We have worked with several organizations that achieved quick wins upon which they can continue to build. One client, a large pharmac- 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 environm- 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 lega- 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 dict-
- 41. 40 tated when aservice 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 determ- 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 reposit- 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 reposi- 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 rep- pository, so there was no way to capture the data that related assets to an incident, or ass- 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 Efficiency Achieving a quick win can help you establish greater efficiencies and increase your pace toward reaching your ultimate CMDB goal. For example, time management and product- 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.
- 42. 5tips for A QUICKWIN APPROACH TO A CMDB INITIATIVE V’Ali Ford is a Remedy application architect and developer with EMS. He is a Remedy Approved Consult tant (RAC) and has seven years of experience developing solutions in the BMC® Remedy® IT Service Management Suite and BMC® Remedy® Customer Service and Supportapplications. V’Alihasapp liedprovenmethodologiestoanalyze,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. ABOUT THE AUTHOR 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 authorit- tative data set, and establish your data reconciliation rules. Leverage the quick win for further improvements to your IT infrastructure processes.
- 43. 42 Configuration Management Activities Using ITIL’s for CMDBSuccess Use 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. This article explains how. By Javier Leyva Novoa
- 44. 43 T he configuration managementdatabase (CMDB) is essential for effective conf- 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 configu- uration management recommendations by providing specific guidance for effectively evolvi- ing through the six activities, which will set the stage for a successful CMDB implementation.
- 45. 44 Activity 1 Planning ITIL’sBest Practices for Service Support book states that this first activity includes“planning and def- fining the purpose, scope, objectives, policies and procedures, and the organizational and techn- nical context, for Configuration Management.”1 Activities in planning a configuration management process include: Assigning a person to be responsible for the process and systems Analyzing existing configuration managem- ment systems, data, and processes Gaining agreement on the purpose, objectives, scope, priorities, and implementation approach for the configuration management process Planning for and obtaining funding for configuration management tools Attaining 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 configurat- 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 conf- 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 unnecess- sary. Finally, you will not address and resolve external influences that inhibit or change the scope of the initiative. Activity 2 Identification Once 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 infras- structure’s CIs, including their ‘owner,’ their interrelationships and configuration docum- 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.
- 46. 45 Know which typesof 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 rel- lated CIs to put in the CMDB, how they rel- 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 cate- 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 inform- 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 3 Control ITIL 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, rep- placed or removed without appropriate cont- 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 inform- mation security schema, you cannot be assured that you are providing truthful and timely inf- 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.
- 47. 46 Tips for effectivecontrol 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 agreem- ments, etc. Be sure to consider the business rules and policies around the CMDB, so the inf- formation will be consistent. Examples of business rules or policies include: The change management process is the only process that allows modificat- 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 4 Status Accounting According 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 Write PC Support-Hardware Incident Management X Problem Management X Change Management X Release Management X Support-Software Incident Management X Problem Management Microsoft Windows Server Support-Hardware Incident Management X Problem Management X Change Management X Release Management X Support-Applications Incident Management X Problem Management X Change Management X Release Management X Support-Networking Incident Management X Problem Management X Change Management X Release Management X 4. Ibid
- 48. 47 To perform thistask, you will need to maint- tain the status of CIs within the CMDB, as well as other related information, including: Lifecycle state of each registered CI Incident, problem, change, and release history of each CI Service level agreement with the busin- 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 configu- uration management solution that supports CIs of varying complexity, such as entire systems, releases, single hardware items, software modules, or hierarchical and networked relat- 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 accounti- ing report, they can run the report manually. Using the statistical results from this accounti- ing, you can find: Behavior patterns Baseline 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 configur- 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 accounti- 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 Verification and Audit ITIL describes this activity as “a series of rev- views and audits that verify the physical exi- 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 RFC CI 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
- 49. 48 Revisions to softwarethat may not be regist- 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 underp- pinning contracts The relationship of a CI with its environment is being researched The 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 bef- 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 discove- 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 act- 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 6 Backing Up and Archiving the CMDB Based on our experience with CMDB projects, we add a sixth activity to the five configurat- 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.
- 50. of using itil’s configuration management activities 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 configur- ration manager. Test the backups from time to time to ensure accuracy.Again, this task often is the respons- 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 ina- accurate information. In addition, the CMDB may have security vulnerabilities. A CMDB to Support Business Needs Deploying a CMDB is more than storing inform- 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 busin- ness to meet its goals. n Javier Leyva Novoa is a new technologies manager at Quitze Tecnología. Javier is a Remedy ApprovedConsultant(RAC)and ITILcertified,andhasadvisednumer- ouscustomers about ITIL, COBIT, and BMC Software products. He hasbeenatrustedleaderincomplex projectssupportingITILprocesses. ABOUT THE AUTHOR 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 implem- 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.
- 51. 50 Successful implementation andlong-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. By Tim Mason for effectively managing “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 challenges 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.
- 52.
- 53. 52 CMDB: the PeopleAngle If you’re like most IT professionals, you’re pretty 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 informat- 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 transformation, 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 resorted 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 throughout your CMDB project: To a large degree, successful implementation and long- term viability depend on how effectively you manage the human aspects of the CMDB. Below, I’ll provide some guidelines on how to do just that. Tip 1 Hook into Existing Processes Your 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 workf- flow in the CMDB. The real challenges are spotting the relevant processes and getting people to follow the new step.
- 54. 53 Tip 2 Communicate Widelyand Take A Top-Down Approach Communication 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 supp- 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 people 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 3 Make it easy to use, give something back Making 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 navig- 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 4 Establish Data Ownership and Clear Measures Clear 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.” Conf- figuration managers, however, cannot own the data because they have no way of knowing if the data is accurate.They can own the proc- 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 implem- 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 information. Data managers are accountable to a data owner for data quality.
- 55. 54 We incorporated dataquality 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 5 Automate Data Checking ITIL 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 identifies 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 6 Use Autodiscovery Appropriately Discovery tools play a vital role in managi- 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 reb- boot theVMWare 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 SUCCESS As 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.
- 56. OF MANAGING THE PEOPLE FACTOR 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 Tim Mason is a founding director at TRM Associates, an information management consultancy firm. Tim brings deep experience and insight from an extensive background in managementconsultingataleading U.K. consulting firm. While working in the industry, he has held intern national IT assignments spanning Europe, Australia, Asia, and the United States. ABOUT THE AUTHOR 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 proc- 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.
- 57. 56 Get a headstart 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. Here are the questions to consider. By Dennis Drogseth Considerations for a CMDB 5design
- 58. 57 Y our configuration managementdatab- base (CMDB) can significantly empower your organization — once it is a cons- sistent, dynamic, and trusted data source that supports such objectives as change and conf- figuration management, inventory and asset management, and service assurance. The CMDB can enhance the alignment of busin- 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 Infras- structure Library (ITIL® ) process initiatives,
- 59. 58 but also foradoption 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 busin- ness objectives A CMDB, as defined by ITIL, is process-centric, and as such, it can only imply these architect- 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 busin- 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 Objectives As you begin your CMDB initiative, ask yourself the following questions: What are the short-term and long-term goals — including operational and busin- 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 asWAN 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
- 60. 59 changes that aservice 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. 1 Configuration Items Configuration 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 GranularityofInformation 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.
- 61. 60 and configuration detailin the core database, where time sensitivity is low and atomicity is high. On the other hand, granular and ext- 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 deg- graded or unavailable. By prioritizing your first-phase objective in terms of change management, service level management, inventory and asset managem- ment, or some other area, it then becomes possible to set initial objectives for CI requirem- ments which will, in turn, impact CMDB design. Design Consideration No. 2 Federated Systems Even 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 produ- 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.
- 62. 61 – Level ofcomplexity versus the near-term and long-term resources available for administration and support? – Database design, performance, and scala- ability? In some cases, vendors replicate data; in others, data is accessed dynamic- cally and reconciled through policies. How does the notion of federation map to: – Current processes? – Currentorplannedorganizationaldynamics? – Current or planned supplier relationships? Design Consideration No. 3 Data Schema When 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 accomp- 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.
- 63. 62 Design Consideration No.4 Autodiscovery Much 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 depend- dencies (service contracts and objectives) Relevant modeling of operational depend- dencies (who does what and when) Relevant insights into consumer consumpt- 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 inform- mation gathered through autodiscovery may more appropriately reside in federated data stores accessed by the CMDB. Design Consideration No. 5 Data Integration and Reconciliation A 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 eff- fective federated CMDB system. Your system will require some level of data normalization, so that management applicat- 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 applic- 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 unificat- tion of disparate data reported for the same CI. Data reconciliation must ensure that a CI is correctly identified, even if various managem- ment tools have named the same CI differently. Time dependencies and disparities of the data must be reconciled. And, finally, data reconc- 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 integrat- 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.
- 64. 5tips for cmdb design Datareconciliation must address the unification of disparate data reported for the same CI. Effective Design: CMDB as Enabler By carefully considering your needs for conf- 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 Dennis Drogseth, vice president, EnterpriseManagementAssociates, directsateamofanalyststhatfocus on the development of networked services management. He has pion neered research in management strategies such as performance andavailability,integratedsecurity, changing organizational dynamics inIT,andenterpriseandserviceprovidermanagement issues. He has a Bachelor of Arts degree, magna cum laude, from Yale University. ABOUT THE AUTHOR 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.
- 65. 64 By Frederieke C.M.Winkler Prins G etting 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 managem- 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. Using 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. your CMDB Implementation with Accelerate A Best Practice Process Model
- 66.
- 67. 66 The STandardized PROCESSes challenge Awell-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. Moreo- 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 respons- 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 stand- dard approach. Figure 1.The Generic Process Model Source: ITIL Service Support Appendix B: Process theory and practice, page 273 Process Process Control Process Enablers Activities and Sub-Processes Quality Parameters and Key Performance Indicators Process Owner Process Goal Resources Roles Input and Input Specifications Output and Output Specifications
- 68. 67 HOW a BestPractice Process Model HELPS A best practice process model combines field- proven processes with practical, detailed, and specific instructions on how enterprises supp- port and deliver their services. Starting with such a model doesn’t mean you eliminate the process definition phase of your service mana- 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 upd- 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 exa- 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 spec- 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 conf- 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 Change Management To Change Management No NoYes Update of supplier information required? Requisition of new Cls requested? Cl Requisition Registration of new Cls requested? 1 Cl Registration 3Supplier Information Maintenance2 Cl Update 4 Contract Administration5 Figure 2. Example Process Diagram — Configuration Item Update
- 69. 68 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 supp- 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 managem- ment process and CMDB more quickly. The IMportance of Tool Integration Once the process definition is complete, you need to implement software that both autom- 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 establ- 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 customizat- 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 activi- 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. Process and Tool CMDB Data Usage 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 andTools Most Dependent on CMDB Data
- 70. 69 Additional Keys toSuccess Once 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 maint- 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 MicrosoftWindows 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 implem- mentation activities that they forget about measuring performance. However, a best practice process model should include def- fined performance measures for overall process quality. Processes that utilize CMDB data should include the definition of key perf- 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 upd 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
- 71. 70 Accommodating the needsof 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 implem- 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 organizat- tional acceptance and makes the transition to new or changed ways of working easier. Results That Speak for Themselves A 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 defin- nition effort by using a standard model. Using a best practice model accelerates the process definition phase, which not only ena- 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 imp- proving your service to the business you support — and supporting the business is what it’s all about. n Frederieke C.M. Winkler Prins is a certified ITIL Master with more than 15 years of experience in the deliveryofITservicemanagement 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. ABOUT THE AUTHOR Training that covers process awareness, as well as how to use supporting tools, fosters broader organizational acceptance. 5tips for CMDB success 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.
- 72. People: People provide insightto business processes and create a link to the IT infrastructure, helping you develop an accurate service model. The Key to Cracking the IT Service Model Code By ALEXANDRE AVELAR 71
- 73. 72 M apping IT servicemodels for your configuration management datab- base (CMDB) may seem like a diff- ficult code to crack at first. Automated tools can facilitate collection of some of the inform- mation you need about the IT infrastructure, so you can build service models. Nonethel- 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 somet- 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 infrastruct- 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 addit- tion, you’ll need to ensure that your methodo- 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 information If 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 busin- 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 SErvice CSC 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.
- 74. 5tips for mapping service models 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 prep- 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 acc- 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 completion 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 Key Although automated tools are critical to mapp- ping infrastructure relationships that are stored in a CMDB, always keep in mind that people play a vital role in that mapping process. Disc- covery tools can collect information regarding components, such as infrastructure devices, configurations, and applications, but do not generally identify the relationships and relev- 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 quest- 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 Alexandre Avelar, a consultant withCSCBRASIL,hasabachelor’s degree in mathematics from Rio de Janeiro State University and a bachelor’s degree in software development from Estácio de Sá University.Hehas19years’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. ABOUT THE AUTHOR Focus on a single process or subprocess. Identify experts in a variety of roles across the enterprise who understand the process and the infras- 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.
- 75.
- 76. Y ou’ve decided toimplement IT service management (ITSM) and a configurat- 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 Success A 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 and Reap Success By Brady Orand Begin your CMDB initiative by defining your services, and increase your success. This article shows you how. 75
- 77. 76 IT service managementis 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 spec- 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 clarif- 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 imp- 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 administ- 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 datab- base supports. When adopting various ITIL processes, organiz- 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. Unders- 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 transf- form the level of thinking about IT throughout IT and the business. It also improves the rel- lationship between IT and the business that IT serves. All too often, organizations that get excited about ITIL start a variety of initiatives to implem- ment various processes in their environment. One organization I worked with was in the midst of implementing change management, incident management, and problem managem- ment in parallel. However, these three parallel endeavors were being undertaken in three separate groups — without any communicat- 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 org- ganization decided to develop a service catalog. During the discussions of services offered, IT leaders realized that they needed to re-evaluate
- 78. 77 some of theirearlier 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 Definitions When I help companies to create service de finitions, first I gather all the IT stakeholders together and ask them what services they prov- 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 discuss- 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 diff- 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 comp- 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 proc- 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 manuf- 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.
- 79. 78 Finally, we askthe 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 — ident- tifying the services IT is offering and the cust- tomers it is serving — it becomes obvious to the people involved what the next steps are. Elements of a Service Definition A simple service definition might include the following: Name Description Customer User 5 Business Services In 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 resources, payroll, and finance, that keep a company running and executives out of jail Service Customers Service Users Business 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
- 80. 5tips for starting withservices 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 CMDB Figure 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 communic- cate through it. At the bottom is the CMDB that supports all of those processes. When developing a CMDB, you can be particul- 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 inc- 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 hardw- ware or software, then you can use the physical configuration item (CI), which is located in the CMDB, to determine exactly where that incid- 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 BradyOrandisanITservicemanagem ment practice manager at Column Technologies Inc. Brady has more than15years’experienceinvarious 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. ABOUT THE AUTHOR 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.
- 81. Demystifying Configuration The configurationitem (CI) is one of the most necessary, yet problematic, concepts in IT governance. It is highly abstract: Any managed “thing” in the IT environment — from an individual computer chip to an entire mainframe — can be a CI. This article helps sort through ITIL’s vague data architecture and helps present a simplified way of categorizing CIs that is useful in designing, populating, and managing an effective CMDB. By Charles Betz Items 80
- 83. 82 A number of processframeworks are currently available to assist you in effectively managing your IT infras- structure: Control Objectives for Information and relatedTechnology (COBIT), Capability Maturity Model (CMM), and the IT Infrastruct- 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 Shortcomings The 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 hardw- 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 applyi- 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 produ- 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 inform- 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 interprete- 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
- 84. 83 “connected to” adata model — connections that obviously do not make logical sense. The high level of generality makes the CI concept difficult to manage from the pers- spectives of process, data, and application. More rigor is necessary. This analysis refines the ITIL representation and makes it more specific by applying data modeling (metamodeling) principles. A Finer Point on CIs I 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 progr- 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 Generi- ic “Human Resource ManagementApplication” as a reference category would not be a CI. Figure 1. Detailed Configuration Item Taxonomy Conceptual Model Inheritance
- 85. 84 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 Operat- 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 subt- 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 asp- 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 ManagementTask Force (DMTF), andTele- Management Forum (TMF).This article represents a much simpler framework as compared to these highly complex standards. Types of Configuration Items The base CI is the master category to which all CIs belong. It is any “thing” in the IT environm- 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 docum- 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 Prod- duction) may or may not be formalized. For example, the service management group may Conceptual Model CI Figure 3. CI Subtypes and Key Relationships
- 86. 85 Figure 4. MajorCITypes, Supporting ITSM Entities, andTheir Allowable Relationships define service offerings, or the asset managem- 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 Asset Technology Product Business Process 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
- 87. 86 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 referr- ring to “the change process.” Logical and Physical CIs CIs can be logical or physical.Top down versus bottom up is another way to think of this dist- tinction: logical are top down, physical are bottom up. Physical, in this case, means there is no ambig- 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 (espec- cially those built in-house), processes, and services (in the service catalog sense) are the best examples of logical CIs. Machines, comp- ponents, files, and network-addressableWeb 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 Model There 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 Management System may cause the initation of Conceptual Model Partitioning Ordered Service Service Offering Service Request Change (RFC) Problem Incident
- 88. 5tips for categorizing configuration items management, someservice 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 autom- matically moved from the Service Request management system to the Service Managem- ment system (automated interfaces can be difficult to build). Each Service Request is assigned an unamb- 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 interope- erate is one of the most pervasive architectural failures in modern IT systems, and we shouldn’t add to the problem. Just remember that interf- faces are expensive to build and run, so don’t underestimate the cost of integrating several best-in-class systems. Bridging the Process Framew work and Technical Systems Processes consume and produce data, which is not some mere technicality that can be def- 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 framew- work and the technical systems supporting it. n Charles Betz is a senior enterprise architect for a Fortune 50 corporat tion. Previously, he was the head of Enterprise Repository Services forthespecialtyelectronicsretailer BestBuy,andhasalsoworkedasan 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©2006MorganKaufmann.Allrightsreserved. ABOUT THE AUTHOR Keep CIs specific. Avoid over-applying subtypes. However, subtypes are import- 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.
- 89. 88 Mission: By Val Sanford Adoptinga 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. Possible
- 90. 89 D eploying a configurationmanagement database (CMDB) can be a complex process that involves integrating inf- formation, processes, and people into a single cohesive system. Successful CMDB implement- 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. Gathering the Right Data in Your CMDB to Optimize IT Services
- 91. 90 Your Mission, ShouldYou Choose to Accept It Industry 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 decis- 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 identification Data collection Data utilization and optimization Proper planning is crucial in mitigating the ine- 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 implem- 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 implem- mentation by selecting, as a starting point, one service that IT provides to the business. After the successful rollout of a limited CMDB implem- 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 busin- 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 Identification 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.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 configur- 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 quer- 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 Process Potential data sources span your entire organiz- 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 busin- 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,” NetworkWorld’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.
- 92. services?Which of theseelements 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 ext- tended CMDB data? What are the relationships between our CIs? How do we represent those relations- 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 syst- tems? (For example, if one system reports the status of a port, will another system rep- port on the health of the server connected to that port?)Which applications will subs- scribe to the data available in the CMDB? Data Collection Once 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 programm- ming interfaces (APIs) to usingWeb 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 Case Study: The Customer Support Web site 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 supportWeb site provides relt liable access to knowledge base articles, downloadat able patches, documentation, and other resources. Business X has assigned a cross-functional 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 e-mail 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 User-experience metrics Finally, the team must use this identification process for each type of data needed in the CMDB. By succt cessfully identifying data their organization needs to capture, the Business X cross-functional team is taking the first step in ensuring a successful rollout of a limited CMDB implementation. • • • • • 91
- 93. 92 collection stage. Pertinentquestions involve choosing tools, addressing data compatibility issues, and choosing a data collection solution. Choosing Tools With 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, reduci- ing costs, and ensuring the day-to-day stability of the disparate systems in your heterogen- neous environment. Questions to ask about tools in the data collect- 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 accomm- modate data loss? Addressing Data Compatibility Issues In addition to resolving tool and data loss issues, you must also address data compatib- bility issues. Managing the translation or norm- 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. - StrategicThinking 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.
- 94. 93 What are therules for normalizing conf- 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 availa- able that may meet your needs. In either case, involve your vendors early in the process and set the expectation that they must work tog- 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 infras- 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 integrate Bidirectional, multidirectional, or unidirect- tional integration between tools Support for both real-time and batch collection Use of existing standards ISO or IT Infrastructure Library (ITIL® ) certification Rapid deployment, configuration, and optimization to ensure quick ROI Automated auditing to help meet compliance efforts Extendibility and low service costs Automated data scrubbing to reconcile data based on your Data Resolution Protocol Data Utilization and Optimization 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. 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, rev- view your objectives so you can measure your progress and identify areas for improvement. Second, determine whether you need to enh- hance, enrich, or add to your initial data set so you can optimize your business services. Reviewing Your Mission Objective Dynamic environments offer limitless opport- tunities for improvement. Comparing perform- 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 implementi- 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.
- 95. 94 not getting theresults 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 opening Automate prioritization of incidents based on business needs Improve root cause analysis Improve service availability Manage change by understanding priority and service impact Automate communication and approval process for change requests Predict outages and apply pre-emptive actions Support automated capacity planning and on-demand computing Improve service level management Autogenerate accurate and timely reports Link service level agreements to IT components Improve financial controls Apply service-based cost allocation of IT components Determine total cost of ownership on IT assets Identify cost savings more easily – – – – – – – – – – – – Reviewing the Initial Data Set to Optimize I.T. Services The initial data set may not provide all of the information you need to make all of the imp- portant business, operational, and technical decisions for your organization. Changes in your IT environment or business needs, whether planned or unplanned, can affect data requirem- 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 syst- 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 enhanci- ing the initial data set you incorporated into your CMDB: Consider incorporating an ongoing data assessment process.
- 96. 5tips for gathering data Foreach service you provide to the busin- ness and the elements associated with that service, identify the conditions in which additional data may be needed Identify the source of that additional data Identify the consumer of that data Re-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 Services At each stage of the CMDB implementation process, there are specific challenges your org- ganization must overcome. Stringent managem- 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. ValSanfordisvicepresidentofpro ducts for Singlestep Technologies, Inc.,aSeattle-basedsoftwarecomp panythatdevelopsdataintegration and automation solutions. Prior to Singlestep,Valservedasavicepre sidentatNetworkCommerce,Inc., and as a director at VersusLaw. SheholdsaBachelorofArtsdegree from Whitworth College. ABOUT THE AUTHOR Narrow your focus to the data that support the most critical serv- 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.
- 97.
- 98. T he data ina 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 lapt- tops, desktops, monitors, and printers make up the foundation of the IT infrastructure. In most cases, these components of the infrastruct- 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 independentl- 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: Just Like an Oreo® Cookie By Jonathan Markworth 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. 1. Oreo is a registered trademark of Kraft Foods. ! 97
- 99. 98 Software is installedon hardware and is most likely to be recognized as connected to the busin- 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 deskt- top. Operating systems, which are also softw- 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 busin- 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 Jar I 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 unders- 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 managem- 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 serv- 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 dec- 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 probl- 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
- 100. 5tips for filling theCMDB cookie car 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 softw- 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 managem- 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 imp- 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 Share A 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 ass- 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 inv- ventory can be used to seed the CMDB or even extend the CMDB through federation. Some IT asset management staff resources and exp- 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 managem- 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 forw- 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 busin- 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. JonathanMarkworthisamanaging consultant with CompuCom Systems, Inc. , headquartered in Dallas, Texas. Jonathan has successfully performed a variety offunctionsintheITindustryduring the last 20 years. He is certified in ITILandSixSigma,andisacertified Project Management Professional (PMP).AspartofCompuCom’sIntegratedInfrastructure Management practice, Jonathan and the CompuCom CenterofExcellenceteamareresponsiblefordeploying effectivesolutionsforchange,configuration,release, and asset management. ABOUT THE AUTHOR A CMDB implementation is successful when all interested and concerned parties consider your CMDB the single source of truth for the IT infrastructure.
- 101.
- 102. 101 Section 2 Capabilities enabled by A CMDB “To provide real value in managing a changing infrastructure, you must identify the interdepencies between components.” — Hans-Heinz Wisotzky, MATERNA GmbH Information Communications “The configuration management process and the CMDB together create the foundation where components, systems, and configurations are brought together and understood.” — Perry Sellars, Strategic Technologies “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.” — Julie Manis, 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.” — Kia Behnia, BMC Software “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.” — Ahmad Abdel-Wahed, Microsoft, and Bob Worner, BMC Software “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.” — Kevin Behr, Gene Kim, and George Spafford, IT Process Institute “Implementing an integrated service management tool supported by a CMDB is a critical success factor in supporting an effective IT service management initiative.” — Troy DuMoulin, Pink Elephant “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.” — Jeff Gibson, 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.” — Troy McAlpin, Invoq Systems “By having business processes defined in the CMDB, the IT organization will now have increased visibility into the business.” — Devesh Sharma, Oracle 142 108 150 124 116 128 134 156 160 102
- 103.
- 104. Management: Thekeytoa Infrastructure PicturePerfect Whena CMDB is the centerpiece of your change management process, you can more efficiently and accurately change your IT infrastructure to meet business needs. By Hans-Heinz Wisotzky Change 103
- 105. 104 Y our company’s ITinfrastructure is in a constant state of change: new techn- 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. Ano- other benefit is overall IT efficiency.While IT capital budgets are flat, businesses nonethel- less expect IT to support new strategic initiat- 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. LookBeyondAssetManagement One 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 app- 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 interdep- 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 inc- crease the success of implementing changes. Sharpen the Focus with Configuration Management and the CMDB Configuration management will help you extend asset management with information about the interdependencies between infras- 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.
- 106. 105 focused picture ofthe 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 mana- 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 managem- 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 configurat- 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) maint- 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 cons- sideration, and which business processes are affected. Compose a Clear Picture with Change Management Every 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 implem- 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 unsucc- cessful changes, and you simultaneously reduce the time from RFC submission to
- 107. 106 making a decisionand 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 proc- cesses, always take into account information from the CMDB.This will achieve two object- tives: The change process can be partly autom- 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 Picture A 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-Heinz Wisotzky is 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. ABOUT THE AUTHOR Use the CMDB to determine the feasibility of each proposed change before moving forward with the change.
- 108. 5tips for efficient change management using a cmdb 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 prop- 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 infras- structure flow back into the CMDB as updates to related CIs.
- 109. 108 The CMDB ismore 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. Remember By Perry Sellars “CM” in CMDB the
- 110. 109 C reating a configurationmanagement 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 inf- 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 analys- 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 inform- 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 serv- 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
- 111. 110 they support. Fromaccounting to order proc- 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 proc- cess can help you integrate IT with the service provided to the business. Configuration mana- agement also helps you to build and maintain an accurate and relevant CMDB. Why You Need Configuration Management with a CMDB When you set up your CMDB, make sure conf- 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 cont- 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 datab- base filled with unusable and inaccurate data. Identification. Break down and uniquely define the infrastructure components or configuration items. A minimum set of identification inform- mation includes owner, dependency relations- 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 Asset vs. Configuration Management It’s important to distinguish between configurt ration and asset management.Typically, IT Operations directs the CMDB and the configut uration management process, which is focused on proper function of the IT infrastructure. Procurement or Finance directs asset managemt 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 service-pack 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.
- 112. 111 Figure 1. ITService 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 managem- 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 vers- 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 comp 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.
- 113. 112 Configuration Management Establishes theFoundational Process for More Effective I.T. Service Support Service 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 continu- 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 increasinglyrecognizedasinsufficient. 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 requirem 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.
- 114. 113 Configuration Management Enables MoreEffective I.T. Service Delivery Functions Service delivery ensures consistent operation of the IT infrastructure upon which the busin- 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 conf- 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 Functions When 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 Document Business Process Internal External Archival GL AP AR Orders Procurement Service Determine Workflow Communication Customer Portal Identify Services Map to IT Infrastructure FSC 2 node Oracle RAC Storage Foundation for Oracle RAC Storage Foundation for Oracle RAC v210 Infra v210 Infrav210 Infra v440 app DBs v210 web and midVVR F12K-dmd app DBs F12K-dme app DBs v210 mid v210 web v210 web v210 mid 6 Node VCS Cluster 2 Node VCS Cluster 1 node Oracle RAC TCA E-mail SAP Oracle Apps Business Impact Service Definition Service Continuity Disaster Recovery Finance Storage Foundation HA Oracle 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.
- 115. 114 a bottom-up orcomponent-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 comp- panies. In fact, some organizations are almost completely shut down by e-mail outages, resulting in lost revenue and customer diss- 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 illust- 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 cust- 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 det- termine whether applying a package release will have a low impact and risk.Without effect- 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.
- 116. 5tips for ensuring cmis part of your cmdb 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 infras- structure that provides user connectivity for that service and noticed that it was missing from the service continuity plan. CMDB Sets Foundation for Knowledge The 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 strat- tegic initiatives that facilitate business services. n Perry Sellars, a consultant with Strategic Technologies, is a publ lished author, featured speaker, ITIL Certified Master, and an ISEB accreditedITILtutor.Hehas23years of experience in IT, system, and networkmanagement,andhascond ducted ITIL maturity assessments and implementation consulting for customers since 1996. Perry may be contacted at perry.sellars@stratech.com. ABOUT THE AUTHOR Establish the vision — why the organization is making a commitm- 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 proc- cess responsible for maintaining accurate data.
- 117. 116 Facilitating Effective I.T. AssetManagement with the CMDB: A Nine-Step Approach
- 118. 117 A well-designed configuration manage mentdatabase (CMDB) can provide business value in multiple ways. Many organizations deploy a CMDB not only to enable configuration, change, and release managem- 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 outl- lines the steps. Step 1 Define the Purpose of the CMDB Start by defining a purpose that relates to your business goals and how the CMDB will add value to the business.The functions the CMDB will serve, the benefits to be derived, and the metrics and measurements of success should be defined and prioritized in the first stage of planning the project. Many organizations initiate an ITAM program to control and manage the total cost of owner ship (TCO) for IT assets over their lifecycle.The aim of ITAM is to align technology investments with business objectives to derive optimal value. Additional value can be gained by broad 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 configur- ration data, the CMDB can be leveraged by multiple IT service processes and can be used to control theTCO for assets, delivering addit- 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, andTCO. 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 dep- pendent IT service management processes, Designing a CMDB that also functions as an asset management repository requires broader definitions of the configuration items included in a traditional CMDB. Follow these steps to successfully scope and manage the asset management aspects of a CMDB initiative. By julie manis 7 1 4 step step step 2 8 5 step step step 3 6 9 step step step Define the purpose of the CMDB Identify all stakeholders and create a CMDB reference group Define the role of the CMDB in IT service management Define the scope for configuration items and assets and the differences between them Define functional requirements Create a strategy for the CMDB Start small, think big for design and implementation Consider tool overlap and organizational gaps Remember critical plan functions Figure 1. Steps for a Successful CMDB
- 119. 118 such as linkingITAM and change processes and data, or ITAM and service desk processes and data, etc. A CMDB should depict relationships in more granularity than traditional asset repositories, because it must also provide incident, problem, change, and other IT Infrastructure Library (ITIL® ) processes with dependency information. An asset manager can use this data to better roll up individual asset metrics into business service- level metrics; for example, the total cost of assets associated with a service such as “Web order entry.” Step 2 Identify All Stakeholders and Create a CMDB Reference Group The CMDB is a tool that involves many more users and stakeholders than just the configur- 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 serv- 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 inf- formation you need, yet big enough that you cover all your stakeholders. Team members should include a mix of people junior enough to be involved in the day-to-day work of the organization, as well as process owners and managers who understand the business issues to be addressed by the CMDB implementation.The members should also be prepared to spend a significant amount of time forming the data definition of items in the data model, and should be the people who finally sign off on data loaded into the tool. Step 3 Define the Role of the CMDB in I.T.ServiceManagement When you gather requirements for your CMDB, think about what you want the tool to be able to do in the long term. But also keep in mind the high-priority, urgent needs and make sure that you include those in the early stages.The concept is to start small, but think big. In the near term, your goal may be to create a CMDB that can be used for change, release, and configuration management.You may also want to leverage asset data for the financial controls required for ITAM. In the long term, this combined data can facilitate incident and problem management as well as capacity and availability management. CIs may vary widely and may include hardware, software, and documentation. By prioritizing these needs, you may determine that the organization’s top priority and most pressing need is software license management. You would start by populating the CMDB with discovered asset inventory data and software license data to be reconciled for license comp- pliance. At the beginning the scope would be small, but you would design and plan the CMDB to have the flexibility and extensibility to meet your other requirements over time. The CMDB reference group needs to define how the CMDB will be leveraged by ITAM and all other IT service management processes and set priorities. Step 4 Define the Scope for Configuration Items and Assets and the Differences Between Them You’ll need to work with the business stakeh- holders to determine what data needs to be collected to identify, track, and control the conf- figuration lifecycle. CIs may vary widely and may include hardware, software, and docum-
- 120. 119 mentation.You also needto 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 definit- tion of either what goes in the CMDB or what information needs to be accessible via federa- ated data stores. In addition to configuration data, ITAM would also want to record asset data such as contract, location, and other inf- 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 cont- 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 assetTCO/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
- 121. 120 Both configuration managementand ITAM can leverage a single CMDB. For the implementa tion to be successful, however, the requirements for both need to be defined up front and the CMDB must be designed to accommodate the requirements of both functions. After you have identified the necessary CIs and asset attributes, you must determine the depth to which these items will be tracked. Make sure you include enough information to meet the established business requirements without storing unneeded or excess data in the CMDB. Decisions about the depth of CIs and assets should be made for each functional environment and should be based on the level of control required and the level of criticality for each component type. Step 5 Define Functional Requirements Once you have defined what you want to track, you need to establish a method for inventory discovery for both hardware and software across all operating systems. A methodology and tool must be chosen for mapping relation ships among the CIs and populating the CMDB. You will need to define what interfaces need to be built to collect contract data, user data, procurement data, and fixed asset data. For effective asset management, you need a me thod for reconciling physical inventory data with financial records; in other words, comp- 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 busin- ness processes into a single, virtual resource that can enable all aspects of service support as well as provide a foundation for service delivery. Step 6 Create a Strategy for the CMDB After you have defined all your requirements, they must be translated into a high-level strategy and scope. Key considerations include: What are the key business purposes and problems to be resolved? What activities and processes must be included? What are the functional requirements? What are the key achievements for measuring success? Figure 3. Closed-Loop and Operational Approaches ITIL Closed-Loop CMDB Approach Operational CMDB Approach Maintains the expected state; what is supposed to be in the environment based on standards and fin- nancial records Maintains the actual state or physical representat- tion of what is actually discovered in the environm- ment Tightly integrated with incident, problem, and change management, plus other IT service mana- 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 infras- structure Key to achieving ITIL/BS15000 accreditation Often business unit-based vs. enterprise-focused For effective asset management, you need a method for reconciling physical inventory data with financial records.
- 122. 121 Closed-loop or operationalapproach. 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 operat- 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 dict- tionary, so all stakeholders interpret terms and the approach in the same way. Figure 3 highl- 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 vend- dor strategies, and greater adoption of ITIL. Federated or unified model. The two basic mo dels for the structure of the CMDB are a federa- 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 associa- ated with the pure centralized approach. The alternative, a unified model, stores all CMDB data in a single, unified data structure. A unif- fied model has fewer interfaces to build and maintain, and works well for a CMDB that is not too complex. For most organizations, especially ones that are large or complex, adding ITAM data to the CMDB contributes to the complexity and size of the database, making a unified approach impractical. If you populate the CMDB with all the attributes required for every ITIL process and ITAM, a single data store would quickly become unmanageable.The federated approa ch allows you to store a subset of critical data for all processes in the CMDB with “pointers” to data stores for less critical information. Step 7 Start Small, Think Big for Design and Implementation Your design and implementation plan for the CMDB should be based on the big picture or vision established early in the project. However, two goals must be kept separate: The long-term capabilities of the tool The immediate, most urgent needs of the business The overall design should focus on meeting the requirements of all the stakeholder groups. But when you plan the actual implementation, focus on the most critical business priorities first and start as small as possible, limiting your scope and the level of detail tracked for configuration items. For example, an ap propriate model to start with might be: Windows Servers — name, location, IP number, person, or Software — name, version, publisher, person After the tool has been live for some time, the plan should define a method for expanding the scope on the basis of operational needs. Items should be included only if they support the vision for the project and a prioritized list of requirements. It is important that the tool you use for a CMDB be able to accommodate future growth. If you choose a tool that allows only configuration mapping and later you want to include asset functions, you’ll be challenged if the CMDB cannot accommodate items such as contract data.You want to make sure the base structure and functionality of the tool will allow you to expand as you go.
- 123. 122 Step 8 Consider ToolOverlap and Organizational Gaps Remember that the CMDB is not an inventory tool. It should not just replicate data that is equally well presented through various inv- 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 examp- ple, assets might have no clear owner or support group Your work plan should allow time to identify and resolve these problems. Step 9 Remember Critical Plan Functions An effective work plan for deploying a CMDB must ensure that the following items are imple mented along with tools and processes: Metrics — Establish audits, measures, and metrics to determine the success and quality of the CMDB. Support — Define who will maintain data, manage databases, and audit for quality. Communication — Employ a comprehen sive communication plan that identifies who will be impacted by the program, and states the goals of the projects, the benefits to be achieved, and the measures of success. Training — Provide process and tool training for each of the teams using and supporting the CMDB.Training must focus not just on the functionality of the tool but equally on the underlying processes that leverage the CMDB. The Key to Delivering a Successful CMDB Defining value and success up front is the key to successfully delivering a CMDB. Identify the strategic goals of your CMDB.Your strategy should incorporate business purpose, high-level sponsorship, tool and architecture options, operational processes, communication strate gies, training approaches, and the metrics by which success will be evaluated.These elements will set the groundwork for an eff- 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.
- 124. 5tips for effective asset management with the cmdb Define the data the CMDB will store, the funct- tional requirements of the CMDB system, your structural approach, and your plan for turning your vision into reality.The effort you put into the beginning of the project will guide you and help you deliver a CMDB that will provide the information required to make effective business decisions — creating maximum value. n Julie Manis is an operational lead in asset management for the Global Architecture and Core Technolog gies group at Accenture. She has more than 20 years of experience deliveringhigh-valuelifecyclemana agement solutions, ITIL standard process solutions, and enterprise systems management solutions. ABOUT THE AUTHOR 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.
- 125. 124 Y ou wouldn’t writea 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 withd- 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 mone- 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 framew- 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 configur- 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 relat- tionships in the environment.This concept of a CMDB serving as single source of data, or “truth,” is its greatest strength.Without a cent- tralized foundation of accurate configuration information, IT organizations will continue to work in isolation, and may not have data neede- 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 inform- mation — such as service level agreements, purchase orders, incident and problem tickets, By kia behnia CMDB Business Value Unfortunately, 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.
- 126.
- 127. 126 performance and utilizationdata — 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 responsiven- ness to business requirements without becomi- 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. 1 Makes I.T. more responsive to business needs A 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. 2 Provides a service-oriented view of the I.T. infrastructure In addition to storing configuration information about the physical IT infrastructure, a CMDB should store information about the configur- ration items’ logical relationships to each other and to the business services that the IT infras- structure supports.This information provides business context for processes and activities so that the risk is assessed correctly and activit- 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 autom- mation in the future. For example, when ass- sessing a known vulnerability on a server, by using the information in the CMDB, an organ- 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 prio- oritize patches to machines that support the business services and ensure that business- critical systems are secure. No. 3 Facilitates compliance Another 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. 4 Reduces the impact of changes The 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 cont- 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)
- 128. 127 provides the abilityto 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. 5 Helps connect the “islands of information” within the I.T. department In 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 environm- 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 conf- figuration data across the organization so that processes can operate with access to all of the configuration data and the system dependenc- 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. 6 Creates synergy among processes, data and automation tools By eliminating the islands of isolation, IT organiz- 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 coord- 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 downt- time, and becoming more efficient. n Kia Behnia is the Chief Technology Officer for the Change and Configu uration Management solutions for BMC Software. Prior to joining the company,hewasCTOforMarimba. Earlierinhiscareer,Behniawasone of the principal technologists for Tivoli Systems. He can be reached at kia_behnia@bmc.com. ABOUT THE AUTHOR Copyright 2005, Line56.com
- 129. 128 Leveraging Identity Information Through theCMDB An identity management solution unifies and manages information about people who have access to the IT infrastructure. By leveraging identity management, you can achieve a comprehensive, accurate, and up-to-date source of people informat- tion for the CMDB.
- 130. T he volume ofinformation maintained by a configuration management datab- base (CMDB) is rapidly increasing in scope. Initially, the CMDB was purely an asset store that described the assets in the IT infras- 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 proc- 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 infrastruct- ture in many ways, depending on their roles and responsibilities. People access the IT inf- 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 compreh- hensive, accurate, and up-to-date source of people information for the CMDB. The Challenge: Unifying and Normalizing Data Enterprises already have a great deal of people information residing in their IT infrastructures. Platforms and applications maintain data about employees who have access privileges. Netw- 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 By Ahmad Abdel-Wahed and Bob Worner 129
- 131. 130 responsibilities within theirroles. Managers, for example, may have access to salary inform- mation in the HR system whereas nonmanag- 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 management An 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 managem- ment functions is to ensure that identity inf- 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 immediatel- 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 CMDB Well-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.
- 132. In addition, likeidentity management solutions, CMDBs offer autodiscovery capabilities that scan the IT environment, gathering and cons- 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 modeli- ing tools. Vendors are working to extend the reach of autodiscovery even further to include the rel- lationships between the IT assets and the business processes they support.This can be accomplished through integration with busin- ness process management tools such as the Business Process Execution Language (BPEL). It is possible to leverage the federated archit- tecture and autodiscovery capabilities of the CMDB to extend its reach into the people inform- mation that is available in the identity managem- 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 managem- 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 comp- 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. 131
- 133. 132 a proposed changeand 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 develo- opment cycle — possible impacts to the develo- 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 cont- 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 ident- tity management solution provide a self-service function that previously was provided through the service desk (e.g., password reset, applic- 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 comp- plete (opened tickets). For the purposes of autom- 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 busin- ness applications are associated with which assets and work with the business application owner to determine current and future capacit- ty requirements. For seasonal businesses, the employee turnover rates are cyclical and cap- pacity can be planned based on the expecte- ed usage level determined by the business application owner. The possibilities are virtually limitless and certainly exciting. n
- 134. 133 of Leveraging Identity Information Through the CMDB 5BENEFITSAhmad Abdel-Wahed is a program manager in the Microsoft Identity and Access Management group. Ahmad is a longtime Microsoft veteran who has a great deal of industry experience. ABOUT THE AUTHORS Bob Worner is the director of SolutionLineManagement,Identity Management Business Unit, for BMCSoftware.Withmorethan20 years of experience in software architecture, design, and developm 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 det- 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.
- 135. 134 CMDB: The Key to Jump-Starting ITIL Success By Kevin Behr, Gene Kim, and George Spafford Three experts discuss their 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.
- 136. 135 S ince 2000, wehave 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 documente- 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 incid- dent and problem management. All of the high performers had repeatable and verifiable processes to release infrastruct- ture components with a known working conf- 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 organ- nizations, each system administrator controls more than 100 servers. In contrast, organiz- 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 exp- 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 relations- 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 SERVERS 0 100 1,000 10,000 10 1 20 40 60 80 100 120 140 Efficiency of Operation SizeofOperation Figure 1. Server to System Administrator Ratio
- 137. 136 Culture ofcausality — 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 peop- ple, processes, and technology that make up Visible Ops Practice CMDB Enables you to: Stabilize the Patient – 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 Electrify the Fence – 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 Modify First Response – 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 Create the Change Team – Manage change resources Standardize on an approval and communication process, impact assessment, and forward scheduling changes — all based on CMDB CI and relationship data Utilize a Change Tracking System – Enforce auditable process Create and store a history of change approval and change history related to each CI Figure 2. Capabilities Enabled by CMDB forVisible Ops Practices in Phase 1
- 138. IT. An enterpriseCMDB consolidates this inf- formation and enables you to take action on it. We developed theVisible 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 1 Stabilize the Patient The 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 maint- 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.) Compliance and the CMDB 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. 137
- 139. 138 Phase 2 Catch andRelease; Find Fragile Artifacts In 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 busin- 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 implementat- 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 3 Create a Repeatable Build Library In 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 unp- 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 managem- ment processes, but you’ll need to complete the first two phases to successfully get through this phase.You will have to define build mecha- 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 pract- tices in this phase. (See Figure 4.) Visible Ops Practice CMDB Enables you to: Catch and Release – 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 Find Fragile Artifacts – 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 Prevent Configuration Mutation – 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 forVisible Ops Practices in Phase 2
- 140. 139 Phase 4 Enable ContinuousImprovement In 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 inThe 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 provis- 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: Enable a Release Team – Deploy reliable configurations into production Identify production CIs Identify functional state of CIs Provide clear picture of target release environment to ensure successful release Create a Repeatable Build Process – 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 Maintain a Definitive Software Library (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 Create an Acceptance Process Contract – Get approval from preproduction and post-production resources Store the contract as a revision-controlled CI Move from Production Acceptance to Deployment for all approved builds Process request for change (RFC) for system rollout — including risk analysis, forward scheduling of changes, etc. Figure 4. Capabilities Enabled by CMDB forVisible 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=809L2=21L3=35
- 141. 140 Shelf lifeof 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 int- tended process. Ratio of release engineers to system adm- 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 organ- nizations achieve better than 99 percent. Number of service-affecting outages — How many changes result in service imp- 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 funct- 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 bureauc- 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.
- 142. of Using aCMDB to Support ITIL Processes 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 effect- tively implement these practices, and the four phases ofVisible 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 transf- formation that other IT practitioners have achieved with their organizations. n A CMDB consolid- dates and enables you to act on the inf- 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 rep- peatable process for building your infrastructure. As the knowledge repository for IT, a CMDB is a critical enabler of cross-functional performance measurement. Kevin Behr is the CTO and chief operationalstrategistforIPServices 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. ABOUT THE AUTHORS George Spafford is the managing directorofSpaffordGlobalConsulti 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 comp panies. Georgeisco-authorofTheVisibleOpsHandbook. Gene Kim is cofounder of the IT Process Institute and is also the CTO and cofounder of Tripwire. Gene co-chaired the Best in Class SecurityandOperationsRoundtable (BIC-SORT) with the Software Engineering Institute. He is co- authorofTheVisibleOpsHandbook and is a primary researcher for the IT Controls Benchmarking Survey. This article is based on “TheVisible Ops Handbook, Starting ITIL in 4 Practical Steps” written by the three authors and published by the InformationTechnology 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.
- 143. 142 Just as aresort condominium sets a higher standard for housing, the CMDB raises the bar on how IT accesses data about IT application and infrastructure components. The result is a better ability to break down organizational silos and provide end-to-end IT service management. By Troy DuMOULIN CMDB: The Resort Condominium for IT
- 144. 143 A n evolution istaking place in informat- tion technology (IT) organizations across the globe.The interest in IT service management, the passage of business legislat- 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 comp- 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 spec- 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 exp- press frustration when they receive answers such as, “The server is up.Try calling the netw- work folks.” Also, business managers who care little about underlying infrastructure and operations issues (and rightly so) are dem- manding budget and cost visibility while ins- 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 inf- 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 dep- 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 indiv- 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 comp- 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 req- 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.
- 145. 144 organization for thesole purposes of the funct- tional groups that maintain them.What’s neede- 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 Condominium Let’s compare the current state of data managem- 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, whene- 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 prov- vided, it’s a better place to live. Second, the resort condominium (CMDB) ensures that these new “residents” still own the data in their ind- 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 perman- 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 members- 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 Challenges However, there is a problem.These new resid- 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 cond- 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 restrict- 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 mana- aged that data in isolated stores. Data struct- 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.
- 146. 145 The resulting resistanceto maintaining conf- 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, managem- 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 implem- mented as a result of the shift to a service management strategy. New horizontal mana- 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 structures Redefining job descriptions to include new areas of accountability and responsibilities for process-based activities Providing 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 departmental competition to customer-focused cooperation Rewarding 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 supp- 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 behavi- ioral change and process-oriented accountability. Integrated Service Management Tools Enable Cross-Functional Process Integration Effective 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.
- 147. 146 for management andmonitoring. Now organiz- 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 processe- es from a tool perspective. As shown at the center of Figure 1, ITIL establ- 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 probl- lem management, focus on the support of IT services. Security, change, and release managem- ment focus on the control of exposure, changes, and the deployment of new or modified comp- ponents into the production environment. Processes such as availability, capacity, IT serv- 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 aTool Perspective Service Level Management Change Management Security Management Configuration Management Relationships Inventory What / Where Asset TCO Capacity Management Service Desk Incident Management Service Continuity Management Financial Mgmt. for I.T. Release Management Availability Management Problem Management
- 148. 147 and relationship managementbetween the business and the IT organization. From a tool perspective, the relationships bet- 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 pract- 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 sensit- 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 transport- tation, and the look and feel of the resort. Communication and possible evacuation and recovery become much more managea- able when the data owners all live under one roof. By taking potential changes to the condom- 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 struct- 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.
- 149. Human Resources Order Management Financial Marketing SalesSupply ProcurementService Customers, products, and everything else Figure A. Central Data for Many Processes Lessons from Business Integration via ERP Systems The business has experience using software to help break down silos and streamline processes.The widest 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 busint 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 necesst 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 proct cesses control and manage data, the data should be stored and managed only once. 148
- 150. 5tips for Overcoming I.T.Silos Create a central rep- pository of record of all IT infrastructure components: a CMDB. Re-engineer IT proc- 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 relations- 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 Critical When organizations integrate IT processes with the CMDB, they can more efficiently deliver end-to-end service management. Implementi- 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 workf- 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 applic- cation. Such a tool enables cross-functional processes and the integration of IT silos. n Troy DuMoulin is an experienced executive consultant with a solid and rich background in business processre-engineering.Troyholds theManagementCertificateinITIL and has extensive experience in leading service management prog grams with a regional and global scope.HismainfocusatPinkElephant (www.pinkelephant.com) is to deliver strategic and tactical-levelconsultingservicestoclientsbasedupon a demonstrated knowledge of organizational transf 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. ABOUT THE AUTHOR When organizations integrate ITIL processes with the CMDB, they can more efficiently deliver end-to-end service management.
- 151. Don’t Forgetthe Network Network configurationmanagement is an important function that should be integrated with an overall configuration management and CMDB strategy. For a successful CMDB initiative, follow a three-step approach for populating the CMDB with network data, and use purpose-built network configuration management tools. By jeff gibson 150
- 153. 152 W e often thinkthat IT services rely solely on servers and applications. However, those servers and applic- 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 configur- ration management database (CMDB) will help you integrate the network layer into your overa- all IT service model and better align IT service delivery to business needs. Network Configuration and Change Management If 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 applic- cations and the multitieredWeb-centric comp- 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 thous- 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 dev- 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
- 154. NCCM provides achange control and change history function that is needed to implement revision control of configuration files, as well as physical network system changes.This comp- 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 Management Integrating 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 applic- cation dependencies enables a complete end-to-end service management approach. Logical connections between network compon- 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 Configuring Network Devices 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 devt vices, along with firewalls and load balancers, yield various configuration schemes that are often more complicated, adding to the complexity of the manat agement of the network layer. Many network device vendors offer simple tools that support changes to their products. Other vendt dors offer tools that help manage other aspects of network device configuration. However, to standt dardize and structure the management of these critical devices across the enterprise, organizations often deploy purpose-built 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. 153
- 155. 154 that enable youto view the business impact of network components.You will know exactly which components of the network infrastruct- 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 rel- lates to network infrastructure elements. As a result, you can control changes to that inf- 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 serv- 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 configurat- tion file at a predetermined time, and store a copy of the new configuration file revis- 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 managem- ment —The logical dependency relations- 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 busin- 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 ident- 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 provisioni- ing of configuration files that require additional Configuration Management Terminology ITIL 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 concerned with provisioning and known good conft 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.
- 156. of Including NetworkData in the CMDB 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 1 Add network devices In 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 configurat- 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 Add detailed hardware data In 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 Add logical configuration relationships In the final step, you should add logical conf- figuration relationships, such as the actual network interfaces on the devices. Adding relationship and dependency information enables you to view the service impact relev- 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 configurat- tions. One interface may be to the services of a certain set of applications and databases, while another interface may impact relations- 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, thephysicalconnectivity,andthelogicalconnec tivity to applications that are used as part of business processes. The deeper logical configuration data should remain with the network configuration applic- cations. But down the road, when the analytics surrounding CMDBs become more sophistic- 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 infras- structure. In the modern business, the network is so critical that even interaction with the outs- 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 Jeff Gibson has more than a decade of experience in software development in both product development andenterpriseIT.HecurrentlyleadsateamatVoyence focusedonintegratingthecompany’snetworkchange and configuration management product with other vendortechnologiestoproducehigher-valuesolutions for customers and partners. ABOUT THE AUTHOR You gain insight into contextual relations- ships, which enables you to view the busin- ness impact of netw- work components. You gain a picture that includes the physical device, the physical connectivity, and the logical conn- nectivity to various applications that are used as part of busin- ness processes. You can explicitly identify dependencies to help improve the overall management of the IT infrastructure. You can control infras- structure changes in accordance with ITIL- defined processes, enabling greater availa- ability, reliability, and security for services. You can better set and deliver systemw- wide service level commitments for various IT functions.
- 157. 156 T he configuration managementdatabase (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 infras- 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. Can People Be Configuration Items?
- 158. 157 Get more outof your CMDB and streamline your IT service support by maintaining a dynamic repository of informat- tion about the people involved in, and affected by, the incident management process. By Troy McAlpin
- 159. 158 Can people beCIs 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 serv- 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 Data What 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 respons- 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 Data When 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 autod- 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 inform- mation. Using the self-service functionality,
- 160. 5tips on people cis individuals wouldstate: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 mac- chines that don’t have feelings — don’t care how many times they get pinged during autod- 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 inform- mation is accomplished through a straightf- 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 autom- matically invalidate unconfirmed data on a timed basis. Matching People CIs to Incidents Using 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 communic- 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-sensitive 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-comm- 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 Future Incident 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 inc- 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 proa- 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 Troy McAlpin is the founder, chief executive officer, and chairman of Invoq Systems. The company develops and provides automated, broad-scale notification and intera action solutions to customers in a wide range of industries. ABOUT THE AUTHOR 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 upd- 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.
- 161. 160 L ego® revolutionized building blocksby providing a set of standardized pieces with uniform connectors that children of all ages can assemble to create large struct- tures of nearly infinite variety. Service-Oriented Architectures andWeb Services have brought a similar revolution to application development. TheWeb 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 verif- 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 develo- oped, aWeb 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 standardWeb Services interfaces to their applications, exp- posing application functionality as aWeb Service. As a result, business application programmers can now take advantage ofWeb Services to integrate applications and third-party systems. TheWeb 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 app- 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. When CMDB information links a BPEL-designed business process to Web Services and underlying IT services, you can dramatically improve the alignment of IT with the goals of the business. to manage I.T. from the business perspective By Devesh Sharma UsingBPEL,BSM,andtheCMDB
- 162. 161 Two sides ofa great story BPEL 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 developm- 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 developm- 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. ThoseWeb 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 infras- structure.That link is critical to managing and prioritizing IT resources from a business pers- 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 evolution There 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 infras- 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 inc- 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
- 163. 162 impact to specificbusiness 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 inclus- 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 mana- 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 infras- 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 probl- 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 toWeb 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 toWeb Services and business processes, the staff can determ- 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 —oreveneliminates— disruption to the business, through forward scheduling of changes and proactive comm- 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 infras- 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 perm- mit the IT staff to immediately determine and document the relationships among IT infrastruct- ture components and business processes. This mapping, which is essential for comp- 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 infras- structure or to the BPEL processes, and can update the CMDB accordingly.This will not only ensure the validity of the CMDB inform- 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
- 164. of BPEL, BSM, andthe CMDB 5 BENEFITS Business Process Execution Language Business Process Execution Language (BPEL) is an XML-based programming language and execution environment that is built on top ofWeb Services specifications. It enables programmers to define portable business process definitions forWeb Services Definition Language (WSDL)-based 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 byWeb 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. InApril 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 WS-BPEL technical committee voted in September 2004 to release the standard specification, namedWS-BPEL 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. Devesh Sharma is senior principal product manager for Oracle Fusion Middleware. His areas of focus includebusinessprocessmanage ment,Service-OrientedArchitecture, and applications integration. He also spearheads Oracle’s strategy forbusinessprocessmodelingand simulation tools. Devesh has more than 14 years of diverse experience in the IT industry. Jihad El-Assaad, Pierre Germain, and Matthew Selheimer also contributed to this article. ABOUT THE AUTHOR Enhanced ability to prioritize and address problems, based on business impact. Increased agility in adapting both busin- ness processes and the IT infrastructure to changes in the busin- ness environment. Improved ability to comply with governm- ment mandates through reporting of relationships among infrastructure compon- nents and business processes. Enhanced monitoring and management of process availability and performance. Greater insight into how proposed changes will affect business processes.
- 165. 164 I n the firstedition of Viewpoint, we introd- 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 managem- 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 relat- tionships, and focus on what’s important to you. A CMDB provides the single source of accurate information about your infrastruct- 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 relat- 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 enterprise Just ask Dr. Henry
- 166. 165 storing IT configurationitem 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 somed- 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? By Linda Donovan
- 167. 166 Probably not. Andif 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 everyd- 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 unrespons- 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.
- 168. 167 Put the less-relevantinformation 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 requirem- ments. Perhaps you forgot to go to the IT Infras- 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 implementat- tion in phases. And make an appointment to meet with me next week. n ABOUT THE AUTHORS Linda Donovan is a senior strategic marketing manager who manages theBMCSoftwareThoughtLeadership Council, a group of experts tasked withprovidingcommentary,analysis, andinsightforITexecutivesandtheir teams. Linda has broad experience in theenterprisesoftwareandaeros spaceindustries,includingexpertise inITprogrammarketing,communications,andstrategic analysis.Shehasbeentheeditorofavarietyofcorporate publications and has taught communications courses at three universities. Dr.Henry,CMDB,isanaccomplished CMDB therapist with more than 15 yearsofexperienceinthesoftware industry.Hispracticesareworldwide and he resides in cyberspace.
- 169. CONTRIBUTORS We greatly appreciatethe contributions of the following people and companies: Ahmad Abdel-Wahed, Microsoft Alexandre Avelar, CSC BRASIL Kia Behnia, BMC Software Kevin Behr, IT Process Institute Charles Betz Tom Bishop, BMC Software David Chiu, BMO Financial Group Linda Donovan, BMC Software Dennis Drogseth, Enterprise Management Associates Troy DuMoulin, Pink Elephant V’Ali Ford, EMS Jeff Gibson, Voyence Gene Kim, IT Process Institute Joe Lord, Aliant Julie Manis, Accenture Jonathan Markworth, CompuCom Tim Mason, TRM Associates Troy McAlpin, Invoq Systems Javier Leyva Novoa, Quitze Tecnología Jason Odden, Wipro Brady Orand, Column Technologies Craig Piercey, Aliant Frederieke C.M. Winkler Prins, Service Management Partners Val Sanford, Singlestep Perry Sellars, Strategic Technologies Devesh Sharma, Oracle George Spafford, IT Process Institute Selma Turki, IBM Kyle Ward, Aliant Hans-Heinz Wisotzky, MATERNA GmbH Information Communication Bob Worner, BMC Software Editor-in-Chief: Elaine Korn Senior Editor: Leanne Bantsari Technical Editor: Kurt Milne Technical Reviewers: Brian Emerson, Dave Wilt Editorial Team: Wendy Assatourian, Linda Donovan, Elizabeth Ferrarini, Paul Mangione, Sheila Mangione, Suszi McFadden Creative Design: Liora Blum Graphic Design Cover Photograph and Design: Della Calfee Creative Direction: Michele Floriani, Della Calfee Special 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. ACKNOWLEDGEMENTS 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 knowledge 2. Review and agree on CMDB goals 3. Create a CMDB mission statement 4. Review and identify governance requirements 5. Review and select supporting best practices 6. Identify inventory and asset requirements 7. Identify and address potential problems 8. Review and define benefits 9. Final scoping objective and expansion planning 10. Define service catalog CMDB requirements 11. Define requirements for other processes, including non-ITIL processes 12. Define configuration item level — IT service model 13. Define configuration item relationships 14. Define configuration item attributes 15. Design IT model blueprint 16. Select technologies for your CMDB 17. Calculate and present ROI 18. Construct your CMDB 19. 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 SOON STEP-BY-STEP GUIDE TO BUILDING A CMDB
- 170. CMDB Business Value A Planning Checklist for CMDB Success Demystifying Configuration Items Implementinga CMDB-based IT Service Structure 6Tips for Managing the “People” Factor Published by BMC Software Published by BMC Software A Compilation of Articles by Industry ExpertsA Compilation of Articles by Industry Experts VIEWPOINTFocuson:CMDBLeadershipVOLUMETWO 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 doesisprioritized 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