CMDB: Why It’s Vital To Progressive Growth

Research shows that only 15% of CMDB implementations are successful*. So it is no surprise that many businesses bypass CMDB, and jump right into incident management. But experience has taught us that a CMDB is a vital part of successfully transitioning into the asset, incident, and change management space. In fact, research has shown that IT organizations with application dependency mapping solutions, applied to change management, are twice as likely to be successful in deploying critical IT business services. ** So why is it that CMDB installations go so horribly wrong?

I sat down with one of our in-house ServiceNow experts, Jack Kosoff, to discuss not only why this happens, but also why the successful implementation of a CMDB is vital to Business Service success. Before we dive into the intricacies of service mapping, a process that is absolutely vital to successful CMDB implementation, let's first understand the basics.

Q: Let’s start with some basics. What is a CMDB?

A configuration management database (CMDB) is a repository that acts as a data warehouse for recording the details of Configuration Items (CI) and Assets. An example of a CI or asset would be the laptop that you're working on right now. From a leadership perspective, it has some asset attributes which are mostly financial in nature. For example, the cost of the laptop, the length of the warranty, how it appreciates or depreciates over time. There is another side to this also.

The CI record associated with your laptop will also contain information about how big the hard drive is, how much memory is being consumed right now by the applications that are being run on it, as well as what applications are on it, and who is using the laptop. It goes even further to explore what you are using it for.

When a new CI is purchased, it needs to be added to the network of IT assets to be discoverable and allow ITSM Managers to track usage, application licenses, etc. But it’s not as simple as just plugging it in. When a new asset comes in, it's not usually ready to put on your network. Instead, it will need to undergo some configuration i.e. you’ll need to install certain programs on it and set up permissions for various applications. All that configuration information is then recorded in the CMDB.

But laptops are only one example of the assets that CMDBs keep track of. CIs also include assets such as servers, printers, and other storage/network devices.

Q: Why is a CMDB important?

The CMDB allows you to organize your IT assets, tracking application usage, software licenses, specifications, usage, value over time, etc., providing detailed information for every device.

The important thing to remember with a CMDB is that its primary purpose is to keep track of the state of different assets in your IT environment; devices that can be expensive and are acquired to better service our business objectives. When those assets are put into operation, they become CIs - and CIs need to be tracked.

Q: What are the critical elements to understand with CIs?

The first thing we need to note is the information we currently have about the CI, and how the CI relates to other devices in our IT environment. A successful CMDB is built on those relationships.

Asset Management involves not only knowing how much an asset costs, but also where it comes from, and how it is being used. Understanding the usage of any device helps determine whether or not it is delivering ROI.

CMDBs are vital because they house the asset and CI records, acting as a vessel for tracking information, recording usage, and mapping relationships between other assets, such as software licenses, within the IT Service Management space. 

Q: How do CMDBs facilitate better IT services?

IT Service Management (ITSM) is the concept of delivering business services or offerings to users either inside or outside the company. In every business, it’s up to the IT department to provide certain capabilities to various arms of the company, so that they can do their job effectively and efficiently. For example, ITSM provides things such as email, Intranets, time capture or timesheet tools; essentially, all those service offerings that we deliver to our customers internally or externally.

However, to be able to keep track of all the devices, software programs, applications, and licenses that are required to deliver those services, we need to have a system in place that manages and tracks those fundamental tools as they work together to provide the service. That’s where a CMDB comes into play.

Q: How do you successfully build a CMDB?

CMDB is all about setting up relationships between assets and establishing processes. Typically, there are two ways to build a CMDB - from the bottom up or the top down.

In a typical enterprise IT environment, there are thousands of devices that work together to deliver services to internal and external users.  If you’ve already built an IT environment and have a discovery tool in place that can search and find all the assets in that environment, then you can build your system from the bottom up by collecting all that information into a central repository, essentially your CMDB. You can then build out the relationships among the assets manually or using automated discovery tools.

For example, if when my discovery tool is set up, it can automatically find the twenty desktops and ten servers in my IT space, then it means that these devices are already on my network. I can then create a “see it” record in ServiceNow that allows those items to be discovered automatically. I would then need to start mapping the relationships by exploring how each workstation is connected.  I might see that the laptop I currently send email from, is running the Outlook application that connects to Exchange which runs on Server 1. Server 1 uses storage capability on storage network X and is connected to the database at Y. Automated discovery will be able to identify all these connections and how they tie back to the database. 

