understanding the role of the cmdb in itil

© 2007 Jupitermedia Corporation

Understanding the Role of the CMDB in ITIL

March 5, 20072:00pm EST, 11:00am PST

George Spafford, Principal ConsultantPepperweed Consulting, LLC“Optimizing The Business Value of IT”www.pepperweed.com


Housekeeping

• Submitting questions to speaker– Submit question at any time by using the “Ask a question”

section located on lower left-hand side of your console.– Questions about presentation content will be answered during

10 minute Q&A session at end of webcast.

• Technical difficulties?– Click on “Help” button– Use “Ask a question” interface


Main Presentation


Agenda

• What Configuration Management's role is under ITIL • Change Management's Role in Controlling the CMDB • An overview of the architecture of a CMDB • The need for automated systems to facilitate processes • Example ITIL data exchanges

• For a copy of today’s webcast PPT, please email:– George at: [email protected]– Kendra at: [email protected]


The fundamental objective of ITSM is to deliver services that meet customer

requirements

And to do this we need timely accurate information


IT Enables the Attainment of Objectives and Goals

Organizational Goal

Accounting Manufacturing

Sales Customer ServiceHuman Resources


Necessitates Teamwork, Planning & Oversight

CustomerRequirements

ChangeMgt

ConfigurationMgt

Service DeskFunction

IncidentMgt

ProblemMgt

Service LevelMgt

CapacityMgt

AvailabilityMgt

IT FinancialMgt

IT ServiceContinuity Mgt

IT SecurityMgt

ServiceDevelopment

To achieve the goal requires proper management and a holistic vision – the creation of silos must be avoided!


IT Process & Function Integration is Key

• The power of ITIL lies in its systemic integration of processes areas – not simply piecemeal adoption

• Any single process in isolation will reach a level of diminishing returns

• As Goldratt has taught us, to optimize the throughput of a system requires optimization of the system – not just one area

• Continuous improvement requires a systemic mentality of adoption and continuous refinement

• Each area both draws information from, and supplies information to, other processes and functions

Service LevelManagement

IncidentManagement

ProblemManagement


CapacityManagement

AvailabilityManagement

IT FinancialManagement

IT ServiceContinuity

Management

IT SecurityManagement

ControlProcesses

ConfigurationManagement

ChangeManagement

ReleaseManagement


Configuration Management Enables Integration

• ITIL tells us that “Configuration Management provides a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration Items (CIs) in existence.”

• But what does this mean?• Configuration Management provides information about CIs to all the

other processes• Think in terms of a database• The Configuration Management Database (CMDB) is the nerve

center of IT – It relates all the data together, provides workflows, access to files, etc.– It can be one database or integrations into multiple sources (federated

models)

• The CMDB contains the data and processes that binds the ITSM processes and the organization together


More Than Technology

• Configuration Management is not just about technology

• Need the right people– Culture– Tone from the Top– Training– Motivation

• Need the right processes– Designed for the organization– Factoring in:

• Organizational goals• Functional area objectives• Constraints

• After you understand processes and requirements, then you need the right technology

People

Processes

Tech

nologyOutcom

es


Configuration Items (CIs)

• These are categories of data that you must track and are modeled using data tables– Hardware – PCs, Servers, Network Equipment, etc.– Software – Operating Systems, Applications, Tools, etc.– People – IT staff, business staff, vendors, etc.– Accommodations/Environment – Locations, data centers, wiring closets,

etc.– Data – tables, interfaces, etc.– Documentation – Policies, work instructions, SLAs, rollback plans,

incident records, problem records, request for change, etc.– Services

• Business processes – sales, accounts receivable, etc.• IT Services – What IT provisions to enable the business

• An ITIL “secret” is that nearly everything is a CI. The establishment of these CI-types, their attributes and relationships enable a logical model of IT


Attributes

• These are the data fields for each CI• What would you need to know in order to manage the CI?• A unique Identifier, model, status, purchase price, vendor, date

purchased, IT owner, RAM, drive space, CPU type, …?• CI vs. Attribute

– You can decide based on value, costs and risks

– CIs are used when relational data is needed to honor normalization of data, security, etc.

• “Is this data I will need to re-use in multiple places?”

• Annex 7C of the Service Support volume offers suggestions on attributes.


Relationships• The power of Configuration Management lies in relationships

• Parent Relationships -- What assembled/compound CIs uses this CI as a component?

• Child Relationships -- If this is an assembled/compound CI, what component CIs make it up?

• RFC Records -- Need to relate this CI to all request for change made against it. This may be the same as the change record IDs but it's listed separately here. The reason is to show all RFCs -- accepted and rejected;

• Change History Records -- Relate this CI to all changes made to it. This allows for the Change Manager and other stakeholders to gauge historical activity;

• Problem Records -- What problems have this CI been associated with? • Incident Records -- What incidents have this CI been associated with?

