Getting started with your Configuration Management Database (CMDB)

This is part one of a short series of articles about CMDB best practices. Below, we introduce what a CMDB is and start to introduce its benefits. 

What is the CMDB? 

The Configuration Management Database (CMDB) records how you deliver services. You may offer connectivity services, desktop support, website hosting - everything that supports those services and makes them possible is stored in the CMDB.

In particular, the CMDB stores Configuration Items (CIs). A CI may represent a router, a service, an application or a virtual machine. Or, it could be a logical grouping, such as a portfolio. Furthermore, each CI is connected to others via relationships.

Every CI contains support information, such as its name, which team supports it, and how critical it may be. If it is a physical device, its location is also stored.

Purpose of the CMDB

The CMDB is used throughout IT Service Management processes (ITSM), from incident management (what CI is failing), to problem management (what's the root cause of the CI failing), to change management (lets adjust it so the CI stops failing and make sure nothing else is affected), to knowledge management (documentation on how the CI may fail in the future, and help to fix it) and many more.

Some people worry that implementing a successful CMDB to help all these processes is a complex - or even overwhelming - task. It doesn’t need to be. CMDB implementations typically fail because people aren’t clear on their objectives or try to go for a “big bang” approach.

If you take a structured “crawl, walk, run” approach, you’ll begin to see benefits very quickly.

"Tales from the service desk..."

 

A long time ago, we wanted to upgrade an old workhorse of a server. It was starting to struggle as the number of users increased. These days, you’d probably shift the workload onto a more powerful host with a few clicks, but back then, the upgrade was a physical one. The problem was, we couldn’t find it. We could ping it, remotely connect to it, but no-one knew where it was physically located. No-one could find it in their racks.  Eventually, we tracked it down, but a good CMDB would’ve saved us hours by telling us exactly where it was. (In this case, a cupboard in a remote office, and was swiftly relocated somewhere more sensible.)

Why do we need a CMDB?

A good CMDB provides accurate and reliable information that powers your ITIL service management processes. By knowing what makes up your services, in turn, you enable better services.

Let’s look at a common scenario, a service outage.

An application isn’t responding and hundreds of users are affected. How do you figure out what’s wrong and get the service back up and running quickly? Has someone upgraded the application recently? Is it the server, or is there a problem with a database halfway around the world? Is there a network problem? 

So many questions and so little time. Without a CMDB, you don’t even know the application version, which server it’s running on, or which databases it’s talking to. You spend hours gathering information - assuming that you can find it - and meanwhile the clock is ticking.

At this point, the value of a CMDB becomes painfully obvious. It gives you instant access to the information you need to quickly resolve the service issue, including infrastructure relationships, service topologies, change histories, software versions and more.

This is just one example. A CMDB can help you to drive positive business outcomes across a wide range of operational processes. It can also support and improve many other business areas - for example, it can help you to reduce service delivery costs, maximise the ROI of your application portfolio and accelerate time-to-market for new services.

What are Configuration Items (CIs) in a CMDB?

The type of information contained in the CMDB includes accurate and reliable information about digital services and the infrastructure that supports them. To do this, the CMDB stores information that describes components - “things” - in your operational environment that are involved in the delivery of digital services. Each component is represented as a Configuration Item (CI).

Each CI has multiple attributes that contain specific information about the component it represents. CI classes are arranged in a hierarchy, with each subclass extending the attributes of its parent class. For example, a Linux Server CI class inherits all the attributes of its parent Server class and adds Linux-specific attributes.

CIs also have relationships. For instance, an application can run on a server, or a web server can depend on an upstream load balancer. The CMDB stores these relationships between CIs, along with the relationship type (depends on, runs on, etc.). Note that these relationships are not the same as the class hierarchy - the hierarchy specifies inheritance between CI classes, whereas relationships are between CI instances (e.g. web server “X” depends on load balancer “Y”).

Is a CMDB a list of servers?

Many organisations start with their CMDB being technically orientated. And that is a great first step: understanding what servers, network devices, database and application servers you have and where they are does deliver valuable insights. But understanding what they do and deliver is the next step.

CIs can be broadly grouped into two main categories: 'infrastructure CIs' and 'service CIs'.

• Infrastructure CIs represent capabilities provided by physical or logical components such as servers, routers, application software, cloud resources, and so on.
• Service CIs represent digital services and are typically delivered by the infrastructure CIs.

In ServiceNow, there are three types of service CIs, representing business, application, and technical services:

• A business service supports a business capability - such as managing customer orders - and is consumed by business users. Business services are typically underpinned by one or more application services, i.e. a business service can include multiple applications.
• An application service is a full application stack - for example, a stock inventory system that supports the customer order management business service described above. It isn’t just the application - it’s all of the distributed components that make the application work. This is what we typically think about when we talk about a digital service.
• A technical service is a technical capability that underpins one or more application services. For instance, multiple application services - including the order management system above - could all use a common storage service. And that's the technical service.

"Tales from the service desk..."

 

We’d just had a catastrophic power failure. Our monitoring screens were a sea of red. But which ones should we focus on first? Thanks to our CMDB, we knew: lets get the finance and payroll systems back online so we could be paid on time. Perhaps a flippant example, but understanding which services are supported by which devices is crucial information.

What's the Common Service Data Model (CSDM)

The Common Service Data Model (CSDM) is a series of guidelines from ServiceNow that helps you to organise your data efficiently and effectively, to fully enable the capabilities of the platform. This includes tracking information such as contracts, entitlements and benefits. POPX has a wealth of experience in using the CSDM to help build the right CMDB for your business. 

My finance team has a list of assets. Is this a CMDB?

CIs and assets are often conflated, since a piece of expensive kit like a physical server is indeed both a CI and an asset. But this doesn’t always hold true. Asset management is more interested in the CapEx financial aspects of your devices, while CIs are about delivering services.

For example, a virtual cloud server may host one of your important applications. So it should be represented by a CI, so it can be controlled and supported effectively. But, it wouldn’t typically be an asset, especially if it is an on-demand virtual machine (VM), since you don’t need to worry about replacement, depreciation or maximising the utilisation of it.  

Similarly, a new physical server that you’ve just bought, and is sitting in its box still should be recorded and tracked as an asset. But, since it isn’t supporting any service, having it in the CMDB would just be clutter.

How do I get a good CMDB?

Building a great CMDB is done in stages, and is value focussed. It should always save you time and effort, because the information and controls it provides reduces confusion and improves service levels.