A top-down approach is more manual (unless you have an automated service mapping tool like the one available from ServiceNow), and depends on identifying your Business Services and Service Offerings up front. Using this information, it is then possible to map the relationships looking from the Offering to the application which delivers it, to the database that supports the application, to the server on which they run.

It’s worth pointing out, though, that starting with the service and using a top-down approach is best practice, and even without the use of automation from tools like ServiceNow, it is the most efficient and effective way to set up business services in the IT space.

Q: What is the importance of device mapping?

For the most part, the network of connected devices that enable the service is irrelevant to the end user. They don't need to know that we have an Exchange server that runs that e-mail application, or that we have a big storage device that stores all the user records, or various network devices that connect all those things together. However, as IT Service Managers, it’s relevant to us.

Mapping services, assets, and applications, whether from the bottom up or top down, helps businesses identify where things have gone wrong with services when issues crop up. For example, if a user’s email isn’t working, a CMDB can help identify the cause of the malfunction (which is known as an “Incident”).  Users can report Incidents using a simple on-line form.

Q: How does a CMDB help to improve reporting?

The CMDB is the heart of all IT processes. If something is ‘broken’ in the network, or an ‘incident’ occurs, the technician will first look at the Business Service Map in the CMDB to determine which device or connection in the network is causing an interruption in the service.  Having this tool can significantly reduce troubleshooting time.

Any business which has earned the title of ‘service excellence’ knows that excellent service is about solving problems quickly, and getting services back up and running with little or no downtime. A CMDB ensures that errors are tracked and reported in real time, helping to keep downtime to a minimum. In some instances, automation can also be set up to reroute errors automatically so downtime is ‘zero’. This approach allows ITSM Managers to then examine and fix the problem without interrupting the user.

A CMDB also helps IT determine whether reoccurring Incidents are the result of a bigger problem. For example, if I purchase a batch of twenty new laptops, and one person reports that the battery on theirs only lasts for 20 minutes, I would replace that battery, assuming it is the result of a single faulty battery. If a few weeks later, I then analyzed my Incident data and discovered that five people reported the same issue, I can look at my CMDB to find common attributes of those devices that are malfunctioning.  In this example, I discovered that all the faulty batteries were in laptops which were purchased on the same PO. Therefore, I can conclude that the entire batch was faulty, and I would contact the manufacturer or supplier for compensation. Without a CMDB, it would have been much more difficult to determine the common root cause.

Q: What is the most common problem IT teams have when setting up a CMDB?

Well, the biggest problem is that most people don't have a clear understanding of the definition of ‘business services’. They tend to confuse ‘services’ with ‘applications.'

For example, when you ask someone what their business services are, many times they'll tell you Outlook is a business service. But Outlook isn’t a service. Outlook is the application that facilitates the service of email.

Another challenge we see quite often is that companies tend to see ‘services’ and ‘service offerings' as one and the same.  

I had a client years ago, let’s call him Mike. Mike worked in the printing business and wanted to implement a CMDB to reduce downtime and increase efficiency across their IT network. He said that they had all their business services mapped out and all we had to do was just drop them into ServiceNow. I got super excited because I’d never had the opportunity to work with a team who was so organized and fully understood the dynamics of an enterprise IT network.

When Mike handed over the list he’d created, however, it became pretty clear that he didn’t understand as well as I had hoped. On the list he had itemized each type of printing; color printing, black and white printing, wide format printing, etc. as a separate service. I said to him, “Mike, each of these items falls under one service, and that service is printing.” It took some time before he would agree with me, but once he realized that the device mapping for each was the same, ding. The lights came on.

Q: What tricks or tips can you share to help IT teams better differentiate between services, service offerings, applications and infrastructure?

An excellent way to look at is by asking yourself, “How would a potential customer navigate through my catalog to find the particular service they needed?” It’s likely that, in the printing example, if they wanted to do black and white printing, they would first look under the section on printing—the service—and then look through the offerings to identify the specific type of printing i.e. black and white.

