Research shows that only 15% of CMDB implementations are successful, so it is no surprise that many businesses bypass CMDB if they can. But experience has taught us that a CMDB is a vital part of successfully implementing best practices in the asset, incident, and change management spaces. 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?
We caught up with one of our experts at Crossfuze, Mark Brownschidle, to better understand not only why this happens, but also why the successful implementation of a CMDB is vital to Business Service success.
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 an Asset perspective, it has attributes which are mostly financial in nature, for example, the cost of the laptop, the length of the warranty, and how it appreciates or depreciates over time. There is another side to this also. The CI record associated with your laptop contains operations 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, where it becomes discoverable, allowing 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 are tracked in CMDBs. 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, track application usage, software licenses, specifications, device 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 the cost of an asset, but also where it comes from, and how it is being used. Understanding the usage of any device helps determine whether 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 among 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; all those service offerings we need to deliver to be a successful business.
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 to manage and track 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 among 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, when my discovery tool is set up, it finds twenty desktops and ten servers in my IT space, then it means that these devices are already on my network. I would then need to start mapping the relationships among those devices 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 identifies all these connections and how they relate to each other.
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 Management leaders, 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 online form.
Q: How does a CMDB 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?
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 don’t understand the difference between ‘services’ and ‘service offerings'. A Service is a grouping of similar offerings, which are presented to the users in a way which makes it easy for them to find what they need. For instance, you might have a Printing Business Service that provides wide format, narrow format, color, black and white, bound, or unbound printed material. Each of those different types of printing is a distinct and different Offering, but all are part of the Printing Business Service.
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.
Business service relationships are broken down into four layers. At the top are the users, who are the individuals who utilize your service. They “look” into 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, 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 per 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, and more interested in how the service relates to a 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 when issues arise, they know how to fix them.
Lastly, we can also take a holistic view of how the cycle works from the view of an ITSM team.
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, we would recommend mapping out all the services you offer and ranking them into three tiers by “following the money”. For example:
Q: How do CMDBs impact business decisions?
When a CMDB is not set up or maintained properly, the information it provides may be misleading. This means that when troubles start occurring, the source of the issue isn’t clear, which can lead to extended troubleshooting times or bad business decisions based on the faulty information.
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, along with whatever automation is available, to ensure people can do their jobs in a way that keeps that data correct.
For example, if you are in procurement, part of your job is to make sure that when you go out and buy something, an asset record is created 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.
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 are the biggest savings opportunity. This business 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 key areas 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. This can be a big problem—many companies have tried to track this manually and failed, which can result in compliance failures and significant fines.
Q: How can companies make the transition to a new ITSM solution smoother?
To make the transition, process is key. Successful companies have best-practice Incident, Problem, and Change Management processes in place, as well as an Asset Management program, a solid CMDB, and robust policies and procedures to 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.
Q: Any closing thoughts?
While a CMDB is an enabler for better process across the board, you can exist without it - and that is what a lot of organizations are doing. They implement Incident Management and Change Management and improve their results considerably. But to get to the next level of maturity, companies must consider the future. Rapid business growth becomes a problem without CMDB. For any progressive company looking to accelerate their growth now rather than later, a well-structured and maintained CMDB is a must-have.
* CMDB Systems: Making Change Work in the Age of Cloud Agile, Drogseth, Sturm and Twing, 2015.
If you have questions for Mark about CMDB, reach out by emailing LetsTalk@crossfuze.com.