Why implementing your CMDB will be the best business decision you ever make
When people question why they should go through the time and expense of implementing a configuration management data base (CMDB), they could do worse than Google two words: ‘NHS’ and ‘WannaCry’.
When the NHS suffered the now infamous WannaCry ransomware attack last year, the healthcare behemoth was almost brought to its knees overnight. Some 20,000 medical appointments had to be cancelled, 600 computers were locked down at hundreds of GP surgeries across England and Wales and five emergency centers were put out of action. Losses for the NHS as a result of WannaCry are estimated at £92 million.
Somewhere across the infrastructure an asset owner had failed to update their Windows operating system and the hackers had found a way in the through the vulnerability. By the time they knew they’d been attacked, NHS IT security managers had no idea in which department the machines were, what software they were running and where they were physically located. So, despite identifying the problem relatively early on, they were unable to fix it.
Avoiding downtime with a CMDB
Examples of similar catastrophic hacks, outages and consequent lengthy downtimes are all over the Internet and social media – and the numbers of stories are increasing. Network downtime is not good for business or for the user experience – and any prolonged outage can cause a failure in operations, sometimes proving fatal for an organisation.
Implementing a CMDB gives organisations a comprehensive ‘map’ of their entire IT infrastructure, helping them to keep track of endpoint devices. With an efficient CMDB implementation in place, the NHS could have avoided WannaCry – or dealt with it more effectively when it occurred.
It’s also worth noting that CMDBs are not just a crucial tool for fighting cybercrime, they’re essential to track an organisation’s shadow IT. In a survey of companies undertaking digital transformation programmes, two-thirds of private and public-sector organisations admitted they had purchased new systems and solutions without involving their IT teams, according to the Economist Intelligence Unit. This would not happen if an efficient CMDB was implemented.
A CMDB – the heartbeat of an organisation
A CMDB is essentially the heartbeat of any organisation’s IT department. It’s a rich data base of the assets or configuration items (CIs) that underpin an organisation’s IT services. These CIs can be software, hardware, people or documentation and the CMDB creates transparency by tracking all the CIs, displaying how they relate to one another. A good CMDB gives organisations a holistic view of what’s making up the business services offered to customers.
The system focuses on accessing accurate, up-to-date data, including all the CIs, where they’re held, how they’re configured and the relationship between all of them. The CMDB is the fount of all knowledge, the trusted source of information across the organisation. It’s the truth for anyone to see at anytime.
As the CMDB is at the heart of the organisation, it also needs ongoing nurturing and updating; it should be looked at as a living, breathing entity that brings huge benefits to a business when implemented properly.
Challenges for building a CMDB
Building a good, effective CMDB often creates challenges for many organisations whose IT infrastructure is built on legacy estates. These have never had a joined up, single view. So a key driver is to bring them altogether, the old and the new, into a single place and drive the value out of what they’re trying to achieve.
Furthermore, the reliability of a CMDB is only as good as the accuracy of the information present in the system. If the data is wrong or out of date, the decisions based on that data will be ineffective. In addition, once an organisation decides to undertake a CMDB, they often throw the “kitchen sink” at it, assigning too many different assets from the outset and crippling the CMDB in its infancy.
When people forget to update or make a mistake with inputting data, an organisation immediately starts to lose confidence in the CMDB, often failing to notify the right customers at the right time – this can be hugely embarrassing and costly.
Other problems organisations have when building their CMDB include:
- Problems accessing data
- Attributing the correct roles and responsibilities to the right people
- Ensuring there’s a buy-in at board level to make the CMDB work
- Overcomplicating an already complex process
- Inability to manage CIs effectively because too many are catalogued from the outset.
The benefits of a good CMDB
Along with the obvious benefits of allowing CIOs to view, track and control CIs across the entire IT infrastructure, a good CMDB will include:
- Event mitigation – a reduction in outages and reduced downtime.
- Automation – human error and risk will be mitigated and costs to the business will be significantly reduced.
- Data accuracy – an improvement in decision making results from accurate data.
- Faster resolution times – CIOs quickly understand the CIs relationships across the system.
- Truth – a significant increase in the single source of truth.
- User experience – an overall improvement in end user experience, hence customer satisfaction.
FlyForm's top tips for CMDB design and implementation
- Define your business goals. Start the CMDB design goals and workshops from a business perspective – NOT from a technical perspective. The focus should be on cost savings; what’s in the IT estate and what’s the ability to undertake a comprehensive impact analysis? What are the pain points that have a customer or business impact? Everyone across the organisation needs to understand this so that everyone is aligned to the challenge of building the CMDB.
- It’s important to remember the necessity for a data model in the design phase of the CMDB. How granular do you want to get with your CIs? All organisations need to understand what they’re trying to capture, which assets, who the data owner is and then linking all that back to the business goals. How will all this help the business? The data model then needs to be physically prepared and signed off by the stakeholders before proceeding.
- Governance. Create a configuration management role. That person will then oversee the processes and the platform. An organisation may have a very good model initially, but have not added a configuration management role, or there’s no investment for that role by management. Often the result is that six months later the CMDB is in chaos, the data is not updated or is inaccurate and the value of the system is eroded. The failure to invest in a single source of governance often then involves a very expensive clean up exercise to maintain the CMDB.
- Senior stakeholder buy-in. This is tied in with governance. Someone at board level has to champion this. This is also linked back to the business goals – what is the business trying to achieve? With a big CMDB project there can multiple stakeholders. Here at FlyForm, we’ve seen a room with 30 people – that’s a lot of personalities, different views and challenges. This can cause its own problems, so it’s vital a business has a single person to ensure the CMDB is being done properly.
- A single source of truth. To have all your key data in one single source goes back to the old world where you have a database of disparate information, different systems. By using the ServiceNow platform, the organisation has the benefit of bringing that into one simple plate. Hence, the CMDB view becomes the single source of truth by utilising the multiple source in a single source everyone trusts. This becomes the go-to resource everyone works with every day.
- Don’t boil the ocean. This gets back to the “kitchen sink” metaphor and for many people this is the most important aspect of a CMDB. An organisation – particularly at board level – has to overcome the misunderstanding that within three months they will have reached nirvana. Everything is captured, everything is automated and there’s never going to be an issue. That’s simply not the case. A CMDB needs a phased approach. Start out small and take a particular service or business environment. This can then be tied back to a particular business challenge. Taking a macro approach to building a CMDB can cause problems around costs and complexity and this often results in a lack of governance – no one wants to take responsibility. At Flyform we see a lot of people getting into problems with this.
- Make sure the CIs link back to the business services. Even if a business gets the bottom layer right, ideally the point to all this is to have a business awareness around it. The end users have to understand what the business impact will be, how it will affect them.
- Roles and responsibilities. The configuration librarian or whoever is going to own the CMDB has to understand that this ongoing. Credentials will change, networks will change, so even when you put an automated Discovery tool in it’s not going to stay perfect. An organisation needs someone looking at those dashboards, looking at those services, overseeing the single source of truth.
Here at FlyForm, we’ve come across many organisations that have tried to implement a CMDB in some shape or form. According to Gartner, for US organisations it takes about three attempts to implement a successful CMDB. Many try to boil the ocean, fail to maintain accurate CIs or to invest in a librarian to oversee the implementation and then the day-to-day running of the CMDB.
All this often cultivates the perception that the CMDB is some sort of unattainable entity. But this is simply not true. With the right approach and the right implementation, a CMDB is actually an easy project to undertake. There are indeed huge complex projects, but more often if you get the structure right from the start and go through the correct phased steps, implementation can be simple and successful.