Here’s a diagram I typically use to help IT teams, and their users, better understand the relationships between users, services, applications, and infrastructure.

CMDB 1

Business service relationships are broken down into four layers. At the top, sits your Users. Users are the individuals who utilize your service. Below users sits the Business Services layer, where the services themselves and various service offerings live. Using the email example, the Business Service in this layer would be ‘email’ and the various offerings would be the types of email, for example, Outlook, Yahoo mail, or Gmail.

In the third layer sits the technical components: applications and database services. This is where your applications that facilitate the service come into play. For example, Exchange, or iMail. Your web services, databases, and various virtual network devices also live here. In the printing example, this is where your ‘printing queues’ would sit.

Finally, in the bottom layer is where you will find your infrastructure. This includes the physical and virtual devices that run those technical components, allowing you to deliver those services. For example, your servers (physical and virtual), your network devices such as laptops, your printers, etc.

We can also segment these relationships according to roles and responsibilities matching layers against the individuals who are most likely to be interested in them. This view is useful because it helps you to identify the level of detail required to service each of these individual user types.

For example, Business Managers are less concerned with how a service is delivered, just that the service relates to a particular portfolio for which they are responsible. A Service Desk Agent on the other hand, needs to know which applications are being used along with the devices that facilitate them so that when issues arise, they know how to fix them.

CMDB 2a

Lastly, we can also take a holistic view of how the cycle works from the view of an ITSM team.

CMDB 3

All of these layers are what make up the CMDB. For the most part, IT teams will use a hybrid approach that combines both top down and bottom up efforts to create the necessary connections between the components in the IT space. Automated discovery through applications like ServiceNow make this process faster and more efficient, using best practice principles based on years of ITSM network experience. It also reduces the likelihood of errors occurring.

Q: Any advice on how businesses can prioritize their services?

Any business looking to implement ITSM, specifically CMDB, should use the data to decide which services take priority. So, in the instance of our Printing company, the clue is in the name. Even if they did offer other services such as design, printing is their primary service offering, so that should be the priority when planning which services to map out first.

For larger enterprises, I’d typically suggest mapping out all the services you offer and ranking them into three top tiers. For example:

  • Tier 1 – Bread and Butter services. These are your high income services. Services that, if they stop working, mean you lose money. Tier 2- Ancillary services. If these services go down, you lose money although they may not be your highest earners.
  • Tier 3 – Supporting services. These are services which impact few users at a time, or which can be offline for a period of time without significant impact on the bottom line.

Another way of prioritizing is by ‘following the money.’ If I can't make any money without a particular service, that’s my Tier 1.  If I can make money but I’ve got to scramble around to do it, that’s Tier 2. If it doesn't impact my ability to make money but it's just annoying, that's Tier 3.

Q: How do CMDBs impact business decisions?

When a CMDB is not setup correctly, the information it provides may be misleading. This means that when problems start occurring, the source of the issue isn’t clear. This inevitably leads to bad business decisions based on the assumptions that the CMDB was setup correctly in the first instance.

Typically, when you set up relationships between devices, you need to vet them to make sure they're correct. Once you’re confident that the knee bone is connected to the shin bone, then you need to design and implement robust policies and procedures to ensure people can do their jobs in a way that keeps that data correct.

For example, if you are in procurement then part of your job is to make sure that when you go out and buy something you create an asset record for it. All the data that is appropriate to the asset will be in that record. The person responsible for configuring the device will follow a set procedure to configure it correctly.  When that device is deployed onto your network, your discovery process will report the changes to the configured hardware and applications (software) as changes occur.

If the CMDB hasn’t been done correctly, and let’s say you’ve purchased twenty laptops half of which have developed issues, you may not be able to accurately analyze why they are having problems. You might assume that every laptop you’ve bought from that particular supplier will develop an issue. You might then recall all of the devices purchased, leading to increased expenses, lost time and compromising your relationship with your supplier, only to find later on down the line, after you’ve purchased another twenty, that it was a mapping error.

Q: What should companies think about when considering implementing a CMDB?