• …and whatever else is needed for Service Level Management, Capacity Management, Security, IT Service Continuity Management and so on. The more you add the more complex the data model becomes


Avoiding Irrelevance

• The possibilities and headaches are limitless• Accuracy is absolutely vital!!• A complex system that is difficult to update will not be

used and/or errors will creep in• If the system is out of date, then the data is out of date

so people use it less as the system of record and the data gets further out of date and people use it less and …– The downward spiral begins

• Your design must be meaningful and manageable– Capture what you need – not what you can


CMDB Tooling

Notice we discussed processes first! Tools come after process definitions not before.


Because the CMDB is a logical model of your infrastructure and will

be used to support your people, processes and technology, you must formally identify requirements prior to

either buying or building it.


Questions That Get Asked

• What do we have?• Where are they?• How do they relate?• How are they configured?• Who should I talk to?• How does the business use them?• What’s the history of each device?• What has caused failures in the past on device X?• What changed? (THE most important question to ask

when an incident starts!)


The Need for Automation

• What goes into the CMDB represents a tremendous amount of data!!

• Manual stand-alone records are not realistic options due to the level of integration and volume of data coupled with the need for security, data integrity, etc.

• Need systems that can automate the management of data records while maintaining referential integrity

• Need integration capabilities to support federated models that facilitate– Access to timely and accurate data– Normalization of data

• Coordination of activities in decentralized operations• Need to generate meaningful consolidated reports• A robust security model that supports the business


Configuration Management and Auto-Discovery

• It seems simple to buy a tool to discover everything on the network and drive the data into the CMDB?

• One question though – “Why did the CI change or suddenly appear?”• A green fairy doesn’t appear at 2am and reconfigure devices or change code randomly• Someone likely made the change – why?• Most errors in the CMDB are caused by Change Management failures

– Excluding typos/data entry errors of course– The CMDB says 16GB of RAM yet there are 128GB – Why?– The CMDB says release 1.35 is installed yet it really has 1.50 – Why?

• Need to reconcile these detected changes *before* simply accepting them– Who, why, is it a security event?– The only acceptable level of unauthorized change is zero!!!

• Note standard change model in ITIL before panic sets in• For regulatory compliance, reconciling changes is mandatory

– Otherwise, how will auditors know that all changes were authorized?


High-Level Tool Considerations (1)

• Know your requirements first! Do not buy a tool and then attempt to make it all work!– This will be the heart of your ITSM effort – make the investment count

– There isn’t a silver bullet answer – you need to define your specific requirements

– ITIL recommends all mandatory requirements be met and 80% of operational requirements

– Must support the business – not just IT

• Select an experienced vendor who is stable and proven!– A CMDB is too critical to gamble on fly-by-night vendors

– A clearly articulated and proven ITSM implementation

• Important Note - “ITIL Compliant” is a marketing term not standards based


High-Level Tool Considerations (2)

• Look for the following high-level features– Extensible data model

• Federated CMDBs

– Extensible Workflow• Adaptable to your requirements• Automation of related transactions

– Open Platform / Integration to Other Systems• Within the enterprise• Moving into the value chain

– Enterprise Class• Database• Security• Ability to support remote sites (very important)


Data Exchange Examples Based on ITIL

• Each process has data inputs and outputs

• Configuration Management is the hub

• The data exchanges will depend on your needs

• Try to design your process first and then your tool second– Easier said than done if you

have an existing tool!!

Service LevelManagement

IncidentManagement

ProblemManagement


CapacityManagement

AvailabilityManagement

IT FinancialManagement

IT ServiceContinuity

Management

IT SecurityManagement

ControlProcesses

ConfigurationManagement

ChangeManagement

ReleaseManagement


Change Management• Can IT manage risks associated with changes to services?• Management of all Request for Change (RFC) records

– Add, change, delete

• Status of changes• Identification of related CIs to facilitate impact assessments• Identification of CI Owners for planning and communications• Configuration audit exceptions

– Production did not match the CMDB

• Current CI configuration for planning the change• Relevant SLAs• Information on proposed cost and benefit of each Change (as part of

the Change record)

• NOTE: Nothing should change in the CMDB without an approved RFC!


Release Management

• Can IT reliably deploy new and changed services into production without negatively impacting the business?

• Release Management records• CI information for the Definitive Software Library (DSL)

– What CIs are needed to create the Release?• CI information for the Definitive Hardware Store (DHS)

– What CIs are needed to build the hardware for the Release?• CI audits

– Pre-release to determine what production looks like– Post-release to confirm that only what was expected to change actually changed– Think of the thousands of files that can change – this is where an automatic

detective control can make a big difference• CI information to plan the release

– Facilities – what racks are available? How much power is there?– Who needs awareness information?– Who needs training?– What documentation needs to be updated?


