Ultimate CMDBGuide ServiceNow FruitionPartners [PDF]

Zitiervorschau

THE ULTIMATE 
 CMDB GUIDE FOR SERVICENOW BY LOÏC HORISBERGER

ABOUT THE AUTHOR

Loïc Horisberger is a Senior Service

With a Bachelor of Science in Media Engineering,

Management Consultant at

Loïc is as well certified ITIL v3 Foundation; ITIL

Fruition Partners, a CSC

2011 Intermediate - Service Operation;

company. He started working

ServiceNow System Administration; ServiceNow

on ServiceNow 7 years ago

Implementation Specialist; ServiceNow Certified

when he joined Aspediens,

Trainer; CipherCloud Solution Architect;

the European ServiceNow

CipherCloud Project Management; and, finally,

expert, that is now part of

Okta Solution Partner.

Fruition Partners.

During his free time, Loïc can be found piloting his

During his years has Technical Consultant, then

plane across the skies of Switzerland and Western

Solution Consultant and now Service

Europe, experiencing the magic and wonder of

Management Consultant, Loïc has gained an

being “up there” and seeing the world from a

extensive knowledge of the ServiceNow

different angle.

ecosystem as well as of the ITIL, ITSM and Service Management areas.

i

TABLE OF CONTENTS Chapter 1 - Introduction

3

Configuration Management as per ITIL copy

5

Asset Management

6

CMS vs. CMDB

8

Chapter 2 - Implementation

9

How to proceed

10

Configuration Model

14

Pitfalls

39

Integration with CMDBs/MDRs

41

ServiceNow Discovery

44

ServiceNow Service Mapping

46

Chapter 3 - Processes

49

Roles and Responsibilities

52

Assets and CI lifedycle

56

Use Cases

58

Chapter 4 - ServiceNow CMDB and asset functionalities

64

CMDB Health

65

Dependency View

71

Change Management

74

Glossary

80

ii

1

INTRODUCTION

Building a CMDB is like building a house. Let’s agree that every house has a door, windows, at least a floor with a  few rooms  and a roof. Then you may want to add a fireplace, a second floor or a swimming pool in the garden depending on your needs. All CMDBs are very similar but depending on the organization and processes it has to support, differences may be implemented. Nowadays, infrastructure and application layers are standardised and pretty much all organizations are facing the same challenges. Moving forward, the  ITIL maturity level will continue to increase thus needs from the CMDB will be converging to become very similar.

Building a CMDB is like building a house. Let’s agree that every house has a door, windows, at least a floor with a few rooms and a roof. Then you may want to add a fireplace, a second floor or a swimming pool in the garden depending on your needs.

This ebook is intended to readers who are in the process or will be in the process of replacing the current legacy ITSM solution by ServiceNow or are simply implementing ServiceNow and need to build a CMDB. ServiceNow is a vast and very flexible product which is often not the case of legacy solutions. Implementing ServiceNow is therefore a great opportunity to build a tailored cut CMDB that perfectly fits your needs. In addition to this, ServiceNow has unprecedented level of integration with all processes, ITIL, IT or non-IT.  Vast also means that to make sure you start on the right track, you need guidance and that is what this ebook is intended to be.

Recommendations made in the following chapters are guided by two factors: 1.

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

2. Best practices gathered along the multiple CMDB implementations we have done at Fruition Partners for our customers. This ebook is organised in four parts. The first one, the introduction, will focus on a bit of theory. The second part will be focusing on the i m p l e m e n t a t i o n p r o c e s s  o f t h e C M D B (establishment of the configuration model). Then the third part will be focusing on processes, mainly to the management of the lifecycle of CIs once the CMDB is in place and fed with data. Then finally, the fourth part will be focusing on ServiceNow and key functionalities leveraging on the CMDB. Last but not least:  KISS - Keep It Simple and Smart. Pretty much any physical or logical components of the whole IT of an organization could find its place in the CMDB. But building a CMDB is a journey and you should go step-bystep. If defining some areas of your configuration model is too long or tends to be complex/ complicated, simplify. Start simple and expend later.

4

CONFIGURATION MANAGEMENT AS PER ITIL COPY As per ITIL books, configuration management (or

effectively. CIs are also key in speeding up and

Service Asset and Configuration Management -

making incident and problem management

SACM) is a process that:

processes more efficient. This inventory of the IT

• Supports the business and 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, resolve incidents and problems faster.

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

• Optimises the service assets, IT configurations, capabilities and resources. Because the core of this process is a CMDB or a CMS (Configuration Management Database/ System), it should reflect as much as it can the current state of applications and infrastructure of the organisation. Elements composing a CMDB are CIs that are interconnected to form a network

aspects of an organisation, the CMDB, is also leveraged to spot inefficiencies and thus optimise services, capabilities and resources (CSI). In Configuration Item, there is the word “Configuration” which needs to be emphasised. In a CMDB/CMS, we really focus on configuration information about a given element of the IT inventory:

• That an element is a server and not a network device

• That a server has 64 GB or RAM • That 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

of dependencies between a datacenter and a service. These CIs need to be controlled in some manners (for regulatory reasons or simply because without controls over them we cannot prevent failure) through a change management process. They should also provide necessary information to the change process so decisions can be taken 5

ASSET MANAGEMENT

When the CMDB focuses on configuration

• Procurement: this is an interesting small

information and interactions between CIs, asset

process that do not intend to replace

management will rather focus on organisational

company-wise procurement solution, often

and financial aspects of equipments. The focus of

SAP but would rather integrate with

this document is the CMDB and not asset

ServiceNow to keep track of the origin of

management, but we cannot speak about one

assets and subsequently CIs.

without mentioning the other. An asset manager wants to know the following:

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

• When the guarantee expires • How much workstations will need to be replaced next year

• …etc. Before a device (a CI) is installed, up and running

• Contract management: manages IT contracts, from maintenance to warranties through PO, NDA, etc. A contract will cover one or multiple assets.

• Inventory management: manages assets in stock, stock transfers, auto-restocking…etc. Stocks is the source for assets/CIs to be installed. An asset or a CI should not be created installed but rather changed from status “In stock” to “Installed”.

delivering some kind of service, it has to be

Because the audience and the aspects tracked by

“created” in the real world as well as in the CMDB.

asset management are not the same than for the

This is also an aspect taken care by the asset

configuration management, we mainly have the

management process: the lifecycle. Asset

following kind of assets:

management in ServiceNow encompasses the following sub-processes:

• Product catalog: manages models of assets/ CIs currently used or planned to be used by the organisation. It also allows the publication of part of it in a request catalog to allow users to directly place a request for what they need.

• Hardware: server, workstation, network device but not VM

• Software/application: MS Office, Oracle 11g, ServiceNow or Salesforce

• Consumable: printer toner, keyboards or mice if managed as such

A vendor catalog aspect is also provided to be directly integrated with vendors.

6

A software/application asset is essentially known as a software license. A consumable is an asset that has a cost and that matters to the organisation but that are not tracked independently. We have 200 keyboards in stock and if someone needs one, we take the first one we find. Once a consumable is consumed, its value is lost. It therefore has 2 states “In stock” and “Consumed”. A consumable has no impact on the CMDB thus we won’t talk about it in this document.