Determine what your critical success factors are and use those to drive your decision to implement now or later. If, for instance, a company’s highest priority is to reduce the cost of software licenses, understanding who is using what, when, and how often, will help them to determine which applications, if any, may be building shelf dust. They should consider implementing Software Asset Management in their CMDB. If other priorities are higher, the CMDB implementation could be delayed in favor of other processes. But remember, it’s only a question of timing – a CMDB will eventually be required to facilitate continuous improvement, by providing accurate data and intelligence that can be applied incrementally to ensure continuous growth.

Q: Are there any real sticklers that ITSM Managers should keep an eye on when considering/implementing a CMDB?

With most tools, and ServiceNow is no exception, it's critical to have your product models in place and a solid understanding of how various devices within your network relate to each other i.e. CIs, services and assets. A reliable map is a key to a successful implementation.

Another issue to look out for is software titles. There are a lot of different product variants available. For example, Microsoft Word can have up to 50 different variants in the market. But Microsoft Word is only one application of ‘Microsoft Office Suite.' So you need to ensure that you are accurately recording and tracking these variants and understand whether you purchased 50 Word licenses or 50 Office Suite licenses, or a combination of both. This is particularly important for compliance purposes. In most instances I’ve seen, this has been a big problem—where companies have tried to track this manually and failed, which can result in falling out of compliance and potentially ending up with a huge fine.

Q: How can companies make the transition to a new ITSM solution smoother?

To make the transition, companies need to have successful Incident, Problem, and Change Management processes in place, as well as an Asset Management program and a solid CMDB, along with robust policies and procedures that support it.  ITSM teams need to ensure that ancillary processes such as procurement, receipt asset tagging--all those things that people don't usually associate with asset management--are in place and are correct. They are critical because if you don't have a good match in your procurement system, then your asset data won’t be correct. Suddenly CIs will appear on your network, and you won’t know where they have come from or what they are.

Q: Are there any tools available to make the mapping process easier?

Yes. Most ServiceNow partners can configure the ServiceNow platform to improve function out of the box. Crossfuze is unique in that we offer several Turnkeys including Asset Management, Incident Management, Change Management and a CMDB Turnkey that uses best practice methodologies (and already built code) to help you organize your model structure and map your product relationships. All of these Turnkeys help you deploy best practices faster and more efficiently. 

Turnkeys use state-of-the-art programming techniques, specific to the ServiceNow platform, reducing time to delivery and decreasing costs for implementation. For instance, the CMDB Turnkey can recognize duplicate CIs and provide real-time reports that help you immediately identify lost or faulty connections in your existing frameworks. This drastically improves reporting and the quality of data that can be measured against planned KPI’s, CSFs and business objectives.

Over time we’ve learned that the relationship mapping of services is similar across multiple companies and industries. That’s why Crossfuze Turnkeys come with a series of updatable templated process maps.  The need to tweak and change the template varies on a case by case basis, but we typically find that with a Turnkey template, in some cases as much as 80 percent of the configuration is already done. This varies, though, depending on the clients unique need.

Q: Any closing thoughts?

The CMDB is an enabler for better process across the board.  However, you can exist without it. And that is what a lot of organizations are doing. They implement incident management and change management and through that, have improved their process considerably. But to get to the next level of maturity, companies have to look into the future. Rapid business growth becomes a problem without CMDB.

For any progressive company who is looking to accelerate their growth now rather than later, I would say that from experience, a well-structured and maintained CMDB is a must-have. 

Some useful links:

Interested in using the images in this blog for your presentation regarding CMDB? Get them now, pptxclick here.

If you have ServiceNow and would like to check out our Turnkeys and save up to 40% with our end-of-year promotion, click here.

ServiceNow offers some very useful resources to help companies on their CMDB implementation journey, click here

Crossfuze also offers up a Business Service Tracker Turnkey that makes identifying and tracking the status of new services, much easier. Have a look at the video, click here.

Want to dive deeper into CMDB with Jack or others at Crossfuze? This email address is being protected from spambots. You need JavaScript enabled to view it.

 

References:

http://www.forbes.com/sites/sungardas/2014/10/22/why-85-of-companies-fail-at-creating-a-cmdb-and-how-to-escape-their-fate/#4132ac7d66f4

** CMDB Systems : Making Change Work in the Age of Cloud Agile, Drogseth, Sturm and Twing, 2015.

 

Leave your comments

Post comment as a guest

0
terms and condition.

Comments