THE ULTIMATE

CMDB GUIDE
FOR SERVICENOW
BY LOC HORISBERGER
ABOUT THE AUTHOR
Loc Horisberger is a Senior Service
Management Consultant at
Fruition Partners, a CSC
company. He started working
on ServiceNow 7 years ago
when he joined Aspediens,
the European ServiceNow
expert, that is now part of
Fruition Partners.
During his years has Technical Consultant, then
Solution Consultant and now Service
Management Consultant, Loc has gained an
extensive knowledge of the ServiceNow
ecosystem as well as of the ITIL, ITSM and Service
Management areas.
With a Bachelor of Science in Media Engineering,
Loc is as well certified ITIL v3 Foundation; ITIL
2011 Intermediate - Service Operation;
ServiceNow System Administration; ServiceNow
Implementation Specialist; ServiceNow Certified
Trainer; CipherCloud Solution Architect;
CipherCloud Project Management; and, finally,
Okta Solution Partner.
During his free time, Loc can be found piloting his
plane across the skies of Switzerland and Western
Europe, experiencing the magic and wonder of
being up there and seeing the world from a
dierent angle.
i
TABLE OF CONTENTS

Chapter 1 - Introduction 3

Configuration Management as per ITIL copy 5

Asset Management 6

CMS vs. CMDB 8

Chapter 2 - Implementation 9

How to proceed 10

Configuration Model 14

Pitfalls 39

Integration with CMDBs/MDRs 41

ServiceNow Discovery 44

ServiceNow Service Mapping 46

Chapter 3 - Processes 49

Roles and Responsibilities 52

Assets and CI lifedycle 56

Use Cases 58

Chapter 4 - ServiceNow CMDB and asset functionalities 64

CMDB Health 65

Dependency View 71

Change Management 74

Glossary 80

ii
1
INTRODUCTION
Building a CMDB is like building a house. Lets
agree that every house has a door, windows, at
least a floor with a few rooms and a roof. Then
you may want to add a fireplace, a second floor or
a swimming pool in the garden depending on
your needs. All CMDBs are very similar but
depending on the organization and processes it
has to support, dierences may be implemented.
Nowadays, infrastructure and application layers
are standardised and pretty much all
organizations are facing the same challenges.
Moving forward, the ITIL maturity level will
continue to increase thus needs from the CMDB
will be converging to become very similar.
Building a CMDB is like building a
house. Lets agree that every house
has a door, windows, at least a floor
with afew roomsand a roof. Then
you may want to add a fireplace, a
second floor or a swimming pool in
the garden depending on your
needs.
This ebook is intended to readers who are in the
process or will be in the process of replacing the
current legacy ITSM solution by ServiceNow or
are simply implementing ServiceNow and need to
build a CMDB. ServiceNow is a vast and very
flexible product which is often not the case of
legacy solutions. Implementing ServiceNow is
therefore a great opportunity to build a tailored
cut CMDB that perfectly fits your needs. In
addition to this, ServiceNow has unprecedented
level of integration with all processes, ITIL, IT or
non-IT. Vast also means that to make sure you
start on the right track, you need guidance and
that is what this ebook is intended to be.
Recommendations made in the following chapters
are guided by twofactors:
1. Respect as much as possible the CMDB
vision of ServiceNow. This means remaining
as close to standards as possible ("out-of-
the-box).
2. Best practices gathered along the multiple
CMDB implementations we have done at
Fruition Partners for our customers.
This ebook is organised in four parts. The first
one, the introduction, will focus on a bit of theory.
The second part will be focusing on the
i m p l e m e n t a t i o n p r o c e s s o f t h e C M D B
(establishment of the configuration model). Then
the third part will be focusing on processes,
mainly to the management of the lifecycle of CIs
once the CMDB is in place and fed with data.
Then finally, the fourth part will be focusing on
ServiceNow and key functionalities leveraging on
the CMDB.
Last but not least: KISS - Keep It Simple and
Smart. Pretty much any physical or logical
components of the whole IT of an organization
could find its place in the CMDB. But building a
CMDB is a journey and you should go step-by-
step. If defining some areas of your configuration
model is too long or tends to be complex/
complicated, simplify. Start simple and expend
later.
4
CONFIGURATION MANAGEMENT AS PER ITIL COPY

As per ITIL books, configuration management (or eectively. CIs are also key in speeding up and
Service Asset and Configuration Management - making incident and problem management
SACM) is a process that: processes more ecient. This inventory of the IT
aspects of an organisation, the CMDB, is also
Supports the business and customers control
leveraged to spot ineciencies and thus optimise
objectives and requirements .
services, capabilities and resources (CSI).
Supports ecient and eective Service
In Configuration Item, there is the word
Management processes by providing accurate
Configuration which needs to be emphasised. In
configuration information to enable people to
a CMDB/CMS, we really focus on configuration
make decisions at the right time, e.g. to
information about a given element of the IT
authorize change and releases, resolve
inventory:
incidents and problems faster.
That an element is a server and not a network
Minimises the number of quality and
device
compliance issues caused by improper
configuration of services and assets. That a server has 64 GB or RAM

Optimises the service assets, IT That a storage device is consumed by the ESX
configurations, capabilities and resources. cluster XYZ

Because the core of this process is a CMDB or a etc.

CMS (Configuration Management Database/
The primary consumers of the CMDB will be the
System), it should reflect as much as it can the
Service Desk and SMEs in the scope of the
current state of applications and infrastructure of
change/release management process. In other
the organisation. Elements composing a CMDB
words, IT technicians and engineers
are CIs that are interconnected to form a network
of dependencies between a datacenter and a
service.

These CIs need to be controlled in some manners

(for regulatory reasons or simply because without
controls over them we cannot prevent failure)
through a change management process. They
should also provide necessary information to the
change process so decisions can be taken

5
ASSET MANAGEMENT
When the CMDB focuses on configuration
information and interactions between CIs, asset
management will rather focus on organisational
and financial aspects of equipments. The focus of
this document is the CMDB and not asset
management, but we cannot speak about one
without mentioning the other. An asset manager
wants to know the following:
What is the price of a server and how much it
costs
When the guarantee expires
How much workstations will need to be
replaced next year
etc.
Before a device (a CI) is installed, up and running
delivering some kind of service, it has to be
created in the real world as well as in the CMDB.
This is also an aspect taken care by the asset
management process: the lifecycle. Asset
management in ServiceNow encompasses the
following sub-processes:
Product catalog: manages models of assets/
CIs currently used or planned to be used by
the organisation. It also allows the publication
of part of it in a request catalog to allow users
to directly place a request for what they need.
A vendor catalog aspect is also provided to be
directly integrated with vendors.
Procurement: this is an interesting small
process that do not intend to replace
company-wise procurement solution, often
SAP but would rather integrate with
ServiceNow to keep track of the origin of
assets and subsequently CIs.
Contract management: manages IT contracts,
from maintenance to warranties through PO,
NDA, etc. A contract will cover one or multiple
assets.
Inventory management: manages assets in
stock, stock transfers, auto-restockingetc.
Stocks is the source for assets/CIs to be
installed. An asset or a CI should not be
created installed but rather changed from
status In stock to Installed.
Because the audience and the aspects tracked by
asset management are not the same than for the
configuration management, we mainly have the
following kind of assets:
Hardware: server, workstation, network device
but not VM
Software/application: MS Oce, Oracle 11g,
ServiceNow or Salesforce
Consumable: printer toner, keyboards or mice
if managed as such
6
A software/application asset is essentially known
as a software license. A consumable is an asset
that has a cost and that matters to the
organisation but that are not tracked
independently. We have 200 keyboards in stock
and if someone needs one, we take the first one
we find. Once a consumable is consumed, its
value is lost. It therefore has 2 states In stock
and Consumed. A consumable has no impact on
the CMDB thus we wont talk about it in this
document.

Asset and CI synchronisation mechanisms in ServiceNow

7
 The dierence between a CMS and a CMDB is in the scope. The
CMS VS. CMDB CMDB, as known from a ServiceNow standpoint, is the database in
which we store configurations. Which means the application and
infrastructure inventory of the organisation. The CMS
encompasses more than configurations such as a KEDB (Known
Error Database) and master data (users, groups and organisational
data).

In addition to that the concept behind the CMS is the federation of

CMDBs. A CMS is composed of multiple CMDBs but do not, or
ideally should not, replicate their data. The ideal CMS is a heavily
integrated technology that reads multiple CMDBs on demand, thus
always displaying the most accurate information to its user. It
would heavily leverage on technologies such as web services and
structural languages to achieve this.

In reality, the theoretical CMS does not exist yet. When it comes to
ServiceNow, we have an additional challenge which is SaaS. It is
dicult for such a solution to reach, on demand, hosted systems/
CMDBs. In this document I will by convention use the term CMDB,
meaning a federated CMDB which is actually what ServiceNow
oers.

8
2

IMPLEMENTATION
The implementation of a CMDB is a long process CMDB. Few organisations can say for sure which
and its not easy. Many organisation struggles service, and subsequently customers, will be
and for various reasons. Often, from my impacted if server n 84 in a datacenter is shut
experience, its due to a poor ITSM strategy thus down.
jumping too quickly to the implementation with
Finally the CMDB implementation does not stop
poor acceptance and understanding of major
after the first phase but is/should be continually
SMEs. Or due to a poor design or understanding
improved.
of organisations scope of services. We dont
know what we deliver but we need a CMDB. If you plan to do a big bang in one phase, the
risk of a failure will be high. The CMDB touches
It is actually quite rare to meet an organisation
from close to far to a vast amount of areas of an
that says we have implemented a complete
IT organisation that it is way too dicult to get it
CMDB. Most of them do have MDR (Managed
right in one phase. The most important aspect of
Data Repositories, such as SCCM) for specific
the implementation of a CMDB is to start small
areas. Many of them have integrated some MDRs
but right and grow it on regular basis along with
with ServiceNow. The real value of a CMDB
the experience you gather using it.
comes when dependencies between CIs are
known. A CMDB without CI relationships is more
a flat inventory of IT components rather than a
9
HOW TO PROCEED
There is three ingredients to have before the actual implementation can start:

1. You need to know what you deliver to your customer

2. You need to know what data sources you may have for the CMDB

3. You need to define the scope of the first phase

The first point, in an ideal world, is knowing the list of business services. If not, because its not trivial, its
at least having an inventory of the business applications.

The second point is about having an inventory of all the tools/spreadsheets used across the IT
organisations to maintain configuration information. Often, updating the CMDB is perceived as an
additional overhead task because the actual work is also done somewhere else.