Asset and CI synchronisation mechanisms in ServiceNow

7

CMS VS. CMDB

The difference between a CMS and a CMDB is in the scope. The CMDB, as known from a ServiceNow standpoint, is the database in which we store configurations. Which means the application and infrastructure inventory of the organisation. The CMS encompasses more than configurations such as a KEDB (Known Error Database) and master data (users, groups and organisational data). In addition to that the concept behind the CMS is the federation of CMDBs.  A CMS is composed of multiple CMDBs but do not, or ideally should not, replicate their data. The ideal CMS is a heavily integrated technology that reads multiple CMDBs on demand, thus always displaying the most accurate information to its user. It would heavily leverage on technologies such as web services and structural languages to achieve this. In reality, the theoretical CMS does not exist yet. When it comes to ServiceNow, we have an additional challenge which is SaaS. It is 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.

8

2

IMPLEMENTATION The implementation of a CMDB is a long process and it’s not easy. Many organisation struggles and for various reasons. Often, from 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 due to a poor design or understanding of organisation’s scope of services. We don’t know what we deliver but we need a CMDB. It is actually quite rare to meet an organisation that says “we have implemented a complete CMDB”. Most of them do have MDR (Managed Data Repositories, such as 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 organisations can say for sure which service, and subsequently customers, will be impacted if server n° 84 in a datacenter is shut down. Finally the CMDB implementation does not stop after the first phase but is/should be continually improved. If you plan to do a big bang in one phase, the risk of a failure will be high. The CMDB touches from close to far to a vast amount of areas of an IT organisation that it is way too difficult to get it right in one phase. The most important aspect of the implementation of a CMDB is to start small but right and grow it on regular basis along with the experience you gather using it.

9

HOW TO PROCEED There is three ingredients to have before the actual implementation can start: 1.

You need to know what you deliver to your customer

2. You need to know what data sources you may have for the CMDB 3. You need to define the scope of the first phase The first point, in an ideal world, is knowing the list of business services. If not, because 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 organisations to maintain configuration information. Often, updating the CMDB is perceived as an additional overhead task because the actual work is also done somewhere else. The last point is dependent on the first two. The maturity of your services coupled with the readiness of the different sources to be migrated/integrated with ServiceNow will define the scope of the phase.

THE FOUR QUESTIONS 1.

What classes of CI do I need?

2. What sources do I have for these classes? 3. Which attributes do I need for these classes? 4. How are these classes relating to each other? For the first question, there are basically two approaches:

• Bottom-up • Top-down The bottom-up approach is when there is already a good level of maturity within the IT organisation and that people know their applications and infrastructure. This is the usual approach when ServiceNow replaces a legacy CMDB or when it has pretty clear and robust sources. The top-down approach is about selecting 3 very different services and organise workshops around them with all necessary stakeholders to “discover”, all together, how these services are actually provided to the users. This sounds a bit odd but when the ServiceNow CMDB implementation is the first trial towards a federated CMDB, the reality is that within the IT organisation, there are lots of misunderstanding how certain part of it work. Often people work in silos very well but don’t know how it 10

works in the silo next to them. Three typical services could be:

• Messaging • ERP • An in-house developed application Note that I’m mentioning a typical service that all companies have (messaging) and 2 services supported by applications. In this approach, often services are not yet known or well-defined thus the selection of 2 applications. Due to the level of uncertainty with such an approach, usually workshops are organised in 2 short sessions per service plus a reconciliation workshop where the result of all 3 services can be demonstrated. A proposal for the phase 1 can be then extracted with the list of needed classes. The goal of the second question is to identify, for each necessary classes, if among the inventory of tools/spreadsheets, one can be used as the source of data. There are 2 types of sources:

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

Sometimes it turns up to be too granular and therefore the list should be simplified. Remember that the CMDB needs to be maintained for many classes that will stand between a service and a datacenter. It’s better to have a simple CMDB with up-to-date and trustful data than a complex CMDB not maintained and therefore with data users cannot trust. The goal of the third question is to make sure we re-focus on what the CMDB should support at first: incident, problem and change management. This means:

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

• But we shouldn’t store in the CMDB too detailed information that we won’t be able to maintained automatically through an integration. Basic attributes such as a name, serial number, model, manufacturer or assignee are always needed. More detailed attributes can vary a lot from an organisation to another. The strategy/ process should always be the following:

• A one-time shot - a source we rather migrate than integrate to ServiceNow At this point some decisions must be taken. A top-down or bottom-up definition of classes does not necessarily give you what is exactly needed i n S e r v i c e N o w . CI attribute decision flow 11

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

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

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

12

At this point, it is important to explain the following concepts and 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 to that, incidents, problems and changes are not raised against CI components but against the parent CI in a CI class. A CI relationship is displayed in red in the above diagram. A CI relationship is always a dependency between two CIs. There is always a parent and a child. Blue relationships in the above diagram are what is called a reference in the ServiceNow language. This type of relationship is used to link CI components to CIs or to represent technical relationship between CIs. A technical reference/ relationship might also be a CI relationship when the technical link directly implies a dependency in the configuration model. For example, a computer room can only be in one datacenter. This is a “technical” link between the two CIs. It also means that the computer room is dependant on the datacenter. If the datacenter burns down, then the room will be out of order as well. A disk link to a workstation is a technical link between a component and a CI. It is not a CI relationship because disks are not relevant in the configuration model thus don’t have a CI relationship defined.

13

CONFIGURATION MODEL

For the following chapters, the configuration model has been sub-divided into the following areas to dig into: 1. Datacenters 2. Networks 3. Storages 4. Computing 5. Applications 6. End-user devices 7. Services As illustrated by the above diagram, each area has a dedicated color which should help to understand how they relate with each other. The objective here is to present how the vast out-ofthe-box CMDB of ServiceNow can be effeciently used in your implementation. As stated at the beginning of this ebook, 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 area presented above, does not pretend to describe the only truth but implementations that proved themselves being successful with our customers.

We will start with datacenter operations because this will be the basis to “construct” the CMDB. Datacenters houses the organisation’s hardware, they provide physical capacity. Then network and storage will be housed mostly in datacenters and will provide connectivity and data storage capacity. Then the computing section will encompass everything around servers, clusters and virtual machine. 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 and importantly, we will consider an implementation without using ServiceNow Discovery nor 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 KSFs.

14

Convention used: This is a ServiceNow CI relationship (These are represented as many-to-many relationships because a CI relationship in ServiceNow is technically a many-to-many relation between two objects)

Reference (one-to-many relation) Optional CI relationship/reference

CMDB entities

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

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

15

DATACENTER

The usual structure of a datacenter is the following: 1.

A datacenter is located at a certain physical address

2. Within this datacenter, there are computer rooms 3. Within a computer room, we have racks 4. Racks houses various mount-in-rack items such as switches, routers, servers…etc. In ServiceNow we usually have a physical location repository. The datacenter object of the CMDB has an attribute “Location” pointing at this location master data table. Subsequently, computer rooms, racks and mount-in-rack equipment inherit logically the datacenter location. The link between computer rooms and datacenter is marked as “optional” because a computer room might not necessary be part of a datacenter. Example: a small room housing a single rack on an office floor is seen as a computer room in the CMDB but it does not have a link to a datacenter. Instead it will have a link to a location master data record, just as a datacenter. Equipments not in computer rooms nor datacenter are by definition at a workplace. Therefore these are just also link to a location master data record. The diagram on the right represents this standard simple approach:

Simple datacenter configuration model 16

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

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

• A CRAC provides cooling for a computer room and is located in a computer room • A UPS provides power supply to a computer room or a rack and is located in a computer room or a rack What matters here is the most important dependency. If we plan a maintenance on a UPS, what we want to know is the potentially impacted applications/ services that would be down if at the same time, we experience a power outage. Therefore the most important relationship is the one that describes to which computer rooms/racks the UPS provides power supply. This concept can be represented as shown on the right:

Extended, with CRAC and UPS, datacenter configuration model 17

STORAGE

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

What are my sources of information?

2. What do I need/can I maintain in the CMDB? The reason is that ServiceNow, over time, has enriched the way storage can be represented. Let’s have a look at two different possibilities. Depending on the organisation’s needs, the solution might well be in between both of them: 1.

“Legacy" solution using a table called “Mass Storage Device"

2. "New solution" using the enriched  set of table around SAN and NAS, primarily aimed at being populated automatically by ServiceNow Discovery Variant 1 hides the complexity behind one single object (as we will do with application). The advantage is the simplicity of the model and the fact it will be easy to be maintained (manually). Variant 2 uses a subset of a new set of tables, introduced from the Fuji release. It relies entirely on the out-of-the-box model but uses only the most relevant classes. It can 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/HBA, switches and ports

18

The following diagram represents the simple variant 1: 

Variant 1 storage configuration model

In the above diagram, mass storage devices should basically be NAS or SAN (eventually DAS if these are to be considered for the CMDB, in the sense of an external drive). This means that the whole complexity of a SAN environment is hidden behind this class.  Optionally, we can also have technical references to disks attached to each MSD if these can/should be maintained. Subsequently, this can become more detailed with the addition of volume information…etc.  Hardware equipments (primarily servers, clusters (i.e.: ESX) and other storage devices (NAS)) will/can then consume mass storage "devices". Note that the storage device class is a generic class in which we can managed any kind of disk. It is extended into the following subclasses: Storage Device (cmdb_ci_storage_device)
 |➝ Disk (cmdb_ci_disk)
      |➝ Storage Disk (cmdb_ci_storage_disk)
 |➝ SAN Disk (cmdb_ci_san_disk)
      |➝ Fibre Channel Disk (cmdb_ci_fc_disk)
      |➝ iSCSI Disk (cmdb_ci_iscsi_disk)

19

With this solution, we have a simple and flexible model that can be easily extended (disk, volumes, pools…etc.) or migrated to a more complex representation as described bellow. The whole complexity of a SAN implementation is represented in one single object and it is a good solution for the phase one of a CMDB. Below is a full diagram of all objects that can be used in ServiceNow CMDB since the Fuji release to represent storage. Variant 2 and 3 are based on this structure.

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

All relationships in the above diagram are technical references and many of the elements are or can be only CI components (storage HBA, storage controller, storage ports…etc.).

20

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

Variant 2 storage configuration model

In the above diagram, one additional class has been added compare to the previous diagram: Storage File Share. This class aims at representing NAS in a infrastructure environment. Either a NAS is a standalone appliance that has disks. Or a NAS is an appliance without disks that use SAN to store data. Finally, with this model, we 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 is to remember why and for whom we are implementing the CMDB? What information do we need to get from it? With the complexity of storage infrastructure, if we try to model something too complex, we risk to loose ourselves in trying to find the right level of abstraction. 21

NETWORK

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

Need of inventory (link with asset management)

2. Incident and problems should be logged against network devices 3. Impact analysis should be performed out of change requests If we want to be accurate in terms of impact analysis, it will be extremely heavy in maintenance. As for storage, auto-discovery won’t be able to fully do the job so manual maintenance will be necessary. Therefore, when it comes to network, it is important to accept a compromise in order to be able to integrate the layer within the configuration model. The concept is the following: 1. Any device that can connect to the network has an IP address attribute 2. Network is provided as VLAN from network equipment 3. Connection to a VLAN can be deducted automatically from its IP range and the IP address of the device.

22

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

If necessary, network devices can be subclassed as following (out-of-the-box): Network Gear (cmdb_ci_netgear)
 |➝ CSU/DSU (cmdb_ci_csu_dsu_network)
 |➝ FDDI Cards (cmdb_ci_fddi_network)
 |➝ Firewall Hardware (cmdb_ci_firewall_network)
 |➝ Hub Hardware (cmdb_ci_hub_network)
 |➝ Intrusion Detection System (cmdb_ci_ids_network)
 |➝ IP Firewall (cmdb_ci_ip_firewall)
 |➝ IP Router (cmdb_ci_ip_router)
 |➝ IP Switch (cmdb_ci_ip_switch)
 |➝ Modem Hardware (cmdb_ci_modem_network)
 |➝ WAN Accelerator (cmdb_ci_wan_accel_network)
 |➝ Wireless Access Point (cmdb_ci_wap_network)

As a reminder, it is good to use subclasses when maintained attributes are different from a type of device to another. Note the optional CI relationship between end user devices and IP network. In most cases it would be too difficult and create far to many relationship to maintain these. However, some end user devices might be critical to a point we would like to make sure they are not missed when doing an impact analysis.

23

COMPUTING

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

• It will be located in a datacenter or at least in a computer room • It will need to be connected to an IP network • It will consume storage (most likely in nowadays' architecture) There are 3 different “categories” of servers we need to be able to model: 1.

A standalone physical server

2. A virtual server running on a physical server 3. A virtual server running on a farm (ESX/Hyper-V…etc.) A physical server can be represented as following: Simple computing configuration model

24

ServiceNow provides a quite extensive list of subclasses for servers. The main ones being: Server (cmdb_ci_server)
 |➝ Windows Server (cmdb_ci_win_server)
 |➝ Linux Server (cmdb_ci_linux_server)
 |➝ UNIX Server (cmdb_ci_unix_server)
      |➝ AIX Server (cmdb_ci_aix_server)
      |➝ HPUX Server (cmdb_ci_hpux_server)
      |➝ Solaris Server (cmdb_ci_solaris_server)
 |➝ IBM Mainframe (cmdb_ci_mainframe)
 |➝ Virtualization Server (cmdb_ci_virtualization_server)
      |➝ Hyper-V Server (cmdb_ci_hyper_v_server)
      |➝ VMware vCenter Server Object (cmdb_ci_vcenter_server_obj)
           |➝ ESX Server (cmdb_ci_esx_server)
 |➝ Server Hardware (cmdb_ci_server_hardware)
      |➝ Network Appliance Hardware (cmdb_ci_net_app_server)
      |➝ Server Chassis (cmdb_ci_chassis_server)
 |➝ Storage Server (cmdb_ci_storage_server)
 |➝ CIM Server (cmdb_ci_cim_server)
 |➝ Load Balancer (cmdb_ci_lb)
      |➝ …

We can notice the load balancer, chassis server and the storage server classes left on the above list on purpose. The server class is used to manage appliances as well. Same remark than in previous chapter here: it is good to subclass when maintained attributes are different from a type of server to another. Appliances often falls into this category since these boxes have a very specific role. For the second and third categories of servers, both virtual, there are two possible models. The first consider a virtual server as a whole and the latter consider the virtual machine and the virtualized server as two different CIs. This seco nd option adds a bit of complexity but allows both objects to be maintained separately, 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 whole, then we simply need a recursive CI relationship to the server class: Simple virtualisation computing configuration model 25

However, this type of virtual server is not  frequent. The last category of server, virtual and running on a farm (ESX, Hyper-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: Generic classes have been used on purpose in the diagram shown on the right. 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 vCenter Cluster (cmdb_ci_vcenter_cluster)

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

Extended virtualisation computing configuration model

Hyper-V:

• Cluster (cmdb_ci_cluster) → Hyper-V Cluster (cmdb_ci_hyper_v_cluster) • [Physical] Server (cmdb_ci_server) → Hyper-V Server (cmdb_ci_hyper_v_server) Note that for Hyper-V, ServiceNow does not provide out-of-the-box a specific class for virtual machines. A custom subclass or the default class can then be used.

26

APPLICATIONS

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

Application

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

Simple application configuration model

27

With the application layer, we are just one layer bellow services and service offerings (application services). The basic principle will be that a service offering or a service (this will be covered in more details in the next chapter) will depend on/consumes an application to be delivered to its customers. As for all other areas of the configuration model, we can be a bit more specific. The above diagram is used when we consider the application as a whole (including the potential application server, redundancy, components… etc.). The obvious advantage is the simplicity of the model because this concept of applications won’t be discoverable automatically. Let’s take ServiceNow as an example to illustrate the difference between an application and a software. ServiceNow is a Java web app:

• Depends on a JRE (Java

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 t h e c o m p l ex i t y o f n o w a d a y s b u s i n e s s applications behind one box in the configuration model. This being said, in the previous diagram, we are differentiating the application and the database instance. The reason behind 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 abstraction of databases and “hide” them behind applications. The contrary is valid too. The following diagram expends the simple model presented above and present its possible evolution:

Runtime Environment)

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

• Depends on a MySQL database All above mentioned components are to be considered as software from a CMDB standpoint. All of them can be auto-discovered if servers are scanned. The result will tell that a version of Java is running on a server as well as a version of Tomcat and on another server we will have a version of MySQL installed. An application is an abstract concept, it does not exists as such. In the case of ServiceNow, Extented application configuration model 28

Two classes have been added in the above diagram. Application servers and application components. The first can be necessary for organizations that do manage them separately (different SMEs) and the latter has been added to subdivide big applications into smaller chunks. Typical example of such an application with components is an ERP. An ERP  often delivers more than one service/service offerings and is so vast that a part of the application might be impacted by an outage without being affected at all elsewhere. ServiceNow could be another example being a platform that is used to provide a lot of different applications. Note that the application component entity is in red because ServiceNow does not offers out-of-the-box a dedicated class to manage this concept. It is an additional configuration that is not mandatory. ServiceNow, with Discovery or Service Mapping, manages all kind of application components within the abstract application class or extended classes. There is also an additional relationship to software packages. In some cases, it might be relevant to have such a relationship between the application and the specific software package consuming it.

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

Extended, with DB catalog, application configuration model 29

In the diagram shown on the previous page the database catalog object is used to represent databases running on instances. Both classes, “Database Instance" and “Database Catalog", are extended to cover the various technologies organisations may use: Database Catalog (cmdb_ci_db_catalog)
 |➝ DB2 Catalog (cmdb_ci_db_db2_catalog)
 |➝ MSFT SQL Catalog (cmdb_ci_db_mssql_catalog)
 |➝ MySQL Catalog (cmdb_ci_db_mysql_catalog)
 |➝ Oracle Catalog (cmdb_ci_db_ora_catalog)
 |➝ Sybase Catalog (cmdb_ci_db_syb_catalog)
 Database Instance (cmdb_ci_db_instance)
 |➝ DB2 Instance (cmdb_ci_db_db2_instance)
 |➝ MSFT SQL Instance (cmdb_ci_db_mssql_instance)
 |➝ MySQL Instance (cmdb_ci_db_mysql_instance)
 |➝ Oracle Instance (cmdb_ci_db_ora_instance)
 |➝ Sybase Instance (cmdb_ci_db_syb_instance)
 |➝ HBase Instance (cmdb_ci_db_hbase_instance)
 |➝ MongoDB Instance (cmdb_ci_db_mongodb_instance
 |➝ PostgreSQL Instance (cmdb_ci_db_postgresql_instance)

Clustered and/or load 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 is not dependent on the application but it’s the opposite. Based on that, bellow is the full  representation that should be used: The diagram on the right summarises all possibilities. We have twice the load balancer entity. Once in red which means it belongs to the computing area of the configuration model and once in blue Extended, load balancer and cluster, application configuration model 30

as it belongs to the application area. A hardware load balancer is often considered as an appliance which subsequently is also often managed as a server with a dedicated functionality. Therefore, and even if it was not mentioned in previous chapter, it makes more sense that these are managed as part of the computing group. It was neither mentioned previously in this chapter, but a database instance 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 when it comes to load balancers as stated earlier in this section. In terms of classes, ServiceNow proposes out-of-the-box two additional classes to manage application clusters that could be used. Cluster (cmdb_ci_cluster)
 |➝ UNIX Cluster (cmdb_ci_unix_cluster)
 |➝ Windows Cluster (cmdb_ci_win_cluster)


 Typically, Microsoft clusters detected by ServiceNow  Discovery will be created within the Windows Cluster class. For the configuration model, a clustered application would not be attached directly to a server but to the cluster record instead. As far as load balancers are concerned, they can be both application or hardware. The following two sets of classes are proposed out-of-the-box by ServiceNow. The first inherits from class “Load Balancer” which houses hardware LBs (the class itself inherits from “Server”), the later inherits from class “Load Balancer Application” (which itself inherits from “Application”). Note that an application load balancer would need to be running on a server.

31

Hardware LBs Server (cmdb_ci_server)
 |➝ Load Balancer (cmdb_ci_lb)
      |➝ A10 Load Balancer (cmdb_ci_lb_a10)
      |➝ ACE (cmdb_ci_lb_ace)
      |➝ Alteon (cmdb_ci_lb_alteon)
      |➝ Cisco CSM (cmdb_ci_lb_cisco_csm)
      |➝ Cisco CSS (cmdb_ci_lb_cisco_css)
      |➝ Citrix Netscaler (cmdb_ci_lb_netscaler)
      |➝ F5 BIG-IP (cmdb_ci_lb_bigip)
      |➝ F5 BigIP GTM (cmdb_ci_lb_f5_gtm)
      |➝ F5 BigIP LTM (cmdb_ci_lb_f5_ltm)
      |➝ ISA Server (cmdb_ci_lb_isa)
      |➝ Network Load Balancer (cmdb_ci_lb_network)
      |➝ Radware Load Balancer (cmdb_ci_lb_radware)




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




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

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

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

32

END USERS

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

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

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

2. These most likely won’t be used in change management. They are very incident centric kind of CIs. CI relationships are useful in incident management, for the root cause analysis, but not as critical as for change management. All this to say, that the focus should not be on CI relationships when implementing end user devices in a configuration model unless the organization has a specific need. They would be very difficult to maintain and could not be accurate automatically (auto-discovery).

33

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

Issue description

Possible root cause

Impact

A software is not working properly

1

Workstation

1 user impacted

The hardware has a problem

1

Workstation

1 user impacted

An application is not working properly

1 2 3 4

Network SAN Server …etc.

Multiple user impacted

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 a lot of things, related to an application or infrastructure. In the reality there will be lots of other not so clear cases but for sure will not account for the majority. In addition to that, a dependancy rarely exists between the workstation and applications/the infrastructure but between a user and the applications she/he is granted access to and the underlying infrastructure. The diagram for such a concept is then very simple (see right): all end user devices apart from printers are orphans. They are not directly linked to a service/service offering and they

End user devices configuration model 34

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 just considered as a component of a workstation but can be optionally linked to the application the software is consuming (for instance, the ERP client will consume the ERP application). Finally, most of the technical references are optional. Lots of organization do have a source such as SCCM or LANDesk to maintain up-to-date computers, disks, software and network adapters attributes and in that case, most of the above technical references are also maintained accurately and automatically. In the case of an organization that cannot leverage on such an integration, it will be 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.

35

SERVICES

The service layer in the CMDB is the top-most layer. Let’s look back at an ITIL definition: "Services are a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks." In other words, the IT department of an organisation provides (sells) services to other organisation’s departments (customers). The IT department has the ownership of costs and risks (and the technical means) and on the other side, customers wants results (they want the service they pay for to perform well). Let’s look at a practical example: Finance wants a solution to be able to manage the organisation’s finance: A.

The organisation’s IT dept run and support an ERP at a certain price.

B.

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

C.

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

36

and the outage generated by the change request can then be easily rolled up to the service and used to measure its performances. In this layer, we have the following primary CMDB classes at our disposal:

• Business Service • Service Offering The Service Offering class will exist only after activating the plugin “Service Portfolio Management”. It intends to manage location variation or different flavour of a service for their respective users. Service ABC in Zürich might not have the same contractual commitments than the same service but in London. Or the “gold” version of that service will have more aggressive commitments than the “silver” or “bronze” version of that same service. Without going too much in details, this additional plugin will allow the configuration of such service flavours and provides solutions to monitor support and availability results on a per service offering basis. It is a 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 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 in three categories:

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 almost everyone gets to help accomplish their day-to-day tasks but that does not directly support the core business of the company. Such service can be “messaging”. The email facilitate the exchange of info and can be critical but is not what the company makes money off.

Infrastructure

An infrastructure service is provided, as its name indicates, by the backend infrastructure. Such service can be the network or storage. 

37

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

Standard service and service offering configuration model

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

38

PITFALLS Let’s look back at the four questions listed in chapter 2.1.1:

• What classes of CI do I need? • What sources do I have for these classes? • Which attributes do I need for these classes? • How are these classes relating to each other? Pitfalls are obviously when the CMDB implementation project failed to answer these questions correctly.  there are basically three dimensions to put in perspective: 1.

The maturity of the organisation

2. How much is known about CIs (available sources) 3. What is expected from the CMDB

(1) Maturity + Objectives The objectives given to the CMDB are wellbalanced with the maturity of the organization. It means the focus is right compare to how the CMDB will be used. No unnecessary classes, attributes or relationships should be maintained. But without carefully taking into account what we k n o w a b o u t C I c l a s s e s d e fin e d i n t h e configuration model, the following situations might be encountered:

• We don’t leverage on a potential integration. Users will be asked to maintain something manually that is already done elsewhere and potentially automatically. The CMDB will be perceived as inefficient and giving overhead work to 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 replaces the un-collaborative solutions. Again, the CMDB will be seen as  inefficient and giving overhead work (job done potentially twice).

(2) Maturity + Sources Compare to the first case, we have perfectly looked at what is known about the 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 The target is to find the right balance between objectives, maturity and data sources

39

very good and effective CMDB but that does not answer current organization’s pain points.

• The user will be given a Porsche whereas he would need seating capacity or a truck whereas speed matters. The perception will be that the tool does not efficiently help him in his day-to-day tasks and will still need additional tools.

(3) Objectives + Sources As for the second case, we will have here a very good CMDB, focused on objectives, with integrations when these could be done and replacing old ineffective solutions to make sure users will not need to do the job twice. We carefully paid attention that the CMDB will be perceived as an effective solution. But without taking into account the maturity, we have basically forgot users who will primarily use the CMDB!

• Either we nailed it and the CMDB is perfectly maintained automatically. The solution just tells the truth about any CI we are tracking at any time. However this is rarely the case or the scope is very narrow. With such a CMDB, the user will be given hands on something that exceeds its competences.

The right balance between objectives, maturity and well leveraging on available sources of information is key to successfully implement a CMDB in ServiceNow. This is valid for a phase 1 but also for following iterations. Five key success factors 1.

Always start small and expend later

2. Always think about users and train them when necessary 3. The “Return On User Investment” should be positive. The CMDB should help users. 4. Spend time to do some conceptual work, 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. To conclude, I would add that if what is being done is too far from the standard, we should question ourselves whether we are doing the right thing. ServiceNow is no stranger to the ITSM business and they are just embedding in their platform best practices.

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

40

INTEGRATION WITH CMDBS/MDRS As mentioned at the beginning of this chapter, a key question to answer is “What sources do I have at my disposal to help me populate/maintain the CMDB?”. The maintenance process will be covered in details in chapter 4 but when implementing a CMDB, there are great chances that a management tool, containing valuable information for the CMDB, exist somewhere:

•

MDR (Managed Data Repository)

• Or another CMDB, external to ServiceNow Beside ServiceNow, these solutions will continue to live and are potentially automated themselves (thus ensuring high quality data) and it would be a pity not to leverage on them to help maintain data in ServiceNow.

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

• ServiceNow Discovery • ServiceNow Service Mapping (previously Nebula) Both of theses solutions will be introduced in more details in the next chapters. The first challenge that will be faced when integrating ServiceNow CMDB in an organization that has multiple CMDBs or MDRs will be dealing with the overlap of two sources and the reconciliation of data. The following diagram represents a potential situation:

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

In this use case, we can see that multiple sources overlap. The network source with Discovery, SCCM with Discovery…etc. The concept is that for each classes, a SSOT should be defined (Single Source Of Truth). Some classes will be manually maintained and therefore their SSOT is manual inputs. Some others will get most of configuration information from a MDR and therefore, if agreed and decided so, it becomes the SSOT. When we have an overlap, there must be a source that takes precedence over the other(s). A matrix similar to the following one should be defined and documented: Example:

• Class “Computer” (cmdb_ci_server) • Sources are SCCM and Discovery

Source

Order

Action

Attributes

SCCM

100

Create/Update

All

Discovery

200

Create/Update

All

In the above example we consider SCCM being the SSOT as it has the smallest order. We also consider it can create and update records but we don’t specifically list attributes it has ownership on. Discovery has the exact same setup but a highest order because it is not considered, for this class to be the SSOT or the most accurate source. The second challenge will be about reconciliation. Now that there are 2 sources and that the SSOT is defined. How does each source recognize if a CI has to be inserted of if the CI exists already and has to be updated? For hardware CI, usually the serial number is used as it is known to be pretty unique worldwide. Nevertheless, depending on the source, other attributes may need to be used such as the MAC address, an IP address or the hostname. Each of these attribute may be formatted slightly differently from a source to another (especially the MAC address) and it needs to be addressed somehow. Until the Geneva release of ServiceNow, there was no real magic tool for this and each data source needed to be configured with a transform map in which the reconciliation rule needed to be configured/scripted.

42

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

Document data source precedences for each classes in scope

2.

Document reconciliation definitions (which source can update what attributes)

3.

Review and eventually adapt CI identifiers

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

43

SERVICENOW DISCOVERY

ServiceNow Discovery is an agent-less solution

The biggest advantage of the solution is that it is

that will scan your network on regular basis for

already pre-configured to be capable of

any kind of connected device. It works in a 4-

discovering most devices an organization would

steps process:

be interested in having in its CMDB. In addition to

1. Shazzam: scan the network and discover connected devices

that, it is agentless and therefore does not require any intervention on devices prior to being able to populate ServiceNow. The main challenge will be

2. Classification:  try to define what kind of

the broadness of the out-of-the-box scope of

device has responded following pre-defined

probes. If you plug and play, the result might be

pattern (i.e.: if the device responds to WMI

more useless than useful due to the huge amount

queries, it must be a windows machine…etc.)

of information it will bring back to your

and gather information about the device.

S e r v i c e N o w i n s t a n c e . H o w e v e r, w e l l implemented, the solution is very powerful. Some

3. Identification: reconcile the device and

key success factors:

gathered information with an existing CI in the CMDB. 4. Explore: get more information about the device such as running processes if applicable or some deeper information on the device itself.

1. PLAN PLAN PLAN ServiceNow Discovery should not be the solution that will magically do the job people had to do prior to its implementation. It is not the solution that will make the organization discover magically

ServiceNow being a SaaS solution, in order to be

devices they own. It’s a solution to support users

able to discover devices/equipments, the solution

in the configuration management process but not

relies on what is called a MID server, which is a

replacing them. Before anything, study the

small Java program running on a server within

network topology of the organization. The primary

customer’s network and capable of executing

reason for this is to plan how many of those MID

various kind of jobs.

servers will be needed. These should be deployed strategically within the organization’s

I would call this approach "bottom-up” or

network to ensure that the scanning will be

“horizontal discovery” (as ServiceNow would call

complete. It is a common mistake to not plan this

it).

accurately and thus ending up with partial

44

discovery with MID servers not able to “see”

CMDB is used across a whole bunch of

everything they should.

processes, primarily incident, problem and change management), it is hard to do a U-turn if

2.PRIORITIZE

six months down the road, we realize we did not do it right. It is then best to start small and simple.

Define what’s most important and key. On a

Take the time to validate the result. And finally,

network, there could be lots of different kind of

continue with multiple phases to expand its usage

devices. Not all of them are relevant in a CMDB

based on priorities.

and more specifically, not all of them relevant within a network range/subnet. When Discovery has to scan a certain IP range within a datacenter, what are  the most relevant devices Discovery has to see? Probably servers, routers, switches…etc. In order to put in practice this priorization, key functionalities with Discovery are behaviours, credentials and functionalities. On a per phase and MID server basis, it can be controlled what accesses are granted and what protocols should be used in order to make sure we keep control on the scope of the scan. In addition to that, the configuration console is easy to use to control what main discovery functionalities are enabled or disabled.

3.START SMALL AND

4.DON’T UNDERESTIMATE THE DESIGN PHASE In a CMDB project, designing is key. For Discovery it is the same. For each phases of the project, no aspects of the implementation should be neglected. Implementing the solution can be difficult and challenging in some organization’s environment. Implementing Discovery requires talking to many different SMEs within the organization who all have different requirements which can be constraints for the project. It is also good to manage well in advance expectations. Security aspects of the solution should be discuss at early stage to make sure everyone is aligned.

SIMPLE AND EXPAND LATER This is repeated many times when implementing ServiceNow. One of the main reason for this is that it is easy to do something with ServiceNow in comparison with other tools where careful design an planning need to be done. It is too easy to go too fast and put into production something not fit for use or purpose. With ServiceNow Discovery, because data it creates has great visibility (the 45

SERVICENOW SERVICE MAPPING

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

Horizontal discovery vs. top-down approach You basically give Service Mapping an entry point: URL or IP address of an application. The solution will do the rest. It will scan the host if necessary and then explore it and try to understand what kind of application it is. This is done using a set of pre-configured pattern (out-of-the-box, but new ones can be created). If a pattern match, it will create the CI in ServiceNow and act accordingly. In Service Mapping there are two distinct phases: 1. Identification of the application  2. Connectivity discovery

46

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 connections are found anymore. How does that fit into our CMDB? What Service Mapping is doing very well is creating a map of an application with technical dependencies. Technical dependencies, to be accurate, also means going down to a very granular view. This might not fit into a configuration model, where for instance, we focus on the application as a whole (the application, the application server and all potential small elements…etc.). The level of details Service Mapping is bringing to ServiceNow is just too high if it had to be maintained manually. But there is no magic behind Service Mapping. The tool does not have the judgement of a human being and capable of simplifying a hierarchy of elements. It just does what we tell it to do. We could modify its behaviour by heavily customizing all the out-of-the-box patterns but we would be loosing on its added value and, above everything, that would not be a good practice. The answer is that the audience or the usage of the information Service Mapping is bringing to ServiceNow is slightly different than the rest of the CMDB. The big plus of Service Mapping is its usage in conjunction with an event management integration. The dependency map is displayed with a timeline and because it is refreshed on regular basis, allows the user to go back in time to check the state of the application or see what has changed. Events are displayed in this timeline. KSFs listed for Discovery are also valid in the context of Service Mapping: 1. Plan plan plan: technologies are the same, MID servers need to be at the right place as well. 2. Prioritize and start small: focus first on the most important/critical applications (3 or 5 to start with I would say).

47

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

Even though not trivial to setup, it is feasible to have mulitple abstraction levels in the CMDB In the above figure, the level of information about the ESX environment might not be useful to everyone. The main elements can be integrated into the standard configuration model view without caring about all the details. The same applies with the application “ABC”. This can be achieved when configuring the BSM map which is presented further in this ebook.

48

3

PROCESSES Once the CMDB is in place, it should not  be static. The content of the CMDB needs to be maintained or updated and for some areas, as much 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 impact one or more service offering(s). The change request needs to be approve by all people it concerns (thus the reason for having good data in your CMDB because that will be the source to define these people) and once it is

49

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 review of the CMDB are performed. The objective is to ensure data matches the reality. If it does not match the reality, it has to be referred to change management (either something was implemented/ installed without change request or the CMDBwas not updated properly following a change request). What we see is that both processes are very

objective of configuration management is to ensure 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 re-align its content based on the reality. I like to compare it to an Inertial Navigation System (INS). The system knows where is the vehicle based on how it is moving but from time to time, we need to realign it with the reality and re-position the system at the correct coordinates. For configuration management, the movements are change requests and on regular basis we go have a look at our datacenters and re-align the CMDB to the reality.

much imbricated. As for all processes, the

CMDB maintenance process

50

CMDB audit and verification process

Note that in the above process flow, we are only

stakeholders means that both sides can evolve at

talking about update. The reason for this is that

a different pace and have a different level of

configuration management is only about CIs that

maturity which is often what is witnessed. Often

exist already (at least in an ideal situation). When a

configuration management, traditional and a base

technician installs a new switch or install a new

ITIL process, is more mature than IT asset

workstation, the device is not new but exists

management (ITAM). Therefore we, in practice,

already in a stockroom. If it does not, then the

often put in place solutions that permit asset

device needs to be purchased and that part is not

management process actions within the perimeter

part of configuration management but request

of the CMDB and configuration management such

fulfilment and asset management. This process is

as the creation or the retiring of  CIs. By retiring,

presented in the introduction and in the next

we mean the “elimination” of the device and not

chapter, it will be explained where the border lies

putting it back in stock.

between the two process, again, 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 small organization there could be overlap between roles and responsibilities). Different 51

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

Asset, configuration and change management interactions

52

Role

Process

Description and responsibilities*:

SA

Change (CM), problem (PM) and incident (IM) Management

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

CC

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

53

Role

Process

Description and responsibilities*:

PO

Configuration Management

Process Owner: • • • • •

Defining the purpose, objectives, scope, as well as principles and CSFs of the process Designing and sponsoring the process throughout the organization and stakeholders Ensuring selected process indicators are collected, analyzed, and acted upon Driving the 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 owns the process, meaning she/he is the ultimate responsible for its performance and objectives and has the authority to change it. CA

Configuration Management

Configuration Administrator: • • • •

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

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

Configuration Management

Configuration Manager: • • • • • • • •

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

The configuration manager runs the process operationally. This means running the audit and verification process, keeping an eye on unauthorised changes and ensuring data is up-to-data and driving the CMDB maintenance.

54

Role

Process

Description and responsibilities*:

AM

IT Asset Management

Asset Manager: • •

• • •

•

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

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

* Responsibilities within the perimeter of configuration management. Non-configuration management roles have, of course, other responsibilities than what is listed here.

55

ASSETS AND CI LIFECYCLE

It is good to start by differentiating two big 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 appears or disappear very quickly following mainly change requests whereas the latter will go through, normally, a proper purchasing process and start their lifecycle as being in a stockroom.

The border between what should be done as part of the asset management process and what is done as part of the config./change management process is not always clear. But in essence, the below diagram basically depicts where the lifecycle of the two categories of elements introduced earlier are managed. For physical or hardware elements, the lifecycle starts in asset management. When one of these element is installed or in use, the lifecycle continues within the CMDB (configuration management or change management process). In the end, physical elements eventually finish their lifecycle ending up in a stockroom, awaiting to be scraped or sold.

Lifecycle of abstract/virtual assets is much shorter than for physical assets 56

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

A CI/asset could also be represented as a coin. With one face being the asset side and the other one the CI side 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 unpack from its box. What matters is really financial aspects of the element. The latter do not care about the financial aspect but how the element will interact with the environment he is responsible for from the time the element is unpack from its box and plugged. The only financial aspect of a virtual or abstract element is the software license, and it is the only aspect managed as part of the asset management process for this category of elements. In order to manage this lifecycle, ServiceNow has out-of-the-box a set of install or hardware status in the CMDB and a set of install status and 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.

57

USE CASES

1.

Managing the lifecycle of a CI and presentation of the out-ofthe-box ServiceNow approach

2. Managing multiple environments and presentation of an approach The first use case has been selected for this ebook because organizations understand the importance of the configuration model but tend to forget that once CIs are populated in the CMDB, they have to be managed. And managing CIs also means properly following ITIL processes (change and configuration) because not everything can be done automatically with Discovery solutions. A discovery solution will be able to tell you if something is on the network or not but do not tell you what you have in stock and more importantly, does not tell you why a CI has suddenly appeared or disappeared in the CMDB. The second use case is about environments around the application and service layers. Sometimes it is not clear whether non-production environments should be tracked in the CMDB and how to position the border between what is considered as production and what is not. This use case tries to answer these points and proposes an approach.

58

HOW DO I MANAGE THE LIFECYCLE OF A CI This question was probably partially answered in chapter 3.2. In ServiceNow, to keep it simple, in the context of this ebook, we have two 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 impacting the same data (again, to keep it simple and make abstraction of the database complexity of ServiceNow) So the question is who does what and when? What we often witness at organizations is a gap between real processes in place (even if not formalized) and what an asset or configuration  manager has to or can do in ServiceNow. In all companies, before a hardware device of any kind physically exists, it has to go through some kind of purchasing process. And this is the trigger for the introduction of new hardware/consumable assets/ configuration items in the ServiceNow database. For software licenses, which are also assets, this is also valid but they do not have one-to-one counterpart in the CMDB (the closer we get is the software instance). Though managing software licenses is a process in itself thus we will not take this into account here nor expand on this topic. Here is a table of the activities around the lifecycle of a hardware asset/configuration item: #

Activity

Process Involved

ServiceNow Module

Outcome

1

Purchase of a new hardware device

Purchasing

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

59

#

Activity

Process Involved

ServiceNow Module

Outcome

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.

60

#

Activity

Process Involved

ServiceNow Module

Outcome

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 retired

Asset Management with inputs from contract management

Asset Management

The asset is updated with the corresponding “Retired” status: • Donated • Sold • Disposed

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

Install

b.

Move

61

c.

Add

d.

Change

e.

Decommission

4. Stock management (including transfer between stockroom and to/from installation sites) 5. CMDB audit for compliance, correctness and completeness 6. Decommissioning For each of them, it should be identified how it is done and where. Typically the purchasing process is often not done directly in ServiceNow but in an ERP. Therefore it should be identified how we get data in ServiceNow from this process. Ideally a process should be formalized but it is most likely not going to be the case as part of the CMDB implementation.

HOW DO I MANAGE MY DIFFERENT ENVIRONMENTS Essentially all configuration items should be in the CMDB independently whether they are supporting a production system or a DEV/TEST/QA environment. Some of these CIs will also most likely be used by multiple environments at the end of the chain. Furthermore, they have a cost and need to be managed somehow, that would usually justify the fact we need to track them. How do we manage this? Generally, when we talk about environments, we are referring to a non-production instance of an application. In this case, an environment in the CMDB will in the end be modelled as a dedicated application and service or service flavour (service 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 2 different services or, and most likely, one service with 2 different offerings, one for DEV and one for PROD (see bellow illustration).  It is also important to be aware of the following differentiation to be made: 1.

Configuration items supporting a specific environment

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

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

Prod vs. nonprod environment representation in ServiceNow

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

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

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

63

4

NOW CMDB AND ASSET FUNCTIONALITIES Besides the theory of the why we implement the CMDB in certain manners, there is also the tool. This section lists the most important features of the ServiceNow platform that leverage on a correctly structured CMDB.

CMDB HEALTH

As we saw in the chapter dedicated to processes, configuration management is essentially a reactive process with request for maintenance coming from change management and proactive checks with regular audits performed on the data hosted in the CMDB. The reactive part of the process is pretty clear but it is less about the proactive part of the process. How do we perform regular audits and verifications in the ServiceNow CMDB? This chapter has been named “CMDB Health” but it is not one single feature of ServiceNow but more an umbrella name under which we have the following functionalities: 1. The CI Class Manager: it is essentially a configuration panel consolidating different new and existing functionalities as well as giving shortcuts to system properties and data dictionary. 2. The CMDB/CI dashboard: CMDB-wise and CI-specific dashboard are available. The first can be accessed through the “Configuration” application of ServiceNow. The later can be accessed through the CI form, using a toggle switch in the header of the form. It is displaying the result of correctness, completeness and compliance KPIs. 3. The “Compliance” application: it is the application where ServiceNow data audits can be configured (this is not only available for the CMDB). This application is leveraged in the latest additions to the CMDB by ServiceNow and the CI class manager gives access to some configuration tables of this application. In previous releases of ServiceNow, the “Configuration” application was mostly a set of classes in which we could store 65

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

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

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

66

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

When

Feature

Correctness

On regular automatic checks

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

Correctness

At creation of CIs

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

Correctness

On regular automatic checks

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

Completeness

On regular 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 is basically making sure 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 the 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.

67

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

The CI/CMDB dashboard The CI/CMDB dashboard is where a configuration manager can check the overall completeness, correctness and compliance status of the CMDB or dig in more details, getting statistics for a particular class. The CMDB dashboard is accessible via the Configuration application. The new CMDB dashboard, introduced with the Helsinki release of ServiceNow

A CI specific dashboard exists as well and is accessible via the header of the CI form: The CI-centric dashboard toggle available in the header of an CI class record

68

Similar information are then displayed specifically for the selected CI:

The CI-centric dashboard

69

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

Description

Versioning

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

Codeless template definition

Templates allow to define what checks will be performed on a given filter. It does 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 created without the need of writing 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 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 ebook) and are accessible contextually from follow-on tasks (a follow-on task related to a windows server will only show remediations available for windows servers).

Scripted audit

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

70

DEPENDENCY VIEW

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

The dependency view also has a dedicated application in the left-hand side menu of ServiceNow. This is because it does not only displays CIs and CI relationships but it can include the following main functionalities:

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

Functionality

Description

Map 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 setup by a ServiceNow administrator but a typical usage of this is in incident management: based on the “context" of the incident (the service), the user can display a map, see all underlying CIs, right-click on one of them and set it as the impacted CI (see also next functionality).

Map Indicators

Map indicators are used to add little badges next to CIs in the dependency view to highlight the ones that have outages, incident problem, 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 covering the configuration model). But in the CMDB, many CIs also have one-to-many relationships (references). Some of them might be interesting to see in a dependency view and these can be configured here.

72

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

73

CHANGE MANAGEMENT


Change management is probably the process that is the 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 dedicated sub-chapter, the following features will be presented: 1.

Proposed change

2. Impact analysis 3. Change conflict analysis

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

At the creation or initiation of the change, what will be changed from a CMDB standpoint is documented using the proposed change functionality.

2. The change is performed, in real life. 3. Once the change is implemented and reviewed, the proposed change, initially documented during the initiation phase of the change can be applied to the CMDB in one click. This feature works with the affected CI related list, displayed at the bottom of the change request form. The change coordinator or 74

whoever documents the change request can right click a selected 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 The proposed change functionality is accessible when right clicking on the affected CI list of a change request

Proposed change overlay

The proposed change functionality is displayed as an overlay where it is allowed to configure/ document what will be changed for a given CI This feature is often overlooked by organizations but in fact, if a good configuration model has been defined, and a good work on each classes was done in terms of attributes. This is a relatively simple thus powerful functionality that can greatly help maintaining and up-to-date CMDB. 

75

CHANGE IMPACT ANALYSIS The change impact analysis functionality is  simple and very powerful. But the functionality will only work if a proper configuration model has been put in place and if the CMDB is correctly maintained (either manually or automatically via integrations). CI relationships in the CMDB have a specific direction as they are used to model a dependency: they have a parent and a child. The change impact analysis functionality will take as input one or more 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 this until it finds a service potentially impacted. Impacted services  are then documented in a related list on the change request form. This documented list can then be used for instance to: 1.

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

2. Ease the selection of change approvers 3. Further analyze the change for potential conflicts (see next chapter)

Change header context menu action

he impact analysis functionality is accessible when right-clicking on the header of the change request.

76

Impacted services related list

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

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

CHANGE CONFLICTS ANALYSIS The change conflicts analysis functionality of ServiceNow will basically checks that a the planned change dates are “compatible” with the immediate environment of all 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 the following:

• A change that falls during a blackout period (a period during which nothing should be undertaken • A change that does not fall during a maintenance window • A change that falls at the same time as another change with the same affected CI (2 changes at the same time on the same CI) These three potential type 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 the above rules

77

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

Change related link action

The conflicts analysis functionality is accessible through a related link in the change request form


 Informational message and information on the change record itself

The system keeps track of the last time a conflict analysis has run The conflicts analysis functionality is accessible through a related link in the change request form

78

Change conflicts related list

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

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

79

5

GLOSSARY ITSM

Information Technology Service Management

ITIL

Information Technology Infrastructure Library

KISS

Keep It Simple and Smart

CMDB

Configuration Management Database

CSI

Continual Service Improvement

SME

Subject Matter Expert

KEDB

Known Error Database

MDR

Managed Data Repository

KSF

Key Success Factor

CRAC

Computer Room Air Conditioner

UPS

Uninterruptible Power Supply

SAN

Storage Area Network

NAS

Network Attached Storage

DAS

Direct Attached Storage

MSD

Mass Storage Device

CI

Configuration Item

VLAN

Virtual Local Area Network

ERP

Enterprise Resource Planning

RFC

Request for Change

ITAM

Information Technology Asset Management

KPI

Key Performance Indicator

BSM

Business Service Management 80

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

www.fruitionpartners.eu [email protected] or find Fruition Partners’ nearest office at fruitionpartners.eu/where

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

81