Creating Visio Service Maps From an ITIL Service Management CMDB Anthony Brimacombe, Senior Manager

Configuration Management

Lloyds Banking Group

1. The Team

2. The Database (CMDB)

3. The Challenge of Visualisation

4. The Need for Visualisation

Presentation Structure

1. The Team Anthony Brimacombe

Senior Manager

CMDB

Architecture

CI Data Owner &

Customer Liaison Integration

Service Variation

& Data Cleaning

1. The Team Anthony Brimacombe

Senior Manager

CMDB

Architecture

CI Data Owner &

Customer Liaison Integration

Service Variation

& Data Cleaning

3 People

The CMDB Architects are responsible for:

• Assessing new requirements for CMDB Data.

• Designing the CMDB data model, from the overall structure down to the specific attributes.

• Designing the Configuration Management Process, including the automated data feeds from systems

such as Tivoli.

• Providing consultancy on how CMDB data could be used to enable or enhance other service related

processes.

1. The Team Anthony Brimacombe

Senior Manager

CMDB

Architecture

CI Data Owner &

Customer Liaison Integration

Service Variation

& Data Cleaning

4 People

Service Variation (SV)

• Deals with the change control and Audit Trail of Service documentation.

• Act on behalf of Service Managers (SMs) to manage changes to their data within the CMDB.

Data Cleaning

• Ensuring that hardware and logical level CIs (Configuration Items) are correct, contact details for SMs are up

to date and relationships for CIs are in place.

1. The Team Anthony Brimacombe

Senior Manager

CMDB

Architecture

CI Data Owner &

Customer Liaison Integration

Service Variation

& Data Cleaning

2 People

Provide Support and Guidance for:

• CI Data Owners to enable them to manage their Configuration Items.

• Our Customers (the Incident, Problem and Change Management and Business Services Teams).

• Our CMDB Data Consumers to ensure they understand the benefit it provides in order for them to make

informed decisions.

This is achieved by:

• Building relationships with CI Data Owners, Customers and Consumers, creating Job Aids and Training Packs,

delivering training, requesting reports and providing ad-hoc support when requested.

1. The Team Anthony Brimacombe

Senior Manager

CMDB

Architecture

CI Data Owner &

Customer Liaison Integration

Service Variation

& Data Cleaning

1 Person

The Configuration Integration function exists to deliver the Configuration (CMDB and Data) elements of the

Integration plan.

2. The Database (CMDB)

An Overview of Basic CMDB Structure & Content

Hardware

Service

System

Subservice

Logical Host

Cluster

Service: A set of related functions provided by IT in support of one or more

business processes that are collectively seen by the customer as a self-

contained entity. In LBG terms, this is the whole IT capability delivered to a

specific Business Unit regardless of size, costs or ownership and is defined in

a Service Agreement. (E.g. Internet Banking).

Sub Service: A logical sub-division of a Service. One or more “Enabling

Business Function(s)” that grouped together make up a single Service.

These Sub Services are underpinned by one or more IT systems. (E.g.

Internet Banking LBG Sub Service).

System: A set of one or more applications, software and hardware

technology platforms, satisfying a single business requirement. (E.g. CBS,

OCIS, IB Registration)

Logical Layer: These represent Logical Partitions, Logical Hosts and the

logical representation of the physical Hardware (partitioned or non-

partitioned)

Logical Cluster Layer: These represent VMWARE clusters in the

Distributed Windows environments. This layer is optional as only Distributed

platforms include them (new to the CMDB in 2010). The vast majority of

logical layer items are not clustered and will relate directly to Computer

Hardware.

Computer Hardware: These represent the Computer hardware of varying

types for z-Series, I-Series, Unix , Tandem and etc. The names for ALL

Hardware items relate to the unique Asset Tag numbers from „Archibus‟ (E.g.

12345, 84746)

Basic CMDB

structure

BS

M /

SA

M o

wn

Pla

tfo

rm t

eam

s o

wn

HBOS legacy

items

LTSB legacy

items

Complete

volume

0 98 98

0 376 376

429 619 1048

19573 11603 30 000 +

0 5 5

9213 9829 20 000 +

2. The Database (CMDB)

2. The Database (CMDB)

•Choose Relationship

Graph from tool bar

•Service Level CI

•Sub-Service Level CI

•System Level CI

•Here we can see SM7

•Logical Layer „click on +‟

•Viewing window

Scope. More CI‟s

reduces what you

can see clearly

•For this example we will look at the IT Service

Delivery Tools Service (SM7 is part of this)

•This is a very simple

structure that makes it

easy for us to see the

different layers

3. The Challenge of Visualisation

3. The Challenge of Visualisation

It gets complex:

There are 161

CIs shown…

the CMDB has

>30,000.

Dependencies

are checked

and updated

daily.

Automation is

used where

practical.

3. The Challenge of Visualisation SERVICE INFORMATION REQUIREMENTS (1)

“Top Down”

Service

focused…

which

components

support this

service?

Service

Hardware/Virtual (133) Host

3. The Challenge of Visualisation SERVICE INFORMATION REQUIREMENTS (2)

“Bottom Up”

Component

focused…

which

Services use

this

component?

Services (33)

3. The Challenge of Visualisation REAL EXAMPLE – The HR Service:

4. The Need for Visualisation The primary uses of the data in our CMDB are:

1) To ensure that Change Raisers and Approvers understand the

true potential impact of a change (and therefore reduce the risk of

a change related outage). We currently have 4,500 Change

Records raised per month.

2) To ensure that all data necessary for swift Incident resolution is

available when required.

3) To assist with Problem Record trending.

4) For data review, verification and correction to support the above.

Explaining service relationships is best done visually.

However,

1) The CMDB GUI is forms based – it is not easy to comprehend complex data.

2) Alternate formats (such as Excel Spreadsheets and Visio diagrams) are

preferred by our customers.

4. The Need for Visualisation

ACCESS TO SERVICE KNOWLEDGE

No need for

CMDB access

Direct CMDB

access required 1. I, P and C forms and user interface 2. Internal Reporting 3. Some Visualisation – limited by complexity

4. Standard Visio service maps – “the maintained view” 5. Ad hoc Visio service maps to suit project / process needs 6. Multi-level / multi-CI query for change impact assessment

7. Integration with other systems 8. KMDB – SharePoint based

5. In Summary

A complex CMDB can be delivered, used and

maintained. It underpins Service Management

processes but requires good reporting and visualisation

to be fully effective.

In practice, service understanding requires CMDB data

to be visible and accessible in different formats at

difference times. E.g.:

Automation of Visio diagrams for CI Data Owner

review and verification.

Production of ad hoc views to suit Management or

Project team needs.