The last point is dependent on the first two. The maturity of your services coupled with the readiness of
the dierent sources to be migrated/integrated with ServiceNow will define the scope of the phase.

THE FOUR QUESTIONS

1. What classes of CI do I need?

2. What sources do I have for these classes?

3. Which attributes do I need for these classes?

4. How are these classes relating to each other?

For the first question, there are basically two approaches:

Bottom-up
Top-down
The bottom-up approach is when there is already a good level of maturity within the IT organisation and
that people know their applications and infrastructure. This is the usual approach when ServiceNow
replaces a legacy CMDB or when it has pretty clear and robust sources.

The top-down approach is about selecting 3 very dierent services and organise workshops around
them with all necessary stakeholders to discover, all together, how these services are actually
provided to the users. This sounds a bit odd but when the ServiceNow CMDB implementation is the first
trial towards a federated CMDB, the reality is that within the IT organisation, there are lots of
misunderstanding how certain part of it work. Often people work in silos very well but dont know how it

10
works in the silo next to them. Three typical
services could be:
Messaging
ERP
An in-house developed application
Note that Im mentioning a typical service that all
companies have (messaging) and 2 services
supported by applications. In this approach, often
services are not yet known or well-defined thus
the selection of 2 applications.
Due to the level of uncertainty with such an
approach, usually workshops are organised in 2
short sessions per service plus a reconciliation
workshop where the result of all 3 services can be
demonstrated. A proposal for the phase 1 can be
then extracted with the list of needed classes.
The goal of the second question is to identify, for
each necessary classes, if among the inventory of
tools/spreadsheets, one can be used as the
source of data. There are 2 types of sources:
An integration - data is refresh on a regular
basis (usually daily or more often)
Sometimes it turns up to be too granular and
therefore the list should be simplified. Remember
that the CMDB needs to be maintained for many
classes that will stand between a service and a
datacenter. Its better to have a simple CMDB with
up-to-date and trustful data than a complex CMDB
not maintained and therefore with data users
cannot trust.
The goal of the third question is to make sure we
re-focus on what the CMDB should support at
first: incident, problem and change management.
This means:
We should provide the minimum necessary
information needed for theses processes.
But we shouldnt store in the CMDB too
detailed information that we wont be able to
maintained automatically through an
integration.
Basic attributes such as a name, serial number,
model, manufacturer or assignee are always
needed. More detailed attributes can vary a lot
from an organisation to another. The strategy/
process should always be the following:

A one-time shot - a
source we rather
migrate than
integrate to
ServiceNow

At this point some

decisions must be
taken. A top-down or
bottom-up definition of
classes does not
necessarily give you
what is exactly needed
i n S e r v i c e N o w . CI attribute decision flow

11
Finally, the goal of the last question is to get the glue that will allow us to build the configuration model:
define dependency relationships between classes to ensure we have a path that link a datacenter to all
services/business service it indirectly provides. This question is answered in details in the coming
chapters.

ESTABLISHING A CONFIGURATION MODEL

The goal of a configuration model is to document and track the configuration and evolution of your
CMDB. Its a relatively simple diagram that illustrate clearly how classes relate to each other. It should
help users to understand how the CMDB is structured and how they should use it.

Example of a configuration model

The construction of such a diagram is no rocket science. In all organisation, applications and
infrastructure items relate to each in the same manner. Everyone uses pretty much the same
technologies with some exceptions here and there. The following chapters will explain in details our
best practices for each area of such a model.

12
At this point, it is important to explain the following concepts and dierences:

CI class vs. CI components

CI relationships vs. technical references
Boxes displayed in the above diagram are CI classes. CI components are also implemented as a CI
class from a technical perspective in ServiceNow but are not relevant in the above model. A CI
component is typically a disk or a network adapter of a server/workstation. These can be maintained in
the CMDB but are not important in a configuration model. In addition to that, incidents, problems and
changes are not raised against CI components but against the parent CI in a CI class.

A CI relationship is displayed in red in the above diagram. A CI relationship is always a dependency

between two CIs. There is always a parent and a child. Blue relationships in the above diagram are what
is called a reference in the ServiceNow language. This type of relationship is used to link CI
components to CIs or to represent technical relationship between CIs. A technical reference/
relationship might also be a CI relationship when the technical link directly implies a dependency in the
configuration model.

For example, a computer room can only be in one datacenter. This is a technical link between the two
CIs. It also means that the computer room is dependant on the datacenter. If the datacenter burns
down, then the room will be out of order as well. A disk link to a workstation is a technical link between
a component and a CI. It is not a CI relationship because disks are not relevant in the configuration
model thus dont have a CI relationship defined.

13
CONFIGURATION MODEL

For the following chapters, the configuration We will start with datacenter operations because
model has been sub-divided into the following this will be the basis to construct the CMDB.
areas to dig into: Datacenters houses the organisations hardware,
they provide physical capacity. Then network
1. Datacenters
and storage will be housed mostly in datacenters
2. Networks and will provide connectivity and data storage
capacity. Then the computing section will
3. Storages encompass everything around servers, clusters
and virtual machine. It provides computing
4. Computing
capacity. Finally, physical, connectivity, storage
5. Applications and computing capacity are used by applications
to provide services. In addition to that, we also
6. End-user devices have to consider end-user devices.

7. Services Finally and importantly, we will consider an

implementation without using ServiceNow
As illustrated by the above diagram, each area
Discovery nor ServiceNow Service Mapping. The
has a dedicated color which should help to
reason is that both products are quite structuring
understand how they relate with each other. The
and therefore, the approach should be slightly
objective here is to present how the vast out-of-
dierent. Nevertheless, two chapters will present
the-box CMDB ofServiceNow can be eeciently
these solutions and expand a bit on how to
used in your implementation. As stated at the
implement them with some KSFs.
beginning of this ebook, all CMDBs will share the
same characteristics but they can all have their
own specificities and variations depending on
the organizations needs. Therefore, each sub-
chapter, representing one of the area presented
above, does not pretend to describe the only
truth but implementations that proved
themselves being successful with our customers.

14
 Convention used:

This is a ServiceNow CI relationship

(These are represented as many-to-many relationships because a CI

relationship in ServiceNow is technically a many-to-many relation between
two objects)

Reference (one-to-many relation)

Optional CI relationship/reference

CMDB entities

Other entities, less important and not in scope of this document

A last note related to conventions. Instead of many-to-many or one-to-many type of relationships, we

could have used arrows but then colors should have been appliedto dierentiate them. It was chosen
in this ebook to stick with the entity type of relationships. Despite relations in ServiceNow have a label
(a type such as Depends on), it was also deliberately chosen to not add these in the following
chapters. The most important to get right is the parent and child direction. When it comes to this, the
parent entity is always above the child entity in diagrams illustrating the following chapters. The arrow in
ServiceNow will point from the child to the parent, so from bottom to top. Subsequently, the direction of
the impact analysis will be from top to bottom.

15
DATACENTER

The usual structure of a datacenter is the following:

1. A datacenter is located at a certain physical address

2. Within this datacenter, there are computer rooms

3. Within a computer room, we have racks

4. Racks houses various mount-in-rack items

such as switches, routers, serversetc.

In ServiceNow we usually have a physical location

repository. The datacenter object of the CMDB has
an attribute Location pointing at this location
master data table. Subsequently, computer rooms,
racks and mount-in-rack equipment inherit
logically the datacenter location.

The link between computer rooms and datacenter

is marked as optional because a computer room
might not necessary be part of a datacenter.
Example: a small room housing a single rack on an
oce floor is seen as a computer room in the
CMDB but it does not have a link to a datacenter.
Instead it will have a link to a location master data
record, just as a datacenter. Equipments not in
computer rooms nor datacenter are by definition
at a workplace. Therefore these are just also link
to a location master data record.

The diagram on the right represents this standard

simple approach: Simple datacenter configuration model

16
In this approach, we only consider mount-in-rack equipments. But sometimes, it is required to track in
the CMDB equipments that are not mounted in racks such as CRAC (air conditioner) or UPS
(Uninterruptible Power Supply). These 2 additional types of equipment should be implemented as
following:

CRACs are linked upstream to a computer room

UPSs are linked upstream to a computer room or a rack (for mount-in-rack UPSs)
These two types of equipment, from a physical perspective, could also be linked downstream (double
relationships). In the end, it can be summarised as following:

A CRAC provides cooling for a computer room and is located in a computer room
A UPS provides power supply to a computer room or a rack and is located in a computer room or a
rack

What matters here is the

most important dependency.
If we plan a maintenance on
a UPS, what we want to
know is the potentially
impacted applications/
services that would be down
if at the same time, we
experience a power outage.
Therefore the most
important relationship is the
one that describes to which
computer rooms/racks the
UPS provides power supply.

This concept can be

represented as shown on
the right:

Extended, with CRAC and UPS, datacenter configuration model

17
STORAGE

Storage management is technically quite complex and thus not easy to represent in a CMDB. It is
important to remember the following 2 questions:

1. What are my sources of information?

2. What do I need/can I maintain in the CMDB?

The reason is that ServiceNow, over time, has enriched the way storage can be represented. Lets have
a look at two dierent possibilities. Depending on the organisations needs, the solution might well be
in between both of them:

1. Legacy" solution using a table called Mass Storage Device"

2. "New solution" using the enriched set of table around SAN and NAS, primarily aimed at being
populated automatically by ServiceNow Discovery

Variant 1 hides the complexity behind one single object (as we will do with application). The advantage
is the simplicity of the model and the fact it will be easy to be maintained (manually). Variant 2 uses a
subset of a new set of tables, introduced from the Fuji release. It relies entirely on the out-of-the-box
model but uses only the most relevant classes. It can eventuallyallow representation of the following
concepts:

SAN Fabrics and Zoning

Storage virtualization with storage pool

SAN disks vs. volumes and LUN numbers

Storage Controller/HBA, switches and ports

18
The following diagram represents the simple variant 1:

Variant 1 storage configuration model

In the above diagram, mass storage devices should basically be NAS or SAN (eventually DAS if these
are to be considered for the CMDB, in the sense of an external drive). This means that the whole
complexity of a SAN environment is hidden behind this class. Optionally, we can also have technical
references to disks attached to each MSD if these can/should be maintained. Subsequently, this can
become more detailed with the addition of volume informationetc. Hardware equipments (primarily
servers, clusters (i.e.: ESX) and other storage devices (NAS)) will/can then consume mass storage
"devices".

Note that the storage device class is a generic class in which we can managed any kind of disk. It is
extended into the following subclasses:

Storage Device (cmdb_ci_storage_device)

| Disk (cmdb_ci_disk)
| Storage Disk (cmdb_ci_storage_disk)
| SAN Disk (cmdb_ci_san_disk)
| Fibre Channel Disk (cmdb_ci_fc_disk)
| iSCSI Disk (cmdb_ci_iscsi_disk)

19
With this solution, we have a simple and flexible model that can be easily extended (disk, volumes,
poolsetc.) or migrated to a more complex representation as described bellow. The whole complexity
of a SAN implementation is represented in one single object and it is a good solution for the phase one
of a CMDB.

Below is a full diagram of all objects that can be used in ServiceNow CMDB since the Fuji release to
represent storage. Variant 2 and 3 are based on this structure.

Out-of-the-box
storage classes
for storage in
ServiceNow

All relationships in the above diagram are technical references and many of the elements are or can be
onlyCI components (storage HBA, storage controller, storage portsetc.).

20
The model proposed by ServiceNow is very detailed and clearly aimed at auto-discovery. From that
model, we could eventually extract the following classes to represent storage in the configuration
model:

Variant 2
storage
configuration
model

In the above diagram, one additional class has been added compare to the previous diagram: Storage
File Share. This class aims at representing NAS in a infrastructure environment. Either a NAS is a
standalone appliance that has disks. Or a NAS is an appliance without disks that use SAN to store data.
Finally, with this model, we dont represent DAS (if relevant). These should be managed in the Mass
Storage Device class and should be reclassified as end user devices (DAS in the sense of an external
drive).

All this being said, the most important is to remember why and for whom we are implementing the
CMDB? What information do we need to get from it? With the complexity of storage infrastructure, if we
try to model something too complex, we risk to loose ourselves in trying to find the right level of
abstraction.

21
NETWORK

As for the previous chapter, network is not an easy one to represent in a relevant manner in the CMDB.
In opposition to storage, which is very datacenter centric, network is everywhere. Every single device
nowadays is connected to the network, thus any device can be impacted in case of an outage. In
addition to that, for whoever is not a network engineer, it is seen as a spider nest which is impossible to
manage.

This being said, for this topic we should prioritize why we tend to represent network in the CMDB:

1. Need of inventory (link with asset management)

2. Incident and problems should be logged against network devices

3. Impact analysis should be performed out of change requests

If we want to be accurate in terms of impact analysis, it will be extremely heavy in maintenance. As for
storage, auto-discovery wont be able to fully do the job so manual maintenance will be necessary.
Therefore, when it comes to network, it is important to accept a compromise in order to be able to
integrate the layer within the configuration model.

The concept is the following:

1. Any device that can connect to the network has an IP address attribute

2. Network is provided as VLAN from network equipment

3. Connection to a VLAN can be deducted automatically from its IP range and the IP address of the
device.

22
When a network equipment is under maintenance, we know which VLAN it contributes to, thus which
equipment are potentially impacted. This concept can be represented as following:

Simple network
configuration
model

If necessary, network devices can be subclassed as following (out-of-the-box):

Network Gear (cmdb_ci_netgear)

| CSU/DSU (cmdb_ci_csu_dsu_network)
| FDDI Cards (cmdb_ci_fddi_network)
| Firewall Hardware (cmdb_ci_firewall_network)
| Hub Hardware (cmdb_ci_hub_network)
| Intrusion Detection System (cmdb_ci_ids_network)
| IP Firewall (cmdb_ci_ip_firewall)
| IP Router (cmdb_ci_ip_router)
| IP Switch (cmdb_ci_ip_switch)
| Modem Hardware (cmdb_ci_modem_network)
| WAN Accelerator (cmdb_ci_wan_accel_network)
| Wireless Access Point (cmdb_ci_wap_network)

As a reminder, it is good to use subclasses when maintained attributes are dierent from a type of
device to another.

Note the optional CI relationship between end user devices and IP network. In most cases it would be
too dicult and create far to many relationship to maintain these. However, some end user devices
might be critical to a point we would like to make sure they are not missed when doing an impact
analysis.

23
COMPUTING

Computing power is the last datacenter area necessary to be able to run applications, databases,
application serversetc. A server will consume all other 3 areas already modelled, thus its position in
the above diagram:

It will be located in a datacenter or at least in a computer room

