DXC Fruition · ServiceNow to keep track of the origin of assets and subsequently CIs. • Contract...

May 2018

The ultimate CMDB guide for ServiceNow

White Paper

DXC Fruition

2

Building a configuration management database (CMDB) is like building a house. Let’s agree that every house has a door, windows, a floor, at least 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 they have to support, differences may be implemented. Nowadays, infrastructure and application layers are standardized, and nearly all organizations face the same challenges. Moving forward, the Information Technology Infrastructure Library (ITIL) maturity level will continue to increase; thus, needs from the CMDB will converge to become very similar.

This paper is intended for readers who are or will be replacing their current legacy IT service management (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 for legacy solutions. Implementing ServiceNow is therefore a great opportunity to build a tailored CMDB that perfectly fits your needs. In addition to this, ServiceNow has an unprecedented level of integration with all processes, ITIL, IT or non-IT. To be sure to start on the right track, you need guidance, and that is what this paper is meant to be.

Recommendations in this paper are guided by:

1. Respect for the CMDB vision of ServiceNow as much as possible. This means remaining as close to standards as possible (“out-of-the-box”).

2. Best practices gathered from the multiple CMDB implementations done at DXC Fruition for its customers.

The paper is organized into four parts. The introduction focuses on theory. The second part will focus on the implementation processes of the CMDB (establishment of the configuration model). The third part will home in on processes, mainly the management of the life cycle of configuration items (CIs), once the CMDB is in place and fed with data. Finally, the fourth part will focus on ServiceNow and key functionalities leveraging the CMDB.

And also: KISS (Keep It Simple and Smart). Pretty much any physical or logical components of an organization’s IT could find their places in the CMDB. But building a CMDB is a journey, and you should approach it step-by-step. If defining some areas of your configuration model is a process that is too long or tends to be complex/complicated, simplify. Start simply and expand later.

IntroductionTable of contents

Introduction 2

Configuration management per ITIL copy 3

Asset management 4

CMS vs. CMDB 5

Implementation 6

How to proceed 6

Configuration model 10

Pitfalls 33

Integration with CMDBS/MDRS 35

ServiceNow Discovery 37

ServiceNow Service Mapping 39

Processes 42

Roles and responsibilities 44

Assets and CI life cycle 47

Use cases 49

ServiceNow CMDB and asset functionalities 53

CMDB health 53

Dependency view 57

Change management 59

Glossary 63

About the author 64

White Paper

Configuration management per ITIL copy

As per ITIL books, configuration management or SACM (service asset and configuration management) is a process that:

• Supports the business and the customer’s control objectives and requirements

• Supports efficient and effective service management processes by providing accurate configuration information to enable people to make decisions at the right time, e.g., to authorize change and releases, or resolve incidents and problems faster

• Minimizes the number of quality and compliance issues caused by improper configuration of services and assets

• Optimizes these service assets, IT configurations, capabilities and resources

Because the core of this process is a configuration management database (CMDB) or a configuration management system (CMS), it should reflect as much as it can the current state of applications and infrastructure of the organization. A CMDB is composed of CIs that are interconnected to form a network of dependencies between a data center and a service.

These CIs need to be controlled in some way (for regulatory reasons or because without controlling them, we can’t prevent failure) through a change management process. They should also provide necessary information for the change process so decisions can be made effectively. CIs are also key in speeding up and making incident and problem management processes more efficient. This inventory of the IT aspects of an organization, the CMDB, is also leveraged to spot inefficiencies and thus optimize services, capabilities and resources (continual service improvement, CSI).

In CI, the word “configuration” needs to be emphasized. In a CMDB/CMS, we focus on configuration information about a given element of the IT inventory:

• An element is a server and not a network device

• A server has 64GB or RAM

• A storage device is consumed by the ESX cluster XYZ, etc.

The primary consumers of the CMDB will be the service desk and SMEs in the scope of the change/release management process. In other words, IT technicians and engineers.

3

White Paper

Asset management

While the CMDB focuses on configuration information and interactions between CIs, asset management will focus on the organizational and financial aspects of equipment. The focus of th is paper is the CMDB and not asset management, but we cannot speak about one without mentioning the other. An asset manager wants to know, among other things:

• What the price of a server is and how much it costs

• When the guarantee expires

• How many workstations will need to be replaced next year

Before a device (a CI) is installed, up and running to deliver 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 of by the asset management process: the life cycle. Asset management in ServiceNow encompasses the following subprocesses:

• Product catalog. Manages models of assets/CIs currently in use or planned by the organization. It also allows the publication of part of it in a request catalog to allow users to directly request what they need. A vendor catalog aspect is also provided to be directly integrated with vendors.

• Procurement. This is an interesting small process that does not intend to replace a company-wide procurement solution, often SAP, but rather integrates with ServiceNow to keep track of the origin of assets and subsequently CIs.

• Contract management. Manages IT contracts, from maintenance to warranties, through purchase orders, nondisclosure agreements, etc. A contract will cover one or multiple assets.

• Inventory management. Manages assets in stock, stock transfers, auto-restocking, etc. Stocks are the source from which assets/CIs will 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 those for configuration management, we mainly have the following kinds of assets:

• Hardware. Servers, workstations, network devices, but not virtual machines (VM)

• Software/applications. MS Office, Oracle 11g, ServiceNow or Salesforce

• Consumables. Printer toner, keyboards or mice, if managed as such

White Paper

4

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 organization but is not tracked independently. For example, 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 two states: “In stock” and “Consumed.” A consumable has no impact on the CMDB, so we won’t talk about it in this document.

CMS vs. CMDB

The difference between a CMS and a CMDB is in the scope. The CMDB, as it is called in ServiceNow, is the database where configurations are stored, which means the application and infrastructure inventory of the organization. The CMS encompasses more than configurations, such as a Known Error Database (KEDB) and master data (users, groups and organizational data ).

In addition to that, the concept underlying the CMS is the federation of CMDBs. A CMS is composed of multiple CMDBs, but they 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 technologies such as web services and structural languages to achieve this.

In reality, the theoretical CMS does not yet exist. When it comes to ServiceNow, we have an additional challenge, which is software as a service (SaaS). It is difficult 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 offers.

White Paper

5

Figure 1. Asset and CI synchronization mechanisms in ServiceNow

Storage CI

Set of attributes 1

ITIL

Pro

cess

es

ITAM

& S

AMPr

ocur

emen

tC

ontr

act

etc.

Storage assetSame attributes

Network device assetSame attributes

Network device CISet of attributes 2

Service CISet of attributes 3

Same device

Same device

Only CI

CMDB: Asset management:

Only asset

Synch

Synch

Softwarelicense asset

Consumable asset

The implementation of a CMDB is a long process, and it’s not easy. Many organizations struggle for various reasons. Often, in my experience, it’s due to a poor ITSM strategy, thus jumping too quickly to the implementation with poor acceptance and understanding of major SMEs. Or, it’s due to a poor design or understanding of organization’s scope of services: “We don’t know what we deliver, but we need a CMDB.”

It is actually quite rare to find an organization that says, “We have implemented a complete CMDB.” Most of them do have managed data repositories (MDR), such as System Center Configuration Manager (SCCM), for specific areas. Many of them have integrated some MDRs with ServiceNow. The real value of a CMDB comes when dependencies between CIs are known. A CMDB without CI relationships is more a flat inventory of IT components, rather than a CMDB. Few organizations can say for sure which service, and subsequently customers, will be affected if server n° 84 in a data center is shut down.

Finally, the CMDB implementation does not stop after the first phase but is or should be continually improved.

If you plan to do a big bang in one phase, the risk of failure will be high. The CMDB touches a vast number of areas in an IT organization, so it is way too difficult to get it right in one phase. The most important aspect of a CMDB implementation is to start small but correctly and to enlarge it on regular basis, along with the experience you gather from using it.

How to proceed

You need three ingredients before the actual implementation can start:

1. Know what you deliver to your customer

2. Know what data sources you may have for the CMDB

3. Define the scope of the first phase

The first point, in an ideal world, is knowing the list of business services. If not, because it’s not trivial, it’s 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 organizations 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 depends on the first two. The maturity of your services, coupled with the readiness of the different sources to be migrated/integrated with ServiceNow, will define the scope of the phase.

White Paper

6

Implementation

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 do these classes relate to each other?

For the first question, there are basically two approaches: bottom up and top down.

The bottom-up approach is when you already have a good level of maturity within the IT organization and people who 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 selects three very different services and organizes workshops around them with all necessary stakeholders to “discover” 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 toward a federated CMDB, the reality is that within the IT organization, there is a lot of misunderstanding about how certain parts of it work. Often people work in silos very well but don’t know how the system works in the silo next to them. Three typical services could be:

• Messaging

• ERP

• An application that’s developed in-house

Note that I’m mentioning a typical service that all companies have (messaging) and two services supported by applications. In this approach, often services are not yet known or well-defined, thus the selection of two applications.

Due to the level of uncertainty with such an approach, usually workshops are organized in two short sessions per service, plus a reconciliation workshop where the results of all three services can be demonstrated. A proposal for Phase 1 can be then extracted with the list of needed classes.

The goal of the second question is to identify, for each necessary class, whether among the inventory of tools/spreadsheets, one can be used as the source of data. There are two types of sources:

• An integration — data is refreshed on a regular basis (usually daily or more often)

• A one-time shot — a source we would rather migrate than integrate into ServiceNow

At this point, some decisions must be made. A top-down or bottom-up definition of classes does not necessarily give you what is exactly needed in ServiceNow.

White Paper

7

Sometimes it turns out 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 data center. It’s better to have a simple CMDB with up-to-date and trustworthy data than a complex CMDB that is not maintained and therefore contains data users cannot trust.

The goal of the third question is to make sure we refocus on what the CMDB should support at first: incident, problem and change management. This means:

• We should provide the minimum necessary information needed for these processes.

• But we shouldn’t store in the CMDB too detailed information that we won’t be able to maintain 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 one organization to another. The strategy/process should always be:

White Paper

8

Define common attributes

Attribute kept

Attribute dropped

Define detail attributes

Is attribute automatically maintained?

Can it be maintained manually?

Yes

Yes

No

No

Figure 2. CI attribute decision flow

Finally, the goal of the last question is to get the glue that will allow us to build the configuration model: Define dependency relationships among classes to ensure we have a path that links a data center to all the services/business services it indirectly provides. This question is answered in detail 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. It’s a relatively simple diagram that illustrates clearly how classes relate to each other. It should help users understand how the CMDB is structured and how they should use it.

White Paper

9

Data center(cmdb_ci_data_center)

Storage Device(cmdb_ci_msd)

Consumed byCluster/Server

Through software install table

End-user devicesLegend

Printer(cmdb_ci_printer)

Comp. Peripherals(cmdb_ci_peripheral)

Communication Device(cmdb_ci_comm)

Network(cmdb_ci_ip_network)

Network Gear(cmdb_ci_netgear)

UPS(cmdb_ci_ups)

Configuration items(cmdb_ci)

Application(cmdb_ci_appl)

Database Instance(cmdb_ci_db_

instance)

Cluster(cmdb_ci_cluster)

Software(cmdb_ci_spkg)

Server(cmdb_ci_server)

Virtual Machine(cmdb_ci_vm_

instance)

Hardware(cmdb_ci_hardware)

Computer(cmdb_ci_computer)

Rack(cmdb_ci_rack)

Rack(cmdb_ci_rack)

Service

Computer Room(cmdb_ci_

computer_room)

Class extension

Related list (1-*)

Depends on :: Used by

Runs :: Runs on

Uses :: Used by

Hosts :: Hosted by

Connected :: Conn. by

Virtualizes :: Virtual. by

Houses :: Located in

Cons :: Consumed by

8

5

5

7

7

7 77

7

5

5

5

5

6

4

22

3

1

4

DC Ops Storage Ops

Net. Ops

End Users

Server Ops

Appl Ops

>

> >

> >

> >

> >

> >

> >

> >

> >

2

3

4

5

6

7

8

1

<

<<

<

<

<<

< <

<

<

<

<

< <

<

< <<

< <

<

<

<

<<<

<

<<

<

< < <

< < <<<<

<

<<<< <

Service offering(service_offering)

Figure 3. Example of a configuration model

The construction of such a diagram is not rocket science. In all organizations, 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.

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

• 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, 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 a 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 be in only one data center. This is a “technical” link between the two CIs. It also means that the computer room is dependent on the data center. If the data center burns down, 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, and thus don’t have a CI relationship defined.

Configuration model

For the following chapters, the configuration model has been subdivided into the following areas:

• Data centers

• Networks

• Storages

• Computing

• Applications

• End user devices

• Services

As illustrated by Figure 4, each area has a dedicated color, which should help to understand how the areas relate with one another. The objective here is to present how the vast out-of-the-box CMDB of ServiceNow can be efficiently used in your implementation. As stated at the beginning of this paper, all CMDBs will share the same characteristics, but they can all have their own specificities and variations depending on the organization’s needs. Therefore, each subchapter, representing one of the areas presented above, does not pretend to describe the only truth, but implementations that have proved themselves successful with our customers.

White Paper

10

Data centerStorage

Computing Applications

Serv

ices

End user devices

Network

Figure 4. CI attribute decision flow

We will start with data center operations because this will be the basis to “construct” the CMDB. Data centers house the organization’s hardware; they provide physical capacity. Then network and storage will be housed mostly in data centers and will provide connectivity and data storage capacity. The computing section will encompass everything around servers, clusters and virtual machines; it provides computing capacity. Finally, physical, connectivity, storage and computing capacity are used by applications to provide services. In addition to that, we also have to consider end-user devices.

Finally, we will consider an implementation without using ServiceNow Discovery or ServiceNow Service Mapping. The reason is that both products are quite structuring and, therefore, the approach should be slightly different. Nevertheless, two chapters will present these solutions and expand a bit on how to implement them with some key success factors (KSFs).

White Paper

11

Data center(cmdb_ci_data center)

Location master data

> >

>

>>

>

This is a ServiceNow CI relationship

(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 relationships)

Optional CI relationship/reference

CMDB entities

Other entities, less important and not within the scope of this document

Convention used:

Here is a final note related to conventions. Instead of the many-to-many or one-to-many types of relationships, we could have used arrows, but then colors should have been applied to differentiate them. In this paper, it was decided to stick with the entity type of relationships. Despite relations in ServiceNow that have a label (e.g., a type such as “Depends on”), we deliberately chose not to add these in the following chapters. The most important thing 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.

Data center

White Paper

12

Data centerStorage


Serv

ices

End user devices

Network

The usual structure of a data center is:

• A data center is located at a certain physical address

• Within this data center, there are computer rooms

• Within a computer room, we have racks

• Racks house various mount-in-rack items, such as switches, routers, servers, etc.

In ServiceNow, we usually have a physical location repository. The data center object of the CMDB has an attribute “Location” pointing at this location master data table. Subsequently, computer rooms, racks and mount-in-rack equipment logically inherit the data center location.

The link between computer rooms and data center is marked as “optional” because a computer room might not necessarily be part of a data center. For example: a small room housing a single rack on an office floor is seen as a computer room in the CMDB, but it does not have a link to a data center. Instead, it will have a link to a location master data record, just as a data center. Equipment that is not in computer rooms or data centers is by definition at a workplace. Therefore, these are also just linked to a location master data record.

Figure 5 represents this standard simple approach:

In this approach, we consider only mount-in-rack equipment. But we sometimes need to track CMDB equipment that is not mounted in racks, such as computer room air conditioners (CRACs) or UPSes. These two additional types of equipment should be implemented as:

• CRACs are linked upstream to a computer room

• UPSes are linked upstream to a computer room or a rack (for mount-in-rack UPSes)

These two types of equipment, from a physical perspective, could also be linked downstream (double relationships). In the end, this can be summarized as:

• 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 to do maintenance on a UPS, what we want to know is the potentially affected applications/services that would be down if — at the same time — we experienced a power outage. Therefore, the most important relationship is the one that describes to which computer rooms/racks the UPS provides power.

White Paper

13



Computer room(cmdb_ci_computer_room)

Rack(cmdb_ci_rack)

Any rackableequipment

(Optional)Inherited

from parent

(Optional)Computer room

may not be in DC

Figure 5. Simple data center configuration model

This concept can be represented as shown in Figure 6:

Storage

White Paper

14

Figure 6. Extended, with CRAC and UPS, data center configuration model



Computer room(cmdb_ci_computer_room)

Computer Room AC(cmdb_ci_crac)

UPS(cmdb_ci_ups)

Rack(cmdb_ci_rack)

Any rackableequipment

(Optional)Inherited

from parent

(Optional)Computer room

may not be in DC

(Optional)Inherited

from parent

Data centerStorage


Serv

ices

End user devices

Network

Storage management is technically quite complex and thus not easy to represent in a CMDB. It is important to remember the following two 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. Let’s have a look at two different possibilities. Depending on the organization’s needs, the solution might well lie between the two of them:

1. “Legacy solution” using a table called “Mass Storage Device”

2. “New solution” using the enriched set of tables around SAN and network attached storage (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 advantages are the simplicity of the model and the fact it will be easy to maintain (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 eventually allow representation of the following concepts:

• SAN fabrics and zoning

• Storage virtualization with storage pool

• SAN disks vs. volumes and LUN numbers

• Storage controller/host-bus adapter (HBA), switches and ports

The following diagram represents the simple Variant 1:

In the above diagram, mass storage devices should basically be NAS or SAN (eventually direct attached storage [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 information, etc. Hardware equipment (primarily servers, clusters (i.e., ESX) and other storage devices (e.g., network attached storage) will/can then consume mass storage “devices.”

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

White Paper

15


Rack

Hardware equipment

Mass storage device(cmdb_ci_msd)

Storage device(cmdb_ci_storage_device)

(Optional)Inherited from

parent

Inherited into:– Disk (cmdb_ci_disk)– SAN Disk (cmdb_ci_san_disk)

Figure 7. Storage configuration model

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

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

White Paper

16

Hardware Stack Logical Stack

Storage pool

Storage poolmember

Storage volume (Lun)

Storage HBA Storage controller

Fiber channel port Storage port

Storage device SAN zone set

SAN zone SAN zone allas

SAN connection

SAN endpoint

SAN zone member

Storage server(cmdb_ci_storage_server)

SAN switch(cmdb_ci_san_switch)

SAN(cmdb_ci_san)

SAN fabric(cmdb_ci_san_fabric)

Figure 8. 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 only CI components (storage HBA, storage controller, storage ports, etc.).

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:

White Paper

17


Rack

Hardware equipment

SAN fabric(cmdb_ci_san_fabric)

SAN(cmdb_ci_san)

SAN switch(cmdb_ci_san_switch)

Storage server(cmdb_ci_san_server)

Storage file share (NAS)(cmdb_ci_storage_fileshare)

Storage device(cmdb_ci_storage_device)

Inherited into:• Disk (cmdb_ci_disk)• SAN Disk (cmdb_ci_san_disk)

(Optional)Inherited

from parent

(Optional)Inherited

from parent

Figure 9. Variant 2 storage configuration model

In the above diagram, one additional class has been added for comparison with the previous diagram: Storage File Share. This class aims at representing NAS in an infrastructure environment. Either a NAS is a standalone appliance that has disks, or a NAS is an appliance without disks that uses SAN to store data. Finally, with this model, we don’t 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 point to remember is 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 losing ourselves in trying to find the right level of abstraction.

Network

White Paper

18

Data centerStorage


Serv

ices

End user devices

Network

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

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

• There’s a need for inventory (link with asset management)

• Incident and problems should be logged against network devices

• Impact analysis should be performed based on change requests

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

The concept is:

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

• The network is provided as a VLAN from network equipment

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

When network equipment is under maintenance, we know which VLAN it contributes to, thus which equipment is potentially affected. This concept can be represented as shown in Figure 10.

White Paper

19


Rack

Hardware equipment

IP network (VLAN)(cmdb_ci_ip_network)

End user devices

Network device(cmdb_ci_netgear)

(Optional)Most end user

devices won’t have the link

(Optional)Inherited

fromparent

Figure 10. Simple network configuration model.

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

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

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

Computing

White Paper

20

Data centerStorage


Serv

ices

End user devices

Network

Computing power is the last data center area necessary for running applications, databases, application servers, etc. A server will “consume” all other three areas already modeled, thus its position in the above diagram:

• It will be located in a data center or at least in a computer room

• It will need to be connected to an IP network

• It will consume storage (most likely in todays’ architecture)

We need to be able to model three different “categories” of servers:

• A standalone physical server

• A virtual server running on a physical server

• A virtual server running on a farm (ESX/Hyper-V, etc.)

A physical server can be represented as:

Rack


IP network


Application CI

(Optional)Inherited

from parent)

SAN/NAS

Figure 11. Simple computing configuration model

ServiceNow provides a quite extensive list of subclasses for servers, the main ones being:

White Paper

21

We can notice the load balancer, chassis server and the storage server classes deliberately left on the above list. The server class is used to manage appliances as well. The same remark as in the previous chapter applies here: It is good to subclass when maintained attributes differ from one type of server to another. Appliances often fall 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 considers a virtual server as a whole, and the latter considers the virtual machine and the virtualized server as two different CIs. This second option adds a bit of complexity, but allows both objects to be maintained separately, which is useful when SMEs are different for the virtual machine and the image/server deployed on top of it.

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

Rack IP Network


Application CI

(Optional)Inherited

from parent

SAN/NASFigure 12. Simple virtualization computing configuration model

However, this type of virtual server is not used frequently. The last category of server — virtual and running on a farm (ESX, Hyper-V, etc.) — 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.

White Paper

22


Virtual flag = FALSE

Cluster(cmdb_ci_cluster)

Virtual machine(cmdb_ci-vm)


Virtual flag = TRUE

Application CI

IP networkSAN/NAS


Rack

(Optional)Inherited

from parent

Figure 13. Extended virtualization computing configuration model

Generic classes have been used deliberately in the diagram shown in Figure 13. Depending on the virtualization technology, variations may be applied.

VMware vCenter/ESX:

• Virtual Machine (cmdb_ci_vm) → VMware (cmdb_ci_vm_vmware)

• Cluster (cmdb_ci_cluster) → VMware v Center Cluster (cmdb_ci_vcenter_cluster)

• [Physical] Server (cmdb_ci_server) → ESX server (cmdb_ci_esx_server)

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 a specific class out of the box for virtual machines. A custom subclass or the default class can then be used.

Applications

White Paper

23

Data centerStorage


Serv

ices

End user devices

Network

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 the following in the CMDB:

Service offerings/services

Database instance(cmdb_ci_db_instance)

Server(virtual or not)



Figure 14. Simple application configuration model

With the application layer, we are just one layer below services and service offerings (application services). The basic principle is that a service offering or a service (to be covered in more detail in the next chapter) will depend on 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 won’t be discoverable automatically.

Let’s take ServiceNow as an example to illustrate the difference between an application and software. ServiceNow is a Java web app:

• Depends on a JRE (Java Runtime Environment)

• Depends on a Tomcat application server

• Depends on a MySQL database

All the 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 exist as such. In the case of ServiceNow, 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 eventually, etc. In a way, it’s a record we use to simplify the model and hides the complexity of today’s business applications behind one box in the configuration model.

That being said, in Figure 14, we are differentiating the application and the database instance. The reason for this is that in most organizations, databases’ and applications’ SMEs are very different. Maintaining and monitoring databases is a job in itself. Nevertheless, we could also make abstractions of databases and “hide” them behind applications. The contrary is valid, too. The following diagram expands the simple model presented above and shows its possible evolution:

White Paper

24

White Paper

25


Application server(cmdb_ci_appl)



Application component(u_cmdb_ci_appl_comp)


Server(Virtual or not) Software package

Figure 15. Extended application configuration model

Two classes have been added in the above diagram: application servers and application components. The first can be necessary for organizations that manage them separately (different SMEs), and the latter has been added to subdivide big applications into smaller chunks.

A typical example of such an application with components is an ERP. An ERP often delivers more than one service/service offerings and is so vast that a part of the application might be affected by an outage without it being affected at all elsewhere. ServiceNow could be another example, being a platform used to provide many different applications. Note that the application component entity is in red because ServiceNow does not offer out-of-the-box a dedicated class to manage this concept; it is an additional nonmandatory configuration. ServiceNow, with Discovery or Service Mapping, manages all kinds of application components in 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.

Expanding the database area

So far, we are using a database instance class only to represent databases in the configuration model, but this area can also be expanded if necessary.

White Paper

26

Figure 16. Extended, with database catalog, application configuration model

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 organizations may use:




Database catalog(cmdb_ci_db_catalog)


Server(virtual or not)

Clustered and/or load-balanced applications

The difficulty with clustered and load-balanced applications is to represent them correctly in 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 does not depend on the application, but rather, the opposite. Based on that, below is the full representation that should be used.

White Paper

27



Load balancer(cmdb_ci_lb_appl)Load balancer

(hardware) Cluster


Server(virtual or not) Or Cluster

Or applicationload balancer

Or hardwareload balancer


Figure 17. Extended, load balancer and cluster, application configuration model

The diagram above summarizes 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, as it belongs to the application area. A hardware load balancer is often considered an appliance that subsequently is also often managed as a server with a dedicated functionality. Therefore, and even if it has not been mentioned in previous chapter, it makes more sense that these are managed as part of the computing group. It was not mentioned previously in this chapter either, but a database instance could also be clustered.

What’s 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 clear when it comes to load balancers, as stated earlier in this section.

In terms of classes, ServiceNow proposes two additional out-of-the-box classes that could be used to manage application clusters.

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 server but to the cluster record instead.

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

Hardware load balancers

White Paper

28

Application load balancers

Environments

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

• Each application, application component and database instance is duplicated for each environment. That can allow them to have production and nonproduction services/service offerings depend on them.

• We consider only one application for all environments. The notion of environment becomes an attribute of the CI instead. All the hardware related to nonproduction 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.

End users

White Paper

29

Data centerStorage


Serv

ices

End user devices

Network

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

• Workstations

• Tablets

• Smartphones

• Bar code scanners

• Printers (even networked)

• Peripherals (screens, directly attached scanners, etc.)

• Other

As stated in the section related to modeling the network, end user devices are almost all connected and thus potentially dependent on many things. It is important to focus on the reasons for having end user devices in the CMDB:

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

• These most likely won’t be used in change management. They are very incident-centric kinds of CIs.

CI relationships are useful in incident management, for root cause analysis, but not as critical as for change management. All this is 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 difficult to maintain and could not be accurate automatically (autodiscovery).

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

White Paper

30


Server(Printing)

Application

Computer(cmdb_ci_computer)

Computer peripheral(cmdb_ci_peripheral)

Printer(cmdb_ci_printer)


Communication device(cmdb_ci_printer)

Disk(cmdb_ci_disk)

Extension of storage device

Network adapter(cmdb_ci_network_adapter)

Software package(cmdb_ci_spkg)

(Optional)Inherited

from parent'suser CI

Figure 18. End user devices configuration model

What we see in the above table is that the barrier is very clear. Either the terminal has an issue and it’s the only root cause, or it is related to a deeper issue because a shared resource is misbehaving. The root cause can then be many things, related to an application or infrastructure. In reality, there will be lots of other not-so-clear cases, but these will not account for the majority. In addition, a dependency rarely exists between the workstation and applications/infrastructure, but rather between a user and the applications they have access to and the underlying infrastructure.

Issue description Possible root cause ImpactA software package is not working properly

1 workstation 1 user is affected

The hardware has a problem

1 workstation 1 user is affected

An application is not working properly

• Network

• SAN

• Server

• Other

Multiple users are affected

The diagram for such a concept is then very simple (see model shown in Figure 18): All end user devices apart from printers are orphans. They are not directly linked to a service/service offering, and they don’t 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 offering (printing service).

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

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

Services

White Paper

31

Data centerStorage


Serv

ices

End user devices

Network

The service layer in the CMDB is the topmost layer. Let’s look 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 organization provides (sells) services to other organizations’ departments (customers). The IT department has the ownership of costs and risks (and the technical means) and, on the other side, customers want results (i.e., they want the service they pay for to perform well). Let’s look at a practical example: The finance department wants a solution so it can manage the organization’s finances:

• The organization’s IT department runs and supports an ERP at a certain price

• The organization’s IT department is responsible for making that solution available and reliable enough by making use of internal or external resources (CIs and/or other services)

• The organization’s IT department should be capable of monitoring the performance of such a service (primarily support and availability)

Remember that configuration management and the CMDB’s primary goal is to support service management processes. Organizing CIs under services goes toward that goal.

Incidents have affected service (as reported by the user/consumer of the service), but so has a faulty CI (found during the root cause analysis). At the same time, a change request might be ongoing. This Request for Change (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 applications and infrastructure CIs, this information can be easily spotted. In addition, the incident 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 Offering

The Service Offering class will exist only after activating the plug-in “Service Portfolio Management.” It intends to manage location variation or different flavors of a service for its respective users. Service ABC in Zürich might not have the same contractual commitments that the same service has 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 into too much detail, this additional plug-in will allow the configuration of such service flavors and provides solutions to monitor support and availability results on a per-service-offering basis. It is good practice to start with this concept, even if the maturity level does not allow a pure definition of service offerings with different commitments. The rest of this chapter will then consider whether the service offering 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 into three categories:

White Paper

32

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

Supporting A supporting service is a service that everyone or nearly everyone gets to help accomplish his or her day-to-day tasks but that does not directly support the core business of the company. “Messaging” can be considered such a service. The emails facilitate the exchange of information and can be critical, but they are not what the company makes its money on.

Infrastructure An infrastructure service is provided, as its name indicates, by the back-end infrastructure. Such a service can be the network or storage.

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

White Paper

33


Network

End user(printers)

Computing

Applications

Service offering(service_offering)

Service(cmdb_ci_service)

Storage

User Department Company Location

Subscription

Figure 19. 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 offering class is available and is used, it must be the component linked to the underlying application and infrastructure CIs. A service offering can also leverage other service offerings from supporting or infrastructure services. (Some of these relationships are implicit, such as 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 flavors.” This subscription concept in ServiceNow simply defines who or what is consuming the service in the organization, thus defining to whom the contractual commitments apply.

Pitfalls

Looking 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 do these classes relate to each other?

Pitfalls arise when the CMDB implementation project fails to answer these questions correctly. Basically, three dimensions need to be put into perspective:

1. The maturity of the organization

2. How much is known about CIs (available sources)

3. What is expected from the CMDB

White Paper

34

1

3 2Goal

Sources

MaturityObjectiv

es

Figure 20. The goal is to find the right balance among objectives, maturity and data sources.

1. Maturity + Objectives

The objectives ascribed to the CMDB are well-balanced with the maturity of the organization. It means the focus is right compared with how the CMDB will be used. No unnecessary classes, attributes or relationships should be maintained. But without carefully taking into account what we know about CI classes defined in the configuration model, the following situations might be encountered:

• We don’t leverage 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 inefficient and making extra work for users.

• We miss an opportunity to replace an ineffective 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 replace uncollaborative solutions. Again, the CMDB will be seen as inefficient and making extra work (jobs done potentially twice).

2. Maturity + Sources

Compared to the first case, we have clearly looked at what is known about the organization’s applications, infrastructure and end user devices. Old, inefficient Excel spreadsheets are replaced, and integrations are put in place. But without focusing on objectives, we might end up with a very good and effective CMDB — but one that does not deal with the current organization’s pain points.

• The user will be given a truck when seating capacity is needed and a Porsche when speed matters. The perception will be that the tool does not efficiently help users in day-to-day tasks and additional tools will be needed.

3. Objectives + Sources

In the second case, we have a very good CMDB, focused on objectives, with integrations when these could be done and replacing old ineffective solutions to make sure users will not need to do the job twice. We carefully made sure that the CMDB is perceived as an effective solution. But without taking into account the maturity, we have basically forgotten 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 else the scope is very narrow. With such a CMDB, the user will be given something that exceeds its competences.

• We are most likely covering too much compared to the available resources. The goal of the configuration model is to have something consistent across all its areas. By covering too much compared to what is possible, we will end up with poorly maintained classes and relationships, thus losing the effectiveness of the CMDB.

Finding the right balance between objectives, maturity and leveraging available sources of information is key to successfully implementing a CMDB in ServiceNow. This is valid for a Phase 1 but also for following iterations. There are five key success factors:

1. Always start small and expand 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, it’s 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.

If what is being done is too far from standard procedures, we should question whether we are doing the right thing. ServiceNow is no stranger to the ITSM business, and it embeds best practices into its platform.

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 populate/maintain the CMDB? The maintenance process will be covered in detail in chapter 4, but when implementing a CMDB, it’s likely that a management tool containing valuable information for the CMDB exists somewhere:

• MDR (Managed Data Repository)

• Or another CMDB, external to ServiceNow

White Paper

35

Besides ServiceNow, these solutions will continue to exist and are potentially automated themselves (thus ensuring high quality data). It would be a pity not to leverage them to help maintain data in ServiceNow.

In addition, ServiceNow proposes its own solutions to help with the maintenance process:

• ServiceNow Discovery

• ServiceNow Service Mapping (previously Nebula)

Both of these solutions are introduced in greater detail in the following chapters.

The first challenge to be faced when integrating ServiceNow CMDB into an organization that has multiple CMDBs or MDRs will be dealing with the overlap of two (or more) sources and the reconciliation of data. The following diagram represents a potential situation:

White Paper

36

Figure 21. When multiple data sources overlap, it is important to define SSOT and put reconciliation rules in place.

CMDBData center

End user Network Storage Computing Applications

SCCM

ServiceNow display

Network source Storage source

In this case, we can see that multiple sources overlap. The network source with Discovery, SCCM with Discovery, etc. The concept is that for each class, a single source of truth (SSOT) should be defined. Some classes will be manually maintained, and therefore their SSOT consists of manual inputs. Some others will get most of their configuration information from an MDR and therefore, if agreed and so decided, it becomes the SSOT. When an overlap exists, one source must take 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

In the above example, we consider SCCM the SSOT, since it has the smallest order. We also consider that it can create and update records, but we don’t specifically list attributes it has ownership of. Discovery has the exact same setup, but a higher order because it is not considered, for this class, to be the SSOT or the most accurate source.

The second challenge is about reconciliation. How does each source recognize whether a CI has to be inserted, or whether the CI exists already and has to be updated? For hardware CI, usually the serial number is used. Depending on the source, other attributes may need to be used, such as the media, access and control (MAC) address, an IP address or the hostname. Each of these attributes may be formatted slightly differently from one source to another (especially the MAC address), and this 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 transformation map in which the reconciliation rule needed to be configured/scripted.

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

• Document data source precedences for each classes in scope

• Document reconciliation definitions (which source can update what attributes)

• 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 by trying the correlation ID first; if not found, the system will try the serial number and then other attributes such as the hostname or IP and MAC address.

ServiceNow Discovery

ServiceNow Discovery is an agent-less solution that will scan your network on a regular basis for any kind of connected device. It works in a four-step process:

1. Shazzam. Scan the network and discover connected devices.

2. Classification. Try to define what kind of device has responded following a predefined pattern (e.g., if the device responds to WMI queries, it must be a Windows machine, etc.) and gather information about the device.

3. Identification. Reconcile the device and gathered information with an existing CI in the CMDB.

White Paper

37

Source Order Action Attributes

SCCM 100 Create/update All

Discovery 200 Create/update All

4. Explore. Get more information about the device, such as running processes, if applicable, or some deeper information on the device itself.

Since ServiceNow is a SaaS solution, to be able to discover devices/equipment, the solution relies on a management, instrumentation and discovery (MID) server, which is a small Java program running on a server in the customer’s network and capable of executing various kind of jobs.

I would call this approach “bottom-up” or “horizontal discovery” (as ServiceNow calls it).

The biggest advantage of the solution is that it is preconfigured to be capable of discovering most devices that an organization would be interested in having in its CMDB. In addition, it is agentless, and therefore does not require any intervention on devices before 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 less than useful due to the huge amount of information it will bring back to your ServiceNow instance. However, if well implemented, the solution is very powerful. Some key success factors:

• Plan, plan, plan

ServiceNow Discovery should not be considered a 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 magically discover devices it owns. It’s a solution to support users in the configuration management process but not replace 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 in the organization’s network to ensure that the scanning will be complete. It is a common mistake to not plan this accurately and thus end up with partial discovery — with MID servers unable to “see” everything they should.

• Prioritize

Define what’s most important. On a network, there could be lots of different kinds of devices. Not all of them are relevant in a CMDB and, more specifically, not all of them are relevant in a network range/subnet. When Discovery has to scan a certain IP range within a data center, what are the most relevant devices Discovery has to see? Probably servers, routers, switches, etc. To put this prioritization into practice, key functionalities with Discovery are behaviors, credentials and functionalities. On a per-phase and MID server basis, you can control which accesses are granted and what protocols should be used to control the scope of the scan. In addition, you can easily use the configuration console to control which main discovery functionalities are enabled or disabled.

White Paper

38

• Start small and simple, and expand later

This advice is repeated many times when implementing ServiceNow. It is easy to do something with ServiceNow compared with other tools, where careful design and planning must be done. It is too easy to go too fast and put into production something not fit for use or your purposes. With ServiceNow Discovery, because the data it creates has great visibility (the CMDB is used across many processes, primarily incident, problem and change management), it is hard to do a U-turn if 6 months down the road, we realize we did not do it correctly. It is then best to start small and simple. Take the time to validate the result. Finally, continue with multiple phases to expand its usage based on your priorities.

• Don’t underestimate the design phase

In a CMDB project, designing is key. For Discovery, it is the same. For each phase of the project, no aspects of the implementation should be neglected. Implementing the solution can be difficult and challenging in some organizations’ environments. Implementing Discovery requires talking to many different SMEs in the organization, all of whom have different requirements that can be constraints for the project. It is also good to manage expectations well in advance. Security aspects of the solution should be discussed at an early stage to make sure everyone’s needs are aligned.

ServiceNow service mapping

As for Discovery, service mapping is an agentless solution that shares and uses the same technologies. Initially, this solution was called Nebula and was acquired by ServiceNow in 2014. With the Geneva release of ServiceNow, it is fully integrated in the platform. As stated earlier, Discovery has an horizontal or bottom-up type of discovery approach. service mapping is top-down.

White Paper

39

Service mapping

Dis

cove

ry

Entry point: IP/URL

Entr

y po

int:

IP ra

nge

Applications:

Computing:

Storage:

Network:

Data center:

Figure 22. Horizontal discovery vs. top-down approach

You basically give service mapping an entry point: a 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 preconfigured patterns (out-of-the-box, but new ones can be created). If a pattern matches, 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

Let’s 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 additional connections are found.

How does that fit into our CMDB?

Service mapping creates a map of an application with technical dependencies, which 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 the potential small elements, etc.). The level of detail service mapping brings 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 judgment of a human being and is not capable of simplifying a hierarchy of elements. It just does what we tell it to do. We could modify its behavior by heavily customizing all the out-of-the-box patterns, but we would be losing its added value, and this would not be a good practice.

The answer is that the audience or the usage of the information service mapping brings to ServiceNow differs slightly from the rest of the CMDB. The big advantage 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, this 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:

• Plan, plan, plan: Technologies are the same; MID servers need to be at the right place as well.

• Prioritize and start small: Focus first on the most important/critical applications (three or five to start with).

White Paper

40

• Don’t 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 complex.

Multiple levels of granularity can cohabit in the CMDB. ServiceNow Discovery will do a horizontal/bottom-up discovery, but in some aspects, results of scan might not fit perfectly 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 will provide a very detailed and accurate view of how an application, and subsequently a business service, is delivered to its customers.

White Paper

41

In the above figure, the level of information about the ESX environment might not be useful for everyone. The main elements can be integrated into the standard configuration model view without worrying about all the details. The same applies for the application “ABC.” This can be achieved when configuring the BSM map, which is presented later in this paper.

Applications:

Computing:

Storage:

Networks:

Data center:

Standard configuration model (high-level view)

Detailed View 2(Discovery)

ESX environment Applications ABC

Detailed View 1(Service Mapping)

Figure 23. Even though not trivial to set up, it is feasible to have multiple abstraction levels in the CMDB.

ProcessesOnce the CMDB is in place, it should not be static. The content of the CMDB needs to be maintained or updated — for some areas, as often as on a daily basis. For that we need processes. Modification/maintenance of the CMDB may occur in various contexts, but the three main processes that will “take care” of your data in the CMDB are:

• Change management

• Configuration management

• Asset management

Change management can be a proactive or reactive process. In the latter, a change request will occur following an issue (incident/ problem). A change request can affect one or more configuration item(s) and subsequently have an impact on one or more service offering(s). The change request needs to be approved by all the people it concerns (thus the reason for having good data in your CMDB, because that will be the source for defining these people) and once it is completed, the CMDB needs to reflect what the change request was all about.

Configuration management is the process that is “called” when a change request is completed and the CMDB needs to be updated. That’s for the reactive part of the process. The other part of the process is mostly proactive, where periodic reviews of the CMDB are performed. The objective is to ensure that the data matches the reality. If it does not, it has to be referred to change management. (Either something was implemented/installed without a change request, or the CMDB was not updated properly following a change request.)

What we see is that both processes are very much imbricated. As for all processes, the objective of configuration management is to ensure that we manage and perform actions within its scope correctly. In other words, that when we update a CI, we don’t miss attributes, we don’t miss relations, etc., and that periodically we try to realign its content based on the reality. I like to compare it to an inertial navigation system (INS). The system knows where the vehicle is based depending on how it is moving, but from time to time, we need to realign it with reality and reposition the system at the correct coordinates. For configuration management, the movements are change requests, and on a regular basis we look at our data centers and realign the CMDB to the reality.

White Paper

42

43

White Paper

Review CMDBmaintenance request

Take other necessary action(s)

Update necessarystatus attribute(s)

Update necessary attribute(s) if applicable

Update necessary CI component(s) if

applicable

Update necessary relationships(s)

From change

management

To change

management

Yes

Yes

Yes

No

No

No

Life cyclechanges?

CI update required?

Relations(s)change(s)?

Figure 24. CMDB maintenance process

Get and analyze physical infrastructure, end user

and application data

Get and analyzeCMDB data

Match both sets of data

Get and analyze CMDB baseline data

Get and analyze CMDB baseline data

Periodicverificationand audit

To change Yes

No

management

Deviationidentified?

Figure 25. CMDB audit and verification process

44

White Paper

Note that in the above process flow, we are talking only about updating because configuration management is only about CIs that already exist (at least in an ideal situation). When a technician installs a new switch or installs a new workstation, the device is not new but already exists in a stockroom. If it does not, the device needs to be purchased, and that is not part of configuration management but rather request fulfillment 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 processes, at least in the ideal situation or in theory.

In practice, because we have two processes, most of the time we are talking to different stakeholders (in a small organization there could be an overlap between roles and responsibilities). Different stakeholders mean that both sides can evolve at a different pace and have a different 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.

Roles and responsibilities

Previously, three processes were introduced. Below is basically how they interact with one another:

Changemanagement

Assetmanagement

Configurationmanagement

Change requeststrigger CI maintenance

requestsRegular audit and

verification process

Trigger the creation of new CIswhen assets are purchased andreceived in stock

Provide information such as:• Configuration information• Maintenance information• When a device/software is installed• When a device/software is uninstalled

Provide information such as:• Dependency relationship with service• Configuration information• Risk and impact analysis• Maintenance and blackout windows

Figure 26. Asset, configuration and change management interactions

45

White Paper

Role Process Description and responsibilities*

SA Change (CM), problem (PM) and incident (IM) management

Support agent (SA) and:

• IM performing investigation and diagnosis

• 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 in incident and problem management when mainly investigations are needed. In change management, the SA will be using the CMDB for risk and impact analysis and documentations. At the end, the SA will be assigning the change task to the configuration administrator (CA) when update or maintenance is required in the CMDB.

CC Change management Change coordinator:

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 the name indicates, the change coordinator coordinates a change request. The CC is assigning change tasks to support agents and/or theconfiguration administrator (as well). The CC is responsible for the communication about and impact on availability and/or outage duration.

PO Configuration management Process owner:

• Defining the purpose, objectives, scope, as well as the principles and CSFs of the process

• Designing and sponsoring the process throughout the organization and stakeholders

• Ensuring that selected process indicators are collected, analyzed and acted upon

• Driving the efficiency and effectiveness of the process; ensuring it is fit for purpose

• Initiating improvement activities considering people, process and/or supporting tools

The process owner is the ultimate person responsible for its performance and objectives and has the authority to change it.

46

White Paper

Role Process Description and responsibilities*

CA Configuration management Configuration administrator:

• Reviewing, acting upon and closing CMDB maintenance requests

• Coordinating CMDB maintenance activities

• Updating CI records

• Ensuring that CI information adequately indicates how it is used to support service delivery (relations)

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

CfM Configuration management Configuration manager:

• Managing the process operationally

• Performing periodic verifications and audits

• Identifying deviations between actual and expected configuration data

• Determining how deviations between actual and expected configuration data will be reconciled through change management

• Ensuring that identified deviations are reconciled in a timely fashion

• Identifying unauthorized CMDB maintenance

• Ensuring that selected indicators are collected, analyzed 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 unauthorized changes and ensuring that data is up to date and driving the CMDB maintenance.

AM IT Asset management Asset manager:

• Implementing the organization’s service asset management policy and standards.

• Agreeing on scope of the asset management processes, function, the items that are to be controlled and the information that is to be recorded

• Developing asset management standards, asset management plans and procedures

• Managing the asset management plan, principles and processes, and their implementation

• Providing reports, including management reports (indicating suggested action to deal with current or foreseen shortcomings), impact analysis reports and asset status reports

• Initiating actions needed to secure funds to enhance the infrastructure and staffing levels 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 his/her counterpart, the configuration manager.

* Responsibilities within the perimeter of configuration management. Nonconfiguration management roles, of course, have other responsibilities than what are listed here.

47

White Paper

Assets and CI life cycle

We start by differentiating two major categories of elements:

1. Abstract or virtual elements in the CMDB such as softwares, applications, virtual machines, etc.

2. Concrete or hardware elements in the CMDB such as physical workstations, physical servers, network appliances, etc.

Abstract or virtual elements are much more versatile than concrete or hardware elements. The first can appear or disappear very quickly following mainly change requests, whereas the latter will go through, normally, a proper purchasing process and start their life cycles in a stockroom.

The border between what should be done as part of the asset management process and what is done as part of the configuration/change management process is not always clear. But in essence, the below diagram depicts where the life cycle of the two categories of elements introduced earlier are managed.

For physical or hardware elements, the life cycle starts in asset management. When one of these elements is installed or in use, the life cycle continues in the CMDB (configuration management or change management process). In the end, physical elements eventually finish their life cycle in a stockroom, waiting to be scrapped or sold.

ITAM ITAMCMDB

Orderingstage

In stockIn transit

In use

Installed

Maintenance

Maintenance

Retired

Retired

Physical Hardware

Abstract/virtual

Figure 27. Life cycle of abstract/virtual assets is much shorter than for physical assets

48

White Paper

For abstract/virtual elements, basically everything is done as part of the configuration change management process, from the installation to the retirement stage.

Asset Manager

Matters most:• Money

Does not matter:• Technical specs• Purpose

CMDB Admin

Matters most:• Purpose• Technical specs• How it is "plugged" to the environment

Does not matter:• Money

CPU: Intel Core I7RAM: 16 GbHD: 4 TONetwork: 3 interfaces

Cost: 5000 CHF

PO: 01.02.2014

Deprecation: 3Y

Warranty: => 2017

Figure 28. A CI/asset could also be represented as a coin, with one face being the asset side and the other one the CI side

Let’s briefly look back at two different 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 unpacked 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 unpacked from its box and plugged in. 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.

To manage this life cycle, ServiceNow has out-of-the-box a set of install or hardware status in the CMDB and a set of install status and substatus 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.

49

White Paper

Use cases1. Managing the life cycle of a CI and presentation of the out-of-the-box

ServiceNow approach

2. Managing multiple environments and presentation of an approach

The first use case has been selected for this white paper 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 does 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 nonproduction environments should be tracked in the CMDB and how to position the border between what is considered production and what is not. This use case tries to answer these points and proposes an approach.

How do I manage the life cycle of a CI?

This question was probably partially answered in chapter 3.2. In ServiceNow, to keep it simple in the context of this paper, we have two different applications: one for the CMDB and one for asset management. This because we essentially have two different roles: the asset manager and the configuration manager. But both applications are using and affecting the same data (again, to keep it simple and make an 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 do 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 valid as well, but they do not have a one-to-one counterpart in the CMDB (the closest we get is the software instance). Managing software licenses is a process in itself; thus, we will not take this into account here or expand on this topic.

# Activity Process Involved ServiceNow Module Outcome1 Purchase of a new

hardware devicePurchasing Asset Management A new asset record is created in the system. The asset

record has also a CI counterpart that has been created. Both have the status “On order.”

2 The new hardware device is received

Purchasing (goods receipting)

Asset Management The received package is checked, the serial number 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.

3 The new hardware device is transferred to another local stockroom

Stock management (transfer order) with inputs from change management

Change Management => Asset Management

The device is probably transferred for installation. Therefore the origin of the request is probably a change request. The little transfer 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 hardware device is installed

Change Management

Change Management => Asset Management => CMDB

The asset is taken out of stock and set with status “Pending install”. The corresponding CI is picked as the affected 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 device is under maintenance

Change Management

Change Management => CMDB => Outage Management

The maintenance on a CI should theoretically be undertaken as part of a change (as long as it means something has to be changed on the device). Status is set to “In Maintenance.” Eventually a planned outage should be logged.

6 The hardware device is audited

Configuration Management

CMDB => Change Management

The CMDB should be audited on regular basis to ensure 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 device should be uninstalled

Change Management

Change Management => Asset Management

The device removal should be done as part of a change, as for the previous active an 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 device reaches end-of-life support and will be retired

Asset Management with inputs from contract management

Asset Management The asset is updated with the corresponding “Retired” status:

• Donated

• Sold

• Disposed

50

White Paper

51

White Paper

This table does not cover all activities but probably the most common. The important point to retain here is that at each stage of the life cycle of an asset/CI, there is/are process(es) to take care of it. The previous table covers the principal 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

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 those, 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 that we need to track them. How do we manage this?

Generally, when we talk about environments, we are referring to a nonproduction instance of an application. In this case, an environment in the CMDB will in the end be modeled as a dedicated application and service or service flavor(service offering).

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 two different services or — and most likely — one service with two different offerings, one for DEV and one for PROD (see Figure 29).

52

White Paper

It is also important to be aware of the following differentiation:

• Configuration items supporting a specific environment

• Configuration items supporting a production service used by a nonproduction environment

The second point might be hard to understand. In many organizations, roles and responsibilities are not siloed but defined in layers. For example, you might have a service responsible for virtualization. When you need computing power to deploy a sandbox or development environment of an application, you request VMs for that service. The service is responsible for ensuring that VMs are running smoothly but it is not accountable for anything deployed on them. More importantly, the VM is provided by a production service but supporting a nonproduction one. The proposed configuration model covered in previous chapters perfectly handles these cases. Below is an example of how different environments could be modeled in ServiceNow:

Online Bet Business Service

Online BetOffering

ACMEOnline BetPROD App

ACMEOnline BetDEV App

VirtualServer

Cluster 1

Server1 to x

Server1 to x

Cluster 2

VM

LoadBalancer

HWServer1 to 3

Visualization Supporting Service

PROD PROD PROD

Online BetOffering VWware Hyper-V

DEV

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

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

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

Figure 29. Production vs. nonproduction environment representation in ServiceNow

53

White Paper

ServiceNow CMDB and asset functionalitiesBesides the theory of 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.

CMDB health

As we saw in the chapter dedicated to processes, configuration management is essentially a reactive process with requests 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 covering the following functionalities:

1. The CI Class Manager: It is essentially a configuration panel consolidating different new and existing functionalities, as well as giving shortcuts to system properties and a data dictionary.

2. The CMDB/CI dashboard: CMDB-wise and CI-specific dashboards are available. The first can be accessed through the “Configuration” application of ServiceNow. The latter can be accessed through the CI form, using a toggle switch in the header of the form. It displays the result of correctness, completeness and compliance KPIs.

3. The “Compliance” application 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 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 three main functionalities mentioned above with the Helsinki release.

The CI Class Manager

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

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

54

White Paper

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

Rule category When FeatureCorrectness On regular

automatic checks CI identifiers: They are used to detect 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 identifiers on regular automatic checks to detect duplicates.

Correctness At creation of CIs Reconciliation definitions and data source precedences: These are used to control how the CMDB can be fed. In these modules you can basically define which data source is your single source of truth (SSOT) and what its scope is (what attributes this data source is allowed to update on specific classes).

Correctness On regular automatic checks

Orphan and staleness rules: Orphan rules allow the administrator to define exactly when a CI should be considered 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 data source, a CI must be considered stale. As for identifiers, they are used on regular automatic checks.

Completeness On regular automatic checks

Required fields: 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 basically make sure that mandatory fields are all filled in.

Completeness On regular automatic checks

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

Compliance On regular automatic checks

Certification filters, templates and audits: 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.

What happens when the compliance, completeness and correctness rules are configured and 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 compliance status of the CMDB or dig into more detail, getting statistics for a particular class. The CMDB dashboard is accessible via the configuration application.

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

Figure 31. The new CMDB dashboard, introduced with the Helsinki release of ServiceNow

55

White Paper

Figure 32. The CI-centric dashboard toggle available in the header of a CI class record

Similar information is then displayed specifically for the selected CI:

56

White Paper

Figure 33. The CI-centric dashboard

The compliance application

The compliance application 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, but can also apply to other data sets 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 DescriptionVersioning Filters and templates are versioned. When a filter or a template is modified, it does not override

the previous configuration, but creates a new version where its number is increased by one.

Codeless template definition

Templates allow us to define what checks will be performed on a given filter. They do not only allow check attributes of records but also:

• CI relationships

• User relationships (as CI relationship)

• Group relationships (as CI relationship)

• Related list content

Template definitions can be created without the need to write scripts.

Creation of follow-on tasks

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

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

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

Business ServiceSAP Enterprise Service

BusinessSAP Financial Accounting

Windows ServerSAP LoadBal01

Web ServerSAP WEB01

Web ServerSAP WEB02

Web ServerSAP WEB03

Web ServerSAP WEB04

ComputerCALLXPR1

Windows ServerSAP LoadBal02

Business ServiceSAP Human Resource

Business ServiceSAP Controlling

Business ServiceSAP Sales and Distribution

Business ServiceSAP Payroll

Databasebond_trade_aus

Business ServiceSAP Labor Distribution

Business ServiceSAP Plant maintenance

Business ServiceSAP Materials Management

Dependency view

The “dependency view” is the new name given by ServiceNow to the Business Service Management (BSM) map from the Geneva release. The dependency view should not be confused with the service mapping map, which essentially displays the same information but focuses specifically on applications and all underlying components. The dependency view, however, displays configuration items and CI relationships.

The dependency view also has a dedicated application in the left menu of ServiceNow because it does not display only CIs and CI relationships, but can include the following main functionalities:

57

White Paper

Figure 33. The Helsinki release dependency view (aka the legacy business service map)

58

White Paper

Functionality DescriptionMap menu actions Additional menu action can be added when right-clicking on a CI in the dependency view.

This is only coding so it should be set up by a ServiceNow administrator. A typical use 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 affected 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 problems, changes, etc. New indicators can be configured if necessary.

Map-related items Relationships displayed in the dependency are normally CI relationships (as explained in chapter 2, discussing 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.

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).

Change managementChange management is probably the process most dependent on the CMDB. In this process, a change user needs to 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 subchapter, the following features are presented:

1. Proposed changes

2. Impact analysis

3. Change-conflict analysis

Proposed changes

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

Proposed changes tend to remediate this. Here is how it works:

1. At the creation or initiation of the change, what will be changed from a CMDB viewpoint 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 affected CI-related list, displayed at the bottom of the change request form. The change coordinator or whoever documents the change request can right-click a specific affected 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.

Affected CIs related list context menu action

59

White Paper

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

Figure 35. The proposed change functionality is displayed as an overlay, where it is allowed to configure/document what will be changed for a given CI.

60

White Paper

Proposed change overlay

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

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 affected configuration items (configuration items that will be “touched” during the change process), recursively loop through CI relationships with CI dependent on affected CIs, and continue until it finds a service potentially affected. Such services are then documented in a related list on the change request form.

This documented list can be used, for example, to:

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

• Ease the selection of change approvers.

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

Change header context menu actionFigure 36. The impact analysis functionality is accessible when right-clicking on the header of the change request.

Impacted services related list

With ServiceNow service mapping, this functionality not only loops through CI relationships but also looks 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 basically checks that the planned change dates are “compatible” with the immediate environment of all affected 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:

• 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 affected CI (two changes at the same time on the same CI)

Three potential types of conflicts are checked on either:

• The main affected CI of the change

• All affected CIs

• Direct parent or child CIs of either the main affected CI of the change or the whole list of affected CIs

• All of the above rules

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 a new planned start/end date or it can be triggered on a regular basis to assess, for instance, all changes currently being planned (controlled by a system property).

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

61

White Paper

Change-related link action

Informational message and information on the change record itself

Change conflicts related list

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.

Figure 38. The conflict analysis functionality is accessible through a related link in the change request form.

Figure 39. The system keeps track of the last time a conflicts analysis was run.

Figure 40. The conflicts-analysis functionality is accessible through a related link in the change request form.

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

62

White Paper

Glossary

63

White Paper

Key functionality Description

BSM Business Service Management

CI Configuration Item

CMDB Configuration Management Database

CMS Configuration Management System

CRAC Computer Room Air Conditioner

CSI Continual Service Improvement

DAS Direct-Attached Storage

ERP Enterprise Resource Planning

ITAM Information Technology Asset Management

ITIL Information Technology Infrastructure Library

ITSM Information Technology Service Management

KEDB Known Error Database

KISS Keep It Simple and Smart

KPI Key Performance Indicator

KSF Key Success Factor

MDR Managed Data Repository

MSD Mass Storage Device

NAS Network-Attached Storage

RFC Request for Change

SAN Storage Area Network

SME Subject Matter Expert

UPS Uninterruptible Power Supply

VLAN Virtual Local Area Network

64

Loïc Horisberger is a senior service management consultant at DXC Fruition, DXC Technology’s global ServiceNow practice. He started working on ServiceNow 7+ years ago when he joined Aspediens, the European ServiceNow expert, which is now part of DXC.

During his years as technical consultant, then solution consultant and now service management consultant, Loïc gained an extensive knowledge of the ServiceNow ecosystem, as well as of the ITIL, IT service management (ITSM) and service management areas.

With a BS science in media engineering, Loïc is also certified in ITIL v3 Foundation, ITIL 2011 intermediate-service operation and ServiceNow system administration. He also is a ServiceNow implementation specialist, a ServiceNow certified trainer, a CipherCloud solution architect, a CipherCloud project manager and an Okta solution partner.

During his free time, Loïc 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 different angle.

About the author

White Paper

Learn more at www.dxc.technology/servicenow

White Paper

www.dxc.technology

About DXC Technology

DXC Technology (DXC: NYSE) is the world’s leading independent, end-to-end IT services company, serving nearly 6,000 private and public-sector clients from a diverse array of industries across 70 countries. The company’s technology independence, global talent and extensive partner network deliver transformative digital offerings and solutions that help clients harness the power of innovation to thrive on change. DXC Technology is recognized among the best corporate citizens globally. For more information, visit dxc.technology.

© 2018 DXC Technology Company. All rights reserved. FR-003. May 2018

Strategy and advisory

UI and UX design

Implementation and integration

Training and education

Run and support

We are a passionate and dedicated partner for your service transformation journey.

DXC Technology has the team, services and technologies required to transform all your business service disciplines.

http://www.dxc.technology/servicenow

http://www.dxc.technology/servicenow

DXC Fruition · ServiceNow to keep track of the origin of assets and subsequently CIs. • Contract...

Documents

Transcript of DXC Fruition · ServiceNow to keep track of the origin of assets and subsequently CIs. • Contract...