Incident Management / Service Desk• Can IT assist users in the speedy recovery of services or service requests?• Service Desk Scripts are CIs• Service Requests and Incident Records are CIs• Information on the CI(s) involved including relationships• Details on caller (the caller is a CI!)• Business CI Owners• IT CI Owners• Supplier / Vendor• Service Level Agreements• Matching data

– Related Incident Records– Related Problem and Known Error Records– Established Work Arounds– Change Records – What Changed?

• Escalation protocols• Alerts and/or Alarms from monitoring tools

– You want to create Incident records (which are CIs)


Problem Management

• Are root causes established to address trends and/or prevent incidents from occurring?

• Information on the CI(s) involved including relationships• Details on caller (the caller is a CI!)• Business CI Owners• IT CI Owners• Supplier / Vendor• Service Level Agreements• Related Problem and Known Error Records• Established Work Arounds• Escalation protocols• Information for Problem analysis

– CI History– Recent Changes


Service Level Management

• Are the needs of the business understood and consistently met?• Service Level Agreement Documents• Operating Level Agreements• Underpinning contracts• CIs that make up services

– Hardware, Software, People, Documentation, Other Services, etc.

• Who are the Customers and/or System Owners?• Incident Records for review• Problem Records for review• Performance relative to SLAs• Quarterly Business Reviews

– Reports– Meeting Minutes

• Service Improvement Programs (SIPs)


Availability Management

• Can IT provision services the are available when the business needs them?

• What CI’s make up a service• Relevant Service Level Agreements• Availability targets• Performance relative to targets

– Breaches– Near Misses– Trends

• CI data used for analyses– Component Failure Impact Analysis (CFIA), Fault Tree Analysis

(FTA)


Capacity Management

• Can IT provision services with adequate capacity to meet the needs of the business both now and in the foreseeable future?

• Identification of CIs that constitute services• Service Level Agreements• Thresholds for Alerts and Alarms

– Incident records arising from monitors are CIs• Business Requirements• IT Service Requirements• Component CI Requirements• Review of Incident Records for service improvement• Capacity Plan is a CI• Capacity Reports are CIs• Note: ITIL defines a Capacity Database (CDB)

– Allows for monitoring data details to be stored outside of CMDB– Summarized data could be shared with the CMDB


IT Service Continuity Management

• Can IT support the organization’s Business Continuity Plan (BCP)?

• What CIs make up each service• How are the production CIs configured?• How are the DR site CIs configured?• Change Management records• Relationship data facilitates Business Impact

Assessments (BIAs)• Plans can be stored in the CMDB• Recovery targets and performance are CIs• Test plans and results are CIs


IT Financial Management

• Are the costs and value of IT understood?• What CIs constitute a service• Purchase Costs, dates, vendor, etc.• Loaded hourly rates for people• Operating costs• Budgets• CI Owners / Customers• User Departments• Chargeback models / schedules• Notional Chargeback Reports• Value studies


Security

• Is the organization relatively secure to operate without negative consequences from external entities?

• What CIs constitute a service• Baseline configuration• Unauthorized changes that have been detected• User access approval records• Security device configuration (hence need for sound

security models of the CMDB itself)• Business Impact Assessments• Security Incidents• Risk Assessments (could tie out to an ERM system)


Continuous Improvement Is Key

• Like any process, you must pick a place to start and begin

• Understand what you need and pursue that

• Refine Configuration Management, the CMDB and all of ITSM over time

• It’s a journey– Your organizations will evolve– Your processes must evolve to

support the needs of the business

Where do we want to be?

Where are we now?

How do we get to where we want to be?

How do we monitorProgress?

Vision and Objectives

Audits / Assessments

Process Improvement(Leverage Best Practices)

Metrics and Critical Success Factors

* Adapted from ITIL Service Support Graphic


I keep six honest serving men (They taught me all I knew);

Their names are What and Why and When and Where and How and Who.

-- Rudyard Kipling


Process References

• The Official OGC ITIL Sitehttp://www.itil.co.uk/

• Microsoft’s Operations Frameworkhttp://www.microsoft.com/technet/itsolutions/cits/mo/smf

• British Educational Communications and Technology Agency (BECTA)http://www.becta.org.uk/tsas

• IT Process Institute’s Visible Ops Methodologyhttp://www.itpi.org

• PMI Project Management Body of Knowledgehttp://www.pmi.org

• Projects in Controlled Environments version 2 (PRINCE2)http://www.prince2.org.uk/web/site/home/Home.asp


Thank you for the privilege of facilitating this webcast

George SpaffordPrincipal Consultant

Pepperweed ConsultingOptimizing the Value of IT

[email protected] http://www.pepperweed.com

Daily News Archive and Subscription Instructionshttp://www.spaffordconsulting.com/dailynews.html


Questions?


Thank you for attending

If you have any further questions, e-mail [email protected]

For future ITSM Watch Webcasts, visit www.jupiterwebcasts.com/itsm