It will need to be connected to an IP network
It will consume storage (most likely in nowadays' architecture)
There are 3 dierent categories of servers we need to be able to model:

1. A standalone physical server

2. A virtual server running on a physical server

3. A virtual server running on a farm (ESX/Hyper-Vetc.)

A physical server can be represented as following:

Simple
computing
configuration
model

24
ServiceNow provides a quite extensive list of subclasses for servers. The main ones being:

Server (cmdb_ci_server)
| Windows Server (cmdb_ci_win_server)
| Linux Server (cmdb_ci_linux_server)
| UNIX Server (cmdb_ci_unix_server)
| AIX Server (cmdb_ci_aix_server)
| HPUX Server (cmdb_ci_hpux_server)
| Solaris Server (cmdb_ci_solaris_server)
| IBM Mainframe (cmdb_ci_mainframe)
| Virtualization Server (cmdb_ci_virtualization_server)
| Hyper-V Server (cmdb_ci_hyper_v_server)
| VMware vCenter Server Object (cmdb_ci_vcenter_server_obj)
| ESX Server (cmdb_ci_esx_server)
| Server Hardware (cmdb_ci_server_hardware)
| Network Appliance Hardware (cmdb_ci_net_app_server)
| Server Chassis (cmdb_ci_chassis_server)
| Storage Server (cmdb_ci_storage_server)
| CIM Server (cmdb_ci_cim_server)
| Load Balancer (cmdb_ci_lb)
|

We can notice the load balancer, chassis server and the storage server classes left on the above list on
purpose. The server class is used to manage appliances as well. Same remark than in previous chapter
here: it is good to subclass when maintained attributes are dierent from a type of server to another.
Appliances often falls into this category since these boxes have a very specific role.

For the second and third categories of servers, both virtual, there are two possible models. The first
consider a virtual server as a whole and the latter consider the virtual machine and the virtualized
server as two dierent CIs. This
seco nd option adds a bit of
complexity but allows both objects to
be maintained separately, useful
when SMEs are dierent for the
virtual machine and the image/server
deployed on top of it.

If we consider the virtual machine

and the virtual server as whole, then
we simply need a recursive CI
relationship to the server class:

Simple virtualisation computing configuration model

25
However, this type of virtual server is
not frequent. The last category of
server, virtual and running on a farm
(ESX, Hyper-Vetc.) is the most frequent
and relevant type of virtual server for
the configuration model. The following
diagram represents this concept,
including the case of a virtual machine
running directly on a physical server:

Generic classes have been used on

purpose in the diagram shown on the
right. Depending on the virtualization
technology, variations may beapplied.

VMWare vCenter/ESX:
Virtual Machine (cmdb_ci_vm)
VMware (cmdb_ci_vm_vmware)

Cluster (cmdb_ci_cluster)
VMware vCenter Cluster
(cmdb_ci_vcenter_cluster)

[Physical] Server (cmdb_ci_server)

ESX server (cmdb_ci_esx_server)
Extended virtualisation computing configuration model
Hyper-V:
Cluster (cmdb_ci_cluster) Hyper-V Cluster (cmdb_ci_hyper_v_cluster)
[Physical] Server (cmdb_ci_server) Hyper-V Server (cmdb_ci_hyper_v_server)
Note that for Hyper-V, ServiceNow does not provide out-of-the-box a specific class for virtual machines.
A custom subclass or the default class can then be used.

26
APPLICATIONS

The application layer in terms of CMDB usually consists of two main CMDB classes:

1. Application

2. Database instance

An application will need one or more servers/virtual severs to run and it will use one or more databases.
Databases, as for applications, will need one or more servers to run. This rather simple concept can be
represented as following in the CMDB:

Simple
application
configuration
model

27
With the application layer, we are just one layer
bellow services and service oerings (application
services). The basic principle will be that a
service oering or a service (this will be covered
in more details in the next chapter) will depend
on/consumes an application to be delivered to its
customers.
As for all other areas of the configuration model,
we can be a bit more specific. The above
diagram is used when we consider the
application as a whole (including the potential
application server, redundancy, components
etc.). The obvious advantage is the simplicity of
the model because this concept of applications
wont be discoverable automatically.
Lets take ServiceNow as an example to illustrate
the dierence between an application and a
software. ServiceNow is a Java web app:
Depends on a JRE (Java
Runtime Environment)
it consists simply of a record CI in a class called
Application in which we will most of the time
track basic and organizational information such a
version, the generic technology, an owner, a
support group eventuallyetc. In a way, its a
record we use to simplify the model and hides
t h e c o m p l ex i t y o f n o w a d a y s b u s i n e s s
applications behind one box in the configuration
model.
This being said, in the previous diagram, we are
dierentiating the application and the database
instance. The reason behind this is that in most
organizations, databases and applications SMEs
are very dierent. Maintaining and monitoring
databases is a job in itself. Nevertheless, we
could also make abstraction of databases and
hide them behind applications. The contrary is
valid too. The following diagram expends the
simple model presented above and present its
possible evolution:

D e p e n d s o n a To m c a t
application server

Depends on a MySQL
database

All above mentioned

components are to be
considered as software from a
CMDB standpoint. All of them
can be auto-discovered if
servers are scanned. The result
will tell that a version of Java is
running on a server as well as a
version of Tomcat and on
another server we will have a
version of MySQL installed.

An application is an abstract
concept, it does not exists as
such. In the case of ServiceNow,
Extented application configuration model
28
Two classes have been added in the above diagram. Application servers and application components.
The first can be necessary for organizations that do manage them separately (dierent SMEs) and the
latter has been added to subdivide big applications into smaller chunks.

Typical example of such an application with components is an ERP. An ERP often delivers more than
one service/service oerings and is so vast that a part of the application might be impacted by an
outage without being aected at all elsewhere. ServiceNow could be another example being a platform
that is used to provide a lot of dierent applications.Note that the application component entity is in red
because ServiceNow does not oers out-of-the-box a dedicated class to manage this concept. It is an
additional configuration that is not mandatory. ServiceNow, with Discovery or Service Mapping,
manages all kind of application components within the abstract application class or extended classes.

There is also an additional

relationship to software packages.
In some cases, it might be relevant
to have such a relationship between
the application and the specific
software package consuming it.

Expending the database area

We are only using so far a database
instance class to represent DBs in
the configuration model but this
area can also be expended if
necessary

Extended, with DB catalog, application configuration

model
29
In the diagram shown on the previous page the database catalog object is used to represent databases
running on instances. Both classes, Database Instance" and Database Catalog", are extended to cover
the various technologies organisations may use:

Database Catalog (cmdb_ci_db_catalog)

| DB2 Catalog (cmdb_ci_db_db2_catalog)
| MSFT SQL Catalog (cmdb_ci_db_mssql_catalog)
| MySQL Catalog (cmdb_ci_db_mysql_catalog)
| Oracle Catalog (cmdb_ci_db_ora_catalog)
| Sybase Catalog (cmdb_ci_db_syb_catalog)
Database Instance (cmdb_ci_db_instance)
| DB2 Instance (cmdb_ci_db_db2_instance)
| MSFT SQL Instance (cmdb_ci_db_mssql_instance)
| MySQL Instance (cmdb_ci_db_mysql_instance)
| Oracle Instance (cmdb_ci_db_ora_instance)
| Sybase Instance (cmdb_ci_db_syb_instance)
| HBase Instance (cmdb_ci_db_hbase_instance)
| MongoDB Instance (cmdb_ci_db_mongodb_instance
| PostgreSQL Instance (cmdb_ci_db_postgresql_instance)

Clustered and/or load balancedapplications

The diculty with clustered and load balanced applications is to represent them correctlyin the CMDB.
From a technical standpoint, the user of an application goes through a load balancer before
actually accessing the application. But from a CMDB and configuration model perspective, the load
balancer is not
dependent on the
application but its the
opposite. Based on
that, bellow is the
full representation that
should be used:

The diagram on the

right summarises all
possibilities. We have
twice the load balancer
entity. Once in red
which means it belongs
to the computing area
of the configuration
model and once in blue
Extended, load balancer and cluster, application configuration model
30
as it belongs to the application area. A hardware load balancer is often considered as an appliance
which subsequently is also often managed as a server with a dedicated functionality. Therefore, and
even if it was not mentioned in previous chapter, it makes more sense that these are managed as part
of the computing group. It was neither mentioned previously in this chapter, but a database instance
couldalso be clustered.

Whats important to retain here is that the cluster and the load balancer object position
themselves between the servers and the application. This is clear from a cluster point of view but
probably less when it comes to load balancers as stated earlier in this section.

In terms of classes,ServiceNow proposesout-of-the-box two additional classes to manage application

clusters that could be used.

Cluster (cmdb_ci_cluster)
| UNIX Cluster (cmdb_ci_unix_cluster)
| Windows Cluster (cmdb_ci_win_cluster)

Typically, Microsoft clusters detected by ServiceNow Discovery will be created within the Windows
Cluster class. For the configuration model, a clustered application would not be attached directly to a
serverbut to the cluster record instead.

As far as load balancers are concerned, theycan be both application or hardware. The following two
sets of classes are proposed out-of-the-box by ServiceNow. The first inherits from class Load Balancer
which houses hardware LBs (the class itself inherits from Server), the later inherits from class Load
Balancer Application (which itself inherits from Application). Note that an application load balancer
would need to be running on a server.

31
 Hardware LBs
Server (cmdb_ci_server)
|LoadBalancer(cmdb_ci_lb)
|A10LoadBalancer(cmdb_ci_lb_a10)
|ACE(cmdb_ci_lb_ace)
|Alteon(cmdb_ci_lb_alteon)
|CiscoCSM(cmdb_ci_lb_cisco_csm)
|CiscoCSS(cmdb_ci_lb_cisco_css)
|CitrixNetscaler(cmdb_ci_lb_netscaler)
|F5BIG-IP(cmdb_ci_lb_bigip)
|F5BigIPGTM(cmdb_ci_lb_f5_gtm)
|F5BigIPLTM(cmdb_ci_lb_f5_ltm)
|ISAServer(cmdb_ci_lb_isa)
|NetworkLoadBalancer(cmdb_ci_lb_network)
|RadwareLoadBalancer(cmdb_ci_lb_radware)

Application LBs:
Application (cmdb_ci_appl)
| Load Balancer Application (cmdb_ci_lb_appl)
| HAProxy Load Balancer (cmdb_ci_lb_haproxy)
| Modjk Load Balancer (cmdb_ci_lb_modjk)
| ModProxy Load Balancer (cmdb_ci_lb_modproxy)
| Nginx Load Balancer (cmdb_ci_lb_nginx)

Environments?
To complete this chapter, when we talk about applications, we have to talk about environments. Most
likely an application used for production will have at least one non-production environment. Normally it
should also be represented in the CMDB as the hardware running non-production environment also
need to be inventoried and managed. The more complex the application area of the configuration
model becomes, the more dicult it will be to represent application environments.

1. Each application, application component and database instance are duplicated for each
environment. Thus that can allow tohave prod and non-prod services/service oerings depending
on them.

2. We only consider one application for all environments. The notion of environment becomes an
attribute of the CI instead. All thehardware related to non-prod environments is still managed and
the same application CI record will be related to it in addition to the one supporting the production
system.

This question is further discussed in chapter 3.3.2.

32
END USERS

End user devices can mess up quickly with the configuration model. First of all, we consider end user
devices, all sort of equipment directly assigned to a user or that users use directly:

Workstations
Tablets
Smartphones
Barecode scanners
Printers (even networked)
Peripherals (screen, directly attached scanneretc.)
etc.
As stated in the section related to modelling the network, end user devices are almost all connected
and thus potentially dependent on a lot of things. It is important to focus on the reasons for having end
user devices in the CMDB:

1. These are the mass of assets an organization often wants to know about

2. These most likely wont be used in change management. They are very incident centric kind of
CIs.

CI relationships are useful in incident management, for the root cause analysis, but not as critical as for
change management. All this to say, that the focus should not be on CI relationships when
implementing end user devices in a configuration model unless the organization has a specific need.
They would be very dicult to maintain and could not be accurate automatically (auto-discovery).

33
When a user logs an incident because something is wrong, the root cause can be:

Issue description Possible root cause Impact

A software is not working 1 Workstation 1 user impacted

properly

The hardware has a 1 Workstation 1 user impacted

problem

An application is not 1 Network Multiple user impacted

working properly 2 SAN
3 Server
4 etc.

What we see in the above table is

that the barrier is very clear. Either
the terminal has an issue and its the
only root cause. Or it is related to a
deeper issue because a shared
resource is misbehaving. The root
cause can then be a lot of things,
related to an application or
infrastructure. In the reality there will
be lots of other not so clear cases but
for sure will not account for the
majority. In addition to that, a
dependancy rarely exists between
the workstation and applications/the
infrastructure but between a user and
the applications she/he is granted
access to and the underlying
infrastructure.

The diagram for such a concept is

then very simple (see right): all end
user devices apart from printers are
orphans. They are not directly linked
to a service/service oering and they End user devices configuration model

34
dont rely on other application/infrastructure CIs. Printers though can have a relationship to a server
(networked printers) and subsequently be linked to a service/service oering (printing service).

Software packages are usually also just considered as a component of a workstation but can be
optionally linked to the application the software is consuming (for instance, the ERP client will consume
the ERP application).

Finally, most of the technical references are optional. Lots of organization do have a source such as
SCCM or LANDesk to maintain up-to-date computers, disks, software and network adapters attributes
and in that case, most of the above technical references are also maintained accurately and
automatically. In the case of an organization that cannot leverage on such an integration, it will be
dicult to maintain automatically because of the number of CIs. End user devices will be by definition
the most CIs that will populate the CMDB.

35
SERVICES

The service layer in the CMDB is the top-most layer. Lets look back at an ITIL definition:

"Services are a means of delivering value to customers by facilitating outcomes customers want to
achieve without the ownership of specific costs and risks."

In other words, the IT department of an organisation provides (sells) services to other organisations
departments (customers). The IT department has the ownership of costs and risks (and the technical
means) and on the other side, customers wants results (they want the service they pay for to perform
well). Lets look at a practical example: Finance wants a solution to be able to manage the organisations
finance:

A. The organisations IT dept run and support an ERP at a certain price.

B. The organisations IT dept is responsible for making that solution available and reliable enough.
By making use of internal or external resources (CIs and/or other services).

C. The organisations IT dept should be capable of monitoring the performance of such a service
(primarily support and availability)

Remember that configuration management and the CMDBs primary goal is to support service
management processes. Organizing CIs under services goes towards that goal.

Incidents have an impacted service (as reported by the user consumer of the service) but also a faulty
CI (found out during the root cause analysis). At the same time, a change request might be ongoing.
This RFC can potentially require some CIs to be shut down, thus generating full or partial outages. This
might be the cause of the issue the user has previously reported. With services linked to supporting
application and infrastructure CIs, this information can be easily spotted. In addition to that, the incident

36
and the outage generated by the change request can then be easily rolled up to the service and used
to measure its performances.

In this layer, we have the following primary CMDB classes at our disposal:

Business Service

Service Oering

The Service Oering class will exist only after activating the plugin Service Portfolio Management. It
intends to manage location variation or dierent flavour of a service for their respective users. Service
ABC in Zrich might not have the same contractual commitments than the same service but in London.
Or the gold version of that service will have more aggressive commitments than the silver or
bronze version of that same service. Without going too much in details, this additional plugin will allow
the configuration of such service flavours and provides solutions to monitor support and availability
results on a per service oering basis. It is a good practice to start with this concept, even if the maturity
level does not allow a pure definition of service oerings with dierent commitments. The rest of this
chapter will then consider the service oering table is available in the system.

A good practice with the Business Service class is to relabel it into just Service. Indeed, not every
service is business-oriented. Generally, we can split the list of services in three categories:

A business service is a service that directly supports the core business of the
Business company. It is generally provided by a specific application necessary to run the
business.

A supporting service is a service that everyone or almost everyone gets to help

accomplish their day-to-day tasks but that does not directly support the core
Supporting business of the company. Such service can be messaging. The email facilitate
the exchange of info and can be critical but is not what the company makes
money o.

An infrastructure service is provided, as its name indicates, by the backend

Infrastructure
infrastructure. Such service can be the network or storage.

37
This being said, the service layout can be represented as following:

Standard service and service offering configuration model

Most business services will be supported by applications but services in general can be supported by
any type of CIs (network, storage, computing, applications or even end-user CIs). When the service
oering class is available and is used, it musts be the component linked to the underlying application
and infrastructure CIs. A service oering can also leverage on other service oerings from supporting or
infrastructure services (some of these relationships are implicit, like the network necessary to make
almost everything work). Finally, at the end of the chain, we have users, departments, companies, or
locations subscribing to "service flavours. This subscription concept in ServiceNow simply defines
who is consuming the service in the organization, thus defining to whom their contractual commitments
apply.

38
PITFALLS
Lets look back at the four questions listed in
chapter 2.1.1:
What classes of CI do I need?
What sources do I have for these classes?
Which attributes do I need for these classes?
How are these classes relating to each other?
Pitfalls are obviously when the CMDB
implementation project failed to answer these
questions correctly. there are basically three
dimensions to put in perspective:
1. The maturity of the organisation
2. How much is known about CIs (available
sources)
3. What is expected from the CMDB
The target is to find the right balance between
objectives, maturity and data sources
(1) Maturity + Objectives
The objectives given to the CMDB are well-
balanced with the maturity of the organization. It
means the focus is right compare to how the
CMDB will be used. No unnecessary classes,
attributes or relationships should be maintained.
But without carefully taking into account what we
k n o w a b o u t C I c l a s s e s d e fin e d i n t h e
configuration model, the following situations
might be encountered:
We dont leverage on a potential integration.
Users will be asked to maintain something
manually that is already done elsewhere and
potentially automatically. The CMDB will be
perceived as inecient and giving overhead
work to users.
We miss an opportunity to replace an
ineective tool by a CMDB integrated with all
gravitating processes. There are lots of cases
where an inventory is simply maintained in an
Excel spreadsheet. Putting in place a
ServiceNow CMDB is a perfect opportunity to
replaces the un-collaborative solutions. Again,
the CMDB will be seen as inecient and
giving overhead work (job done potentially
twice).
(2) Maturity + Sources
Compare to the first case, we have perfectly
looked at what is known about the organizations
applications, infrastructure and end user devices.
Old inecient Excel spreadsheets are replaced
and integrations are put in place. But without
focusing on objectives, we might end up with a
39
very good and eective CMDB but that does not
answer current organizations pain points.
The user will be given a Porsche whereas he
would need seating capacity or a truck
whereas speed matters. The perception will
be that the tool does not eciently help him in
his day-to-day tasks and will still need
additional tools.
(3) Objectives + Sources
As for the second case, we will have here a very
good CMDB, focused on objectives, with
integrations when these could be done and
replacing old ineective solutions to make sure
users will not need to do the job twice. We
carefully paid attention that the CMDB will be
perceived as an eective solution. But without
taking into account the maturity, we have basically
forgot users who will primarily use the CMDB!
Either we nailed it and the CMDB is perfectly
maintained automatically. The solution just
tells the truth about any CI we are tracking at
any time. However this is rarely the case or
the scope is very narrow. With such a CMDB,
the user will be given hands on something that
exceeds its competences.
We are most likely covering too much
compare to the available resources. The goal
of the configuration model is to have
something consistent across all its areas. By
covering too much compare to what we can,
we will end up with poorly maintained classes
and relationships thus loosing the
eectiveness of the CMDB.
The right balance between objectives, maturity
and well leveraging on available sources of
information is key to successfully implement a
CMDB in ServiceNow. This is valid for a phase 1
but also for following iterations. Five key success
factors
1. Always start small and expend later
2. Always think about users and train them
when necessary
3. The Return On User Investment should be
positive. The CMDB should help users.
4. Spend time to do some conceptual work, its
important to start small but also to start right.
5. Think twice when customization is needed,
the out-of-the-box ServiceNow CMDB is
already vast and often has the answer to a
question.
To conclude, I would add that if what is being
done is too far from the standard, we should
question ourselves whether we are doing the
right thing. ServiceNow is no stranger to the ITSM
business and they are just embedding in their
platform best practices.
40
 INTEGRATION WITH CMDBS/MDRS
As mentioned at the beginning of this chapter, a
key question to answer is What sources do I have
at my disposal to help me populate/maintain the
CMDB?. The maintenance process will be
covered in details in chapter 4 but when
implementing a CMDB, there are great chances
that a management tool, containing valuable
information for the CMDB, exist somewhere:
MDR (Managed Data Repository)
Or another CMDB, external to ServiceNow
Beside ServiceNow, these solutions will continue
to live and are potentially automated themselves
(thus ensuring high quality data) and it would be a
pity not to leverage on them to help maintain data
in ServiceNow.
When multiple data sources overlap, it is important to define SSOT and put in place reconciliation rules
In addition to that, ServiceNow proposes their
own solutions to help with the maintenance
process:
ServiceNow Discovery
ServiceNow Service Mapping (previously
Nebula)
Both of theses solutions will be introduced in
more details in the next chapters.
The first challenge that will be faced when
integrating ServiceNow CMDB in an organization
that has multiple CMDBs or MDRs will be dealing
with the overlap of two sources and the
reconciliation of data. The following diagram
represents a potential situation:
41
In this use case, we can see that multiple sources overlap. The network source with Discovery, SCCM
with Discoveryetc. The concept is that for each classes, a SSOT should be defined (Single Source Of
Truth). Some classes will be manually maintained and therefore their SSOT is manual inputs. Some
others will get most of configuration information from a MDR and therefore, if agreed and decided so, it
becomes the SSOT. When we have an overlap, there must be a source that takes precedence over the
other(s). A matrix similar to the following one should be defined and documented:

Example:

Class Computer (cmdb_ci_server)

Sources are SCCM and Discovery

Source Order Action Attributes

SCCM 100 Create/Update All

Discovery 200 Create/Update All

In the above example we consider SCCM being the SSOT as it has the smallest order. We also consider
it can create and update records but we dont specifically list attributes it has ownership on. Discovery
has the exact same setup but a highest order because it is not considered, for this class to be the SSOT
or the most accurate source.

The second challenge will be about reconciliation. Now that there are 2 sources and that the SSOT is
defined. How does each source recognize if a CI has to be inserted of if the CI exists already and has to
be updated? For hardware CI, usually the serial number is used as it is known to be pretty unique
worldwide. Nevertheless, depending on the source, other attributes may need to be used such as the
MAC address, an IP address or the hostname. Each of these attribute may be formatted slightly
dierently from a source to another (especially the MAC address) and it needs to be addressed
somehow. Until the Geneva release of ServiceNow, there was no real magic tool for this and each data
source needed to be configured with a transform map in which the reconciliation rule needed to be
configured/scripted.

42
Starting from the Geneva release, ServiceNow has introduced a new CI Reconciliation/Identification
engine (to not confuse with the old Discovery CI identification engine) that applies the above theoretical
concepts and will greatly help dealing with multiple CMDB sources. The procedure is the following:

1. Document data source precedences for each classes in scope

2. Document reconciliation definitions (which source can update what attributes)

3. Review and eventually adapt CI identifiers

CI identifiers are a set of rules, evaluated in a certain order, that tells the system how to identify a CI.
Hardware devices will usually be identified trying the correlation ID first, if not found it will try the serial
number and then other attributes like the hostname or IP and MAC address.

43
SERVICENOW DISCOVERY
ServiceNow Discovery is an agent-less solution
that will scan your network on regular basis for
any kind of connected device. It works in a 4-
steps process:
1. Shazzam: scan the network and discover
connected devices
2. Classification: try to define what kind of
device has responded following pre-defined
pattern (i.e.: if the device responds to WMI
queries, it must be a windows machineetc.)
and gather information about the device.
3. Identification: reconcile the device and
gathered information with an existing CI in
the CMDB.
4. Explore: get more information about the
device such as running processes if
applicable or some deeper information on
the device itself.
ServiceNow being a SaaS solution, in order to be
able to discover devices/equipments, the solution
relies on what is called a MID server, which is a
small Java program running on a server within
customers network and capable of executing
various kind of jobs.
I would call this approach "bottom-up or
horizontal discovery (as ServiceNow would call
it).
The biggest advantage of the solution is that it is
already pre-configured to be capable of
discovering most devices an organization would
be interested in having in its CMDB. In addition to
that, it is agentless and therefore does not require
any intervention on devices prior to being able to
populate ServiceNow. The main challenge will be
the broadness of the out-of-the-box scope of
probes. If you plug and play, the result might be
more useless than useful due to the huge amount
of information it will bring back to your
S e r v i c e N o w i n s t a n c e . H o w e v e r, w e l l
implemented, the solution is very powerful. Some
key success factors:
1. PLAN PLAN PLAN
ServiceNow Discovery should not be the solution
that will magically do the job people had to do
prior to its implementation. It is not the solution
that will make the organization discover magically
devices they own. Its a solution to support users
in the configuration management process but not
replacing them. Before anything, study the
network topology of the organization. The primary
reason for this is to plan how many of those MID
servers will be needed. These should be
deployed strategically within the organizations
network to ensure that the scanning will be
complete. It is a common mistake to not plan this
accurately and thus ending up with partial
44
discovery with MID servers not able to see CMDB is used across a whole bunch of
everything they should. processes, primarily incident, problem and
change management), it is hard to do a U-turn if
2.PRIORITIZE six months down the road, we realize we did not
do it right. It is then best to start small and simple.
Define whats most important and key. On a Take the time to validate the result. And finally,
network, there could be lots of dierent kind of continue with multiple phases to expand its usage
devices. Not all of them are relevant in a CMDB based on priorities.
and more specifically, not all of them relevant
within a network range/subnet. When Discovery 4.DONT UNDERESTIMATE
has to scan a certain IP range within a datacenter,
what are the most relevant devices Discovery has THE DESIGN PHASE
to see? Probably servers, routers, switchesetc. In
In a CMDB project, designing is key. For Discovery
order to put in practice this priorization, key
it is the same. For each phases of the project, no
functionalities with Discovery are behaviours,
aspects of the implementation should be
credentials and functionalities. On a per phase
neglected. Implementing the solution can be
and MID server basis, it can be controlled what
dicult and challenging in some organizations
accesses are granted and what protocols should
environment. Implementing Discovery requires
be used in order to make sure we keep control on
talking to many dierent SMEs within the
the scope of the scan. In addition to that, the
organization who all have dierent requirements
configuration console is easy to use to control
which can be constraints for the project.It is also
what main discovery functionalities are enabled or
good to manage well in advance expectations.
disabled.
Security aspects of the solution should be discuss
at early stage to make sure everyone is aligned.
3.START SMALL AND
SIMPLE AND EXPAND
LATER
This is repeated many times when implementing
ServiceNow. One of the main reason for this is
that it is easy to do something with ServiceNow in
comparison with other tools where careful design
an planning need to be done. It is too easy to go
too fast and put into production something not fit
for use or purpose. With ServiceNow Discovery,
because data it creates has great visibility (the

45
 As for Discovery, Service Mapping is an agent-less solution that
SERVICENOW shares and uses the same technologies. Initially, this solution was
SERVICE called Neebula and was acquired by ServiceNow back in 2014. With
MAPPING the Geneva release of ServiceNow, it is fully integrated within the
platform. As stated in the previous chapter, Discovery has an
horizontal or bottom-up type of discovery approach. Service Mapping
is top-down.

Horizontal discovery vs. top-down approach

You basically give Service Mapping an entry point: URL or IP address

of an application. The solution will do the rest. It will scan the host if
necessary and then explore it and try to understand what kind of
application it is. This is done using a set of pre-configured pattern
(out-of-the-box, but new ones can be created). If a pattern match, it
will create the CI in ServiceNow and act accordingly. In Service
Mapping there are two distinct phases:

1. Identification of the application

2. Connectivity discovery

46
Lets take a practical example: the application is a Java EE program running on a JBoss web server and
using an Oracle database:

1. The application is identified according to the pattern and explored (a CI is created in ServiceNow
with the corresponding attributes).

2. Service Mapping will look at possible connectivity and try to find a match. It will discover a
matching connection with an Oracle database and a JBoss web server.

3. Service Mapping now has two entry points to explore against patterns and try to identify the
Oracle database and the JBoss web server.

4. And the process goes on recursively until no connections are found anymore.

How does that fit into our CMDB?

What Service Mapping is doing very well is creating a map of an application with technical
dependencies. Technical dependencies, to be accurate, also means going down to a very granular
view. This might not fit into a configuration model, where for instance, we focus on the application as a
whole (the application, the application server and all potential small elementsetc.). The level of details
Service Mapping is bringing to ServiceNow is just too high if it had to be maintained manually.But there
is no magic behind Service Mapping. The tool does not have the judgement of a human being and
capable of simplifying a hierarchy of elements. It just does what we tell it to do. We could modify its
behaviour by heavily customizing all the out-of-the-box patterns but we would be loosing on its added
value and, above everything, that would not be a good practice.

The answer is that the audience or the usage of the information Service Mapping is bringing to
ServiceNow is slightly dierent than the rest of the CMDB. The big plus of Service Mapping is its usage
in conjunction with an event management integration. The dependency map is displayed with a timeline
and because it is refreshed on regular basis, allows the user to go back in time to check the state of the
application or see what has changed. Events are displayed in this timeline.

KSFs listed for Discovery are also valid in the context of Service Mapping:

1. Plan plan plan: technologies are the same, MID servers need to be at the right place as well.

2. Prioritize and start small:focus first on the most important/critical applications (3 or 5 to start with
I would say).

47
 3. Dont underestimate design: to make sure a pattern works,
you need to understand how the application works and
where Service Mapping should look for information on
connectivity and so on. This can be complexe.

To conclude this chapter on Service Mapping, I would add that

multiple levels of granularity can cohabit in the CMDB. ServiceNow
Discovery will do an horizontal/bottom-up discovery but in some
aspects, results of scan might not perfectly fit into the
configuration model. Nevertheless, it can be very good at detailing
some areas where it is useful for some SMEs to have more than a
simplistic view (such as the VMWare ESX environment which is
very detailed using Discovery). Service Mapping, on its side, will
provide a very detailed and accurate view of how an application,
and subsequently a business service, is delivered to its customers.

Even though not trivial to setup, it is feasible to have mulitple abstraction levels in the CMDB

In the above figure, the level of information about the ESX

environment might not be useful to everyone. The main elements
can be integrated into the standard configuration model view
without caring about all the details. The same applies with the
application ABC. This can be achieved when configuring the BSM
map which is presented further in this ebook.

48
3

PROCESSES
Once the CMDB is in place, it should not be Asset management
static. The content of the CMDB needs to be
Change management can be a proactive
maintained or updated and for some areas, as
or reactive process. In the latter, a change
much as on a daily basis. For that we need
request will occur following an issue (incident/
processes. Modification/maintenance of the
problem). A change request can aect one or
CMDB may occur in various contexts but the
more configuration item(s) and subsequently
three main processes that will take care of your
impact one or more service oering(s). The
data in the CMDB are:
change request needs to be approve by all
Change management people it concerns (thus the reason for having
good data in your CMDB because that will be the
Configuration management source to define these people) and once it is

49
completed, the CMDB needs to reflect what the objective of configuration management is to
change request was all about. ensure we manage and perform actions within its
scope correctly. In other words, that when we
Configuration management is the process that is
update a CI, we dont miss attributes, we dont
called when a change request is completed and
miss relationsetc. and that periodically we try to
the CMDB needs to be updated. Thats for the
re-align its content based on the reality. I like to
reactive part of the process. The other part of the
compare it to an Inertial Navigation System (INS).
process is mostly proactive where periodic review
The system knows where is the vehicle based on
of the CMDB are performed. The objective is to
how it is moving but from time to time, we need to
ensure data matches the reality. If it does not
realign it with the reality and re-position the
match the reality, it has to be referred to change
system at the correct coordinates. For
management (either something was implemented/
configuration management, the movements are
installed without change request or the CMDBwas
change requests and on regular basis we go have
not updated properly following a change request).
a look at our datacenters and re-align the CMDB
What we see is that both processes are very to the reality.
much imbricated. As for all processes, the

CMDB
maintenance
process

50
CMDB audit
and verification
process

Note that in the above process flow, we are only
talking about update. The reason for this is that
configuration management is only about CIs that
exist already (at least in an ideal situation). When a
technician installs a new switch or install a new
workstation, the device is not new but exists
already in a stockroom. If it does not, then the
device needs to be purchased and that part is not
part of configuration management but request
fulfilment and asset management. This process is
presented in the introduction and in the next
chapter, it will be explained where the border lies
between the two process, again, at least in the
ideal situation or in theory.
stakeholders means that both sides can evolve at
a dierent pace and have a dierent level of
maturity which is often what is witnessed. Often
configuration management, traditional and a base
ITIL process, is more mature than IT asset
management (ITAM). Therefore we, in practice,
often put in place solutions that permit asset
management process actions within the perimeter
of the CMDB and configuration management such
as the creation or the retiring of CIs. By retiring,
we mean the elimination of the device and not
putting it back in stock.

In practice, because we have two processes, most

of the time we are talking to dierent stakeholders
(in small organization there could be overlap
between roles and responsibilities). Dierent

51
ROLES AND RESPONSIBILITIES
Previously, three processes
were introduced, bellow is
basically how they interact
with each other:

Asset, configuration and change management interactions

52
Role Process Description and responsibilities*:

SA Change (CM), Support Agent and

problem (PM) and
incident (IM) (IM) Performing investigation and diagnosis
Management (IM)Determining if change management is required to
resolve an incident
(PM) Investigating and diagnosing root causes
(PM) Investigating and diagnosing workarounds
(PM) Investigating and proposing permanent solution(s)
(CM) Developing specifications, design, and/or architecture
(CM) Performing risk and impact assessments
(CM) Building, testing, and deploying changes
(CM) Executing rollback plans

The support agent will be using the CMDB within incident and
problem management when mainly investigations are needed. Within
change management, she/he will be using the CMDB for risk and
impact analysis and documentations. At the end, she/he will be
assigning the change task to the configuration administrator (CA)
when update or maintenance is required in the CMDB.

CC Change Change Coordinator:

Management
Assigning change tasks considering support agents' skills and
availability
Assigning change tasks requiring configuration management to
configuration administrator
Informing about scheduled changes and availability impact and
outage duration

As its name indicates it, the change coordinator coordinates a change

request. She/he is assigning change tasks to support agents and/or
configuration administrator (as well). She/he is responsible for the
communication about and impact on availability and/or outage
duration.

53
Role Process Description and responsibilities*:

PO Configuration Process Owner:

Management
Defining the purpose, objectives, scope, as well as principles and
CSFs of the process
Designing and sponsoring the process throughout the organization
and stakeholders
Ensuring selected process indicators are collected, analyzed, and
acted upon
Driving the eciency and eectiveness of the process ensuring it
is fit for purpose
Initiating improvement activities considering people, process, and/or
supporting tools

The process owner owns the process, meaning she/he is the ultimate
responsible for its performance and objectives and has the authority to
change it.

CA Configuration Configuration Administrator:

Management
Reviewing, acting upon, and closing CMDB maintenance requests
Coordinating CMDB maintenance activities
Updating CI records
Ensuring CI information adequately indicate how it is used to support
service delivery (relations)

The configuration admin is the person that has the right to perform actions
on the CMDB. This is a role that exist as such in ServiceNow has it gives a
write access to the CMDB.

CfM Configuration Configuration Manager:

Management
Managing the process operationally
Performing periodic verification and audit
Identifying deviations between actual and expected configuration
data
Determining how deviations between actual and expected
configuration data will be reconciled through change management
Ensuring identified deviations are reconciled in a timely fashion
Identifying unauthorized CMDB maintenance
Ensuring selected indicators are collected, analysed, and acted upon
Driving CMDB maintenance improvement activities

The configuration manager runs the process operationally. This means

running the audit and verification process, keeping an eye on
unauthorised changes and ensuring data is up-to-data and driving the
CMDB maintenance. 54
 Role Process Description and responsibilities*:

AM IT Asset Asset Manager:

Management
Implements the organizations service Asset Management policy
and standards.
Agrees scope of the Asset Management processes, function, the
items that are to be controlled, and the information that is to be
recorded.
Develops Asset Management standards, Asset Management plans
and procedures .
Manages the Asset Management plan, principles and processes
and their implementation .
Provides reports, including management reports (indicating
suggested action to deal with current or foreseen shortcomings),
impact analysis reports and asset status reports
Initiates actions needed to secure funds to enhance the
infrastructure and stang levels in order to cope with growth and
change

Those are the main responsibilities defined in ITIL. In essence, the asset
manager runs the asset management process operationally as would its
counterpart the configuration manager.

* Responsibilities within the perimeter of configuration management. Non-configuration management

roles have, of course, other responsibilities than what is listed here.

55
ASSETS AND CI LIFECYCLE
It is good to start by dierentiating two big
categories of elements:
1. Abstract or virtual elements in the CMDB
such as softwares, applications, virtual
machinesetc.
2. Concrete or hardware elements in the CMDB
such as physical workstations, physical
servers, network appliancesetc.
Abstract or virtual elements are much more
versatile than concrete or hardware elements.
The first can appears or disappear very quickly
following mainly change requests whereas the
latter will go through, normally, a proper
purchasing process and start their lifecycle as
being in a stockroom.
Lifecycle of abstract/virtual assets is much shorter than for physical assets
The border between what should be done as part
of the asset management process and what is
done as part of the config./change management
process is not always clear. But in essence, the
below diagram basically depicts where the
lifecycle of the two categories of elements
introduced earlier are managed.
For physical or hardware elements, the lifecycle
starts in asset management. When one of these
element is installed or in use, the lifecycle
continues within the CMDB (configuration
management or change management process). In
the end, physical elements eventually finish their
lifecycle ending up in a stockroom, awaiting to be
scraped or sold.
56
 For abstract/virtual elements, basically, everything is done as part of the
config./change management process, from the installation to the
retirement stage.

A CI/asset could also be represented as a coin. With one face being the asset side and the other
one the CI side

Lets briefly look back at two dierent roles when it comes to physical/
hardware elements: the Asset Manager and the CMDB admin. The first
will care about the element until it is unpack from its box. What matters is
really financial aspects of the element. The latter do not care about the
financial aspect but how the element will interact with the environment
he is responsible for from the time the element is unpack from its box
and plugged. The only financial aspect of a virtual or abstract element is
the software license, and it is the only aspect managed as part of the
asset management process for this category of elements.

In order to manage this lifecycle, ServiceNow has out-of-the-box a set of

install or hardware status in the CMDB and a set of install status and sub-
status on the asset management side. As depicted in the above
illustration, we are talking about an asset or CI depending on the angle at
which we are looking at the element, but it is the same thing. In
ServiceNow, asset information is not maintained in the CMDB anymore
but in dedicated tables. Therefore there is a seamless synchronization of
some shared attributes, among them, the status.

57
 1. Managing the lifecycle of a CI and presentation of the out-of-
USE CASES the-box ServiceNow approach

2. Managing multiple environments and presentation of an

approach

The first use case has been selected for this ebook because
organizations understand the importance of the configuration
model but tend to forget that once CIs are populated in the CMDB,
they have to be managed. And managing CIs also means properly
following ITIL processes (change and configuration) because not
everything can be done automatically with Discovery solutions. A
discovery solution will be able to tell you if something is on the
network or not but do not tell you what you have in stock and
more importantly, does not tell you why a CI has suddenly
appeared or disappeared in the CMDB.

The second use case is about environments around the

application and service layers. Sometimes it is not clear whether
non-production environments should be tracked in the CMDB and
how to position the border between what is considered as
production and what is not. This use case tries to answer these
points and proposes an approach.

58
HOW DO I MANAGE THE LIFECYCLE OF A CI
This question was probably partially answered in chapter 3.2. In ServiceNow, to keep it simple, in the
context of this ebook, we have two dierent applications: one for the CMDB and one for Asset
Management. This because we essentially have two dierent roles: the Asset Manager and the
Configuration Manager. But both applications are using and impacting the same data (again, to keep it
simple and make abstraction of the database complexity of ServiceNow) So the question is who does
what and when?

What we often witness at organizations is a gap between real processes in place (even if not
formalized) and what an asset or configuration manager has to or can do in ServiceNow. In all
companies, before a hardware device of any kind physically exists, it has to go through some kind of
purchasing process. And this is the trigger for the introduction of new hardware/consumable assets/
configuration items in the ServiceNow database. For software licenses, which are also assets, this is
also valid but they do not have one-to-one counterpart in the CMDB (the closer we get is the software
instance). Though managing software licenses is a process in itself thus we will not take this into
account here nor expand on this topic.

Here is a table of the activities around the lifecycle of a hardware asset/configuration item:

# Activity Process Involved ServiceNow Outcome

Module

1 Purchase of a Purchasing Asset A new asset record is created

new hardware Management in the system. The asset
device record has also a CI
counterpart that has been
created. Both have the status
On order

2 The new Purchasing Asset The received package is

hardware device (goods Management checked, the serial number
is received receipting) and the asset tag are
scanned to link them to the
asset. Asset record in
ServiceNow is updated with
status In stock and CI
record also inherits the serial
number/asset tag

59
# Activity Process Involved ServiceNow Outcome
Module

3 The new Stock Change The device is probably

hardware device management Management transferred for installation.
is transferred to (transfer order) => Asset Therefore the origin of the
another local with inputs from Management request is probably a change
stockroom change request. The little transfer
management order process will update the
asset record status to In
transit when is on the move
and then back to In stock
when it has arrived. CI record
also inherits the status.

4 The new Change Change The asset is taken out of

hardware device Management Management stock and set with status
is installed => Asset Pending install. The
Management corresponding CI is picked as
=> CMDB the aected CI in the change
record. The CI is also updated
with some configuration
related information (such as
the support group, owner
etc.). In the end the status is
also updated to respectively
In use/Installed

5 The hardware Change Change The maintenance on a CI

device is under Management Management should theoretically be
maintenance => CMDB undertaken as part of a
=> Outage change (as long as it means
Management something has to be changed
on the device). Status is set to
In Maintenance. Eventually
a planned outage should be
logged.

60
 # Activity Process Involved ServiceNow Outcome
Module

6 The hardware Configuration CMDB The CMDB should be audited

device is audited Management => Change on regular basis to ensure
Management compliance, correctness and
completeness. The CI status
may be changed if change
management is required to
correct something. Other
attributes may be updated as
well.

7 The hardware Change Change The device removal should

device should be Management Management be done as part of a change,
uninstalled => Asset as for the previous active an
Management outage may be logged if
applicable. The status of the
asset is set back to In stock
which is reflected in the CI.
Some additional information
may be removed

8 The hardware Asset Asset The asset is updated with the

device reaches Management with Management corresponding Retired
end-of-life inputs from status:
support and will contract Donated
retired management Sold
Disposed

This table does not cover all activities but probably the most common. The important part to retain here
is that at each stage of the lifecycle of an asset/CI, there is/are process(es) to take care of it. The above
table cover the principle activities that should be looked at from a process standpoint when
implementing a CMDB:

1. Purchasing

2. Goods receipting

3. Change management and IMACD

a. Install

b. Move

61
 c. Add

d. Change

e. Decommission

4. Stock management (including transfer between stockroom and to/from installation sites)

5. CMDB audit for compliance, correctness and completeness

6. Decommissioning

For each of them, it should be identified how it is done and where. Typically the purchasing process is
often not done directly in ServiceNow but in an ERP. Therefore it should be identified how we get data
in ServiceNow from this process.Ideally a process should be formalized but it is most likely not going to
be the case as part of the CMDB implementation.

HOW DO I MANAGE MY DIFFERENT ENVIRONMENTS

Essentially all configuration items should be in the CMDB independently whether they are supporting a
production system or a DEV/TEST/QA environment. Some of these CIs will also most likely be used by
multiple environments at the end of the chain. Furthermore, they have a cost and need to be managed
somehow, that would usually justify the fact we need to track them. How do we manage this?

Generally, when we talk about environments, we are referring to a non-production instance of an

application. In this case, an environment in the CMDB will in the end be modelled as a dedicated
application and service or service flavour (service oering).

In the case of ServiceNow, customers get multiple instances to manage at least a development and a
production environment. The development environment is supported by dedicated hardware and does
not have the same contractual commitments than the production environment in terms of SLAs or
availability.The result of this is that we would have in the CMDB either 2 dierent services or, and most
likely, one service with 2 dierent oerings, one for DEV and one for PROD (see bellow illustration).

It is also important to be aware of the following dierentiation to be made:

1. Configuration items supporting a specific environment

2. Configuration items supporting a production service used by a non-production environment

The second point might be hard to understand. In many organisations, roles and responsibilities are not
siloed but defined in layers. For example, you might have, a service responsible for the virtualization.
When you need computing power to deploy a sandbox or development environment of an application,

62
you request VMs to that service. The service is responsible to ensure VMs are running smoothly but is
not accountable for anything deployed on them. More importantly, the VM is provided by a production
service but supporting a non-production one. The proposed configuration model covered in previous
chapters perfectly handles these cases. Bellow is an example how dierent environments could be
modelled in ServiceNow:

Prod vs. non-

prod
environment
representation
in ServiceNow

This is of course not the unique way to manage environments but one solution that fitted well with
many organisations. Essentially, the following should be retained:

1. Environments should be managed at the service, service oering and/or application level but not
bellow.

2. Bellow the application level, a CI may be incorporated in a chain of hardware impacting more than
one environment. If this information is needed a this level, it can be calculated based on its links
with supporting applications/services.

63
4
NOW CMDB AND
ASSET
FUNCTIONALITIES
Besides the theory of the why we implement the
CMDB in certain manners, there is also the tool.
This section lists the most important features of the
ServiceNow platform that leverage on a correctly
structured CMDB.
 As we saw in the chapter dedicated to processes,
CMDB HEALTH configuration management is essentially a reactive process
with request for maintenance coming from change
management and proactive checks with regular audits
performed on the data hosted in the CMDB. The reactive part
of the process is pretty clear but it is less about the proactive
part of the process. How do we perform regular audits and
verifications in the ServiceNow CMDB?

This chapter has been named CMDB Health but it is not one
single feature of ServiceNow but more an umbrella name
under which we have the following functionalities:

1. The CI Class Manager: it is essentially a configuration

panel consolidating dierent new and existing
functionalities as well as giving shortcuts to system
properties and data dictionary.

2. The CMDB/CI dashboard: CMDB-wise and CI-specific

dashboard are available. The first can be accessed
through the Configuration application of ServiceNow.
The later can be accessed through the CI form, using a
toggle switch in the header of the form. It is displaying the
result of correctness, completeness and compliance KPIs.

3. The Compliance application: it is the application where

ServiceNow data audits can be configured (this is not
only available for the CMDB). This application is
leveraged in the latest additions to the CMDB by
ServiceNow and the CI class manager gives access to
some configuration tables of this application.

In previous releases of ServiceNow, the Configuration

application was mostly a set of classes in which we could store

65
configuration items, essentially a CMDB. What we saw coming with recent releases is that ServiceNow
has added features to really support the ITIL configuration management process, with the result being
the 3 main functionalities mentioned above with the Helsinki release.

The CI Class Manager

The CI Class Manager is split in 3 panes, tree selector of the class on the left-hand side, information
displayed in the center and option on a pane on the right-hand side:

The new CI class manager, introduced with the Helsinki release of ServiceNow

66
In this new configuration panel, we have access to the setup of the following functionalities:

Rule category When Feature

Correctness On regular CI Identifiers:

automatic checks They are used to detects duplicates. As explained above,
this is mainly used in state-of-the-art interfaces but some of
them might not use this mechanism or some CIs might be
created manually or via batch load. To cover these cases,
ServiceNow uses identifier on regular automatic checks to
detects duplicates.

Correctness At creation of CIs Reconciliation definitions and data source precedences:

This is used to control how the CMDB can be fed. In these
modules you can basically define which data source is your
SSOT (Single Source of Truth) and what is its scope (what
attributes this data source is allowed to updated on specific
classes)

Correctness On regular Orphan and staleness rules:

automatic checks Orphan rules allows the administrator to define exactly
when a CI should be considered as an Orphan (checks on
attributes as well as relationships).Staleness rules allow the
administrator to define after how much time without any
activity from a given datasource, a CI must be considered as
stale. As for identifiers, this is used on regular automatic
checks.

Completeness On regular Required fields:

automatic checks When a user interacts with the CMDB, a record cannot be
saved if a mandatory field is empty. But for regular and
automated imports, this does not necessarily apply.
Required field checks is basically making sure mandatory
fields are all filled in.

Completeness On regular Recommended fields:

automatic checks Recommended fields can be configured here. These are not
mandatory fields but the ones it would be good to have set.

Compliance On regular Certification filters, templates and audits:

automatic checks These allow the administrator to essentially define the set of
data to be assessed (filter) and what the system should look
at (template). This function leverages on a functionality
introduced in earlier releases to basically define audits on
CMDB data.

67
What happened then when the compliance, completeness and correctness rules are configured and
that the system performs regular (recurrence to be configured) automatic checks? Most of the above
regular automatic checks will only feed KPIs so the configuration manager can report on what is wrong.
For compliance audits, working with filters and templates, Follow On Tasks can be triggered. These
are simple task records that can be assigned to teams to undertake corrective actions and are
accessible through the application called Compliance.

The CI/CMDB dashboard

The CI/CMDB dashboard is where a configuration manager can check the overall completeness,
correctness and compliancestatus of the CMDB or dig in more details, getting statistics for a particular
class. The CMDB dashboard is accessible via the Configuration application.

The new CMDB

dashboard,
introduced with
the Helsinki
release of
ServiceNow

A CI specific dashboard exists as well and is accessible via the header of the CI form:

The CI-centric
dashboard
toggle
available in the
header of an CI
class record

68
Similar information are then displayed specifically for the selected CI:

The CI-centric
dashboard

69
 The Compliance application
The compliance is partly accessible via the CI class manager. It is where audits on ServiceNow hosted
data can be configured. It is not only specific to the CMDB and can also apply to other datasets of the
system such as assets or tasks. It works with three dimensions: filters (what data will be checked),
templates (what will be checked)and audit definitions (when checks will be performed).

Key functionality Description

Versioning Filters and templates are versioned. When a filter or a template is modified, it
does not override the previous configuration of it but creates a new version
where its number is increased by 1.

Codeless Templates allow to define what checks will be performed on a given filter. It
template does not only allow check attributes of records but also:
definition
CI Relationships
User Relationships (as CI relationship)
Group Relationships (as CI relationship)
Related list content

Template definitions can created without the need of writing scripts.

Creation of When an audit fails on a given record, follow-on tasks can be created. At the
follow on tasks definition of the audit, the choice is given on how these tasks will be assigned:
either to specific user or group or contextually to the CI record being assessed.

Link with CMDB remediations can be defined via the Configuration application.
remediations Remediations are meant to be Orchestration workflows (which is going a bit
beyond the scope of this ebook) and are accessible contextually fromfollow-on
tasks (a follow-on task related to a windows server will only show remediations
available for windows servers).

Scripted audit If codeless template are not enough to define what checks should be
performed, there is always the possibility to completely script the audit (requires
knowledge of JavaScript).

70
 DEPENDENCY VIEW

The dependency view is the new name given by The dependency view also has a dedicated
ServiceNow to the BSM map from the Geneva application in the left-hand side menu of
release. BSM use to stand for Business Service ServiceNow. This is because it does not only
Management map. The dependency view should displays CIs and CI relationships but it can include
not be confused with the service mapping map the following main functionalities:
which essentially displays the same information
but focusing specifically on applications and all
underlying components. The dependency view,
however, will display configuration items and CI
relationships.

The Helsinki release dependency view (a.k.a. the legacy business service map)
71
Functionality Description

Map Menu Additional menu action can be added when right-clicking on a CI in the
Actions dependency view. This is only coding so it should be setup by a ServiceNow
administrator but a typical usage of this is in incident management: based on the
context" of the incident (the service), the user can display a map, see all
underlying CIs, right-click on one of them and set it as the impacted CI (see also
next functionality).

Map Indicators Map indicators are used to add little badges next to CIs in the dependency view
to highlight the ones that have outages, incident problem, changesetc. New
indicators can be configured if necessary.

Map Related Relationships displayed in the dependency are normally CI relationships (as
Items explained in chapter 2 covering the configuration model). But in the CMDB, many
CIs also have one-to-many relationships (references). Some of them might be
interesting to see in a dependency view and these can be configured here.

72
What is very powerful with this dependency view is that it can be accessed from any reference field
pointing to the ServiceNow CMDB in any processes. Typically it is heavily used for incident
management (root cause analysis) and change management (impact/risk analysis)

73
 Change management is probably the process that is the most
CHANGE dependent on the CMDB. In this process, a change user needs to
MANAGEMENT document what has changed or what will change on the
infrastructure or applications, needs to perform impact and risk
analysis or needs to document planned outages if applicable. All
these activities require information from the CMDB. In this
dedicated sub-chapter, the following features will be presented:

1. Proposed change

2. Impact analysis

3. Change conflict analysis

PROPOSED CHANGE
In operations, priority is given to the actual task to be performed. If
there is some time left, documentation will be performed. Normally
this should not be the case and proper time should be allocated to
documentation. Rule says that people should be booked 80% of
their time to be able to absorb all disturbing daily activities within
the 20% percent of time left. Often we do not have the luxury for
this but it is not the subject of this chapter.

Proposed changes tend to remediate this. Actually the way it

works is the following:

1. At the creation or initiation of the change, what will be

changed from a CMDB standpoint is documented using the
proposed change functionality.

2. The change is performed, in real life.

3. Once the change is implemented and reviewed, the

proposed change, initially documented during the initiation
phase of the change can be applied to the CMDB in one
click.

This feature works with the aected CI related list, displayed at the
bottom of the change request form. The change coordinator or

74
whoever documents the change request can right click a selected aected CI, and use the option
Proposed change. This will display, as an overlay, the CI form in which the user can propose changes.
All proposed new attribute values are stored in the system to be applied to the CI record later in the
process.

Aected CIs related list context menu action

The proposed
change
functionality is
accessible when
right clicking on
the affected CI
list of a change
request

Proposed change overlay

The proposed change functionality is displayed as an overlay where it is allowed to configure/

document what will be changed for a given CI

This feature is often overlooked by organizations but in fact, if a good configuration model has been
defined, and a good work on each classes was done in terms of attributes. This is a relatively simple
thus powerful functionality that can greatly help maintaining and up-to-date CMDB.

75
CHANGE IMPACT ANALYSIS
The change impact analysis functionality is simple and very powerful. But the functionality will only
work if a proper configuration model has been put in place and if the CMDB is correctly maintained
(either manually or automatically via integrations).

CI relationships in the CMDB have a specific direction as they are used to model a dependency: they
have a parent and a child. The change impact analysis functionality will take as input one or more
aected configuration items (configuration items that will be touched during the change process),
recursively loop through CI relationships with CI dependent on aected CIs, and this until it finds a
service potentially impacted.Impacted services are then documented in a related list on the change
request form.

This documented list can then be used for instance to:

1. Ease the creation of a planned outage. A planned outage can then be used to be displayed to all
impacted users (users who have subscribed to the service) in a portal.

2. Ease the selection of change approvers

3. Further analyze the change for potential conflicts (see next chapter)

Change header context menu action

he impact analysis functionality is accessible

when right-clicking on the header of the
change request.

76
 Impacted services related list

The result of an impact analysis is displayed in a related list of the change request

With ServiceNow Service Mapping, this functionality not only loops through CI relationships but also
look up for potentially impacted services in a table called Service Configuration Item Associations.
This table is filled in when an application is explored and discovered using Service Mapping.

CHANGE CONFLICTS ANALYSIS

The change conflicts analysis functionality of ServiceNow will basically checks that a the planned
change dates are compatible with the immediate environment of all aected CIs and impacted
services. Actually, what the functionality does exactly is controlled using a set of system properties. But
what is a change conflict? Potentially it is the following:

A change that falls during a blackout period (a period during which nothing should be undertaken
A change that does not fall during a maintenance window
A change that falls at the same time as another change with the same aected CI (2 changes at the
same time on the same CI)

These three potential type of conflicts are checked on either:

The main aected CI of the change

All aected CIs
Direct parent or child CIs of either the main aected CI of the change or the whole list of aected
CIs

All the above rules

77
As for the change impact analysis, the result of the change conflict analysis is a related list on the
change request form with all potential impacts. The functionality can either be triggered manually from
the change record itself, be triggered automatically whenever the change is updated with a new
configuration item or new planned start/end date or can be triggered on a regular basis to assess for
instance all changes currently being planned (controlled by a system property).

Change related link action

The conflicts analysis functionality is

accessible through a related link in the
change request form

Informational message and information on the change record itself

The system keeps track of the last time a conflict

analysis has run

The conflicts analysis functionality is accessible

through a related link in the change request
form

78
 Change conflicts related list

The list of conflicts found is displayed in a related list of the change request

Of course this feature requires that blackout and maintenance windows are documented in
ServiceNow. These windows are recorded in the form of calendar entries and can apply to the entire
CMDB or to a particular set of CIs.

79
5

GLOSSARY
ITSM Information Technology Service Management

ITIL Information Technology Infrastructure Library

KISS Keep It Simple and Smart

CMDB Configuration Management Database

CSI Continual Service Improvement

SME Subject Matter Expert

KEDB Known Error Database

MDR Managed Data Repository

KSF Key Success Factor

CRAC Computer Room Air Conditioner

UPS Uninterruptible Power Supply

SAN Storage Area Network

NAS Network Attached Storage

DAS Direct Attached Storage

MSD Mass Storage Device

CI Configuration Item

VLAN Virtual Local Area Network

ERP Enterprise Resource Planning

RFC Request for Change

ITAM Information Technology Asset Management

KPI Key Performance Indicator

BSM Business Service Management

80
 We are a passionate and dedicated partner
for your Service Transformation journey.
Fruition Partners has the team, services and technologies
required to transform all your business service disciplines

www.fruitionpartners.eu
info@fruitionpartners.eu
or find Fruition Partners nearest oce at fruitionpartners.eu/where

Copyright 2017 Fruition Partners, a CSC company All Rights Reserved. ServiceNow, ServiceNow product names and the ServiceNow logo are
trademarks of ServiceNow, Inc. All other brand and product names are trademarks or registered trademarks of their respective holders.

81