Who’s afraid of the CMDB?

In the Star Trek universe, a master systems display (MSD) is the screen that appears behind Worf in “The Next Generation,” in the table in main engineering where Geordi La Forge hangs out, and in many other places in the ship. It also appears in other series and movies. (For instance, Kirk and Spock go over the damages to the ship after Khan attacks the Enterprise in the second, and best, movie.) It’s conveniently used as a device where characters would gather around and discuss how to get the Enterprise out of a pickle.

In my home office, I have a poster of the ship that represents a master systems display screen (it would be cool if it were interactive) and as I watch it daily, it got me thinking. You see, aside from being used as a plot device, the MSD is a representation of the ship’s CMDB.

As we know, the configuration management database (CMDB) is that logical place where we list all of the assets that are in the infrastructure in support of a particular service. We may have multiple CMDBs under a logical structure that ITIL v3 calls the configuration management system (CMS). I’m staying close to ITIL v3 best practice. I’ve not yet seen if this changes with version 4. The one thing that makes the CMDB work, though, is the fact that it captures relationships between the configuration items (CI) within. That is, server X connects to route Y and is in rack Z, and so on.

This is precisely what the MSD is in Star Trek: a visual representation of all of the items in the ship, and its relationships. The anti-matter injectors are in the warp core, which provides power to propulsion, life support, the transporters, etc. It’s a good example of how a CMDB might be built, and how it delivers value. So, I want to expand on this and propose a different point of view to you, dear reader, so maybe you can see the CMDB in a different light.

The MSD is well scoped

What is the scope of the MSD in Star Trek: The Next Generation? The starship Enterprise. Full stop. It’s not concerned with things that are not within that scope. There are relationships with external entities (Starfleet, for example) but while it’s out there, the ship operates on its own. In IT, I’ve read and seen many CMDB ‘projects’ fail because it’s not well scoped. So how do you scope your CMDB?

Enterprise has a clear-cut mission

…and we all know what it is: “To explore strange new worlds.” In order to meet this mission, Enterprise has to provide the means to its crew to perform the mission: survive the harshness of space, explore, communicate, fight when necessary. These are the ships vital business functions (VBF). In business, often this is not understood, and this affects the scoping of the CMDB. Particularly, it makes the CMDB a technology project, as opposed to a business project. Understanding what the business does, and how it delivers value to its customers, helps with the definition of the CMDB.

It’s visible, and open

Watch any Star Trek episode and you’ll see the MSD everywhere. It’s on the bridge, on main engineering. Data can see it in his quarters and so can the Captain. It’s information that everyone can consult at any time (it can be safe to assume that there are security restrictions. You don’t want an alien ambassador looking at the MSD without him/her/it being vetted). Since many companies treat the CMDB as a technology project, that’s where it stays: at the IT level. Why not make it visible, within reason, to everyone in the company? Some people will not necessarily understand the technology, but they’ll know what’s happening.

The MSD provides for better decision making

Because everything is related to everything in the MSD, this enables people to make better decisions. Under attack and need to re-route power to shields? With the MSD you can safely see where to grab the power from. In IT, having this visibility is vital, and it’s not always clear. Since this visibility doesn’t always exist, diagnosing for incidents is difficult. Same goes for assessing changes.

It’s the living history of the ship

On the poster I have at home there is a statement that reads: “Note: views incorporate Starfleet Yard changes from stardates xxx to yyy, plus authorized field repairs, replacements, upgrades, and equipment abandoned in place”. This is important, as it recognizes that there are frequent changes to the ship’s systems and that what you see there is a true representation of the now. This is dependent on an established change management practice that works closely with the configuration management practice and CMDB. (I’m pretty sure that by the 24^th century change management works better than now. Hopefully. Maybe?)

Here’s the thing: building a CMDB is not a technological project. It’s a management project that needs to be tied to the business and its VBFs. I’ll say that the tools are the least important thing to consider here. Many, if not all, of the leading IT Service Management tools support the creation of a CMDB within it in one way or the other. Not one is better than the other in this regard. How do you start? Couple of tips:

• Remember, it’s a management project first. Don’t get hung up on the technological aspects of it at the beginning.
• What is the company’s mission and VBFs? Become familiar and understand what is it that the company values. For example, say that I’m the CIO of a supermarket chain. I understand that the VBFs of the company is to make sure we a.) get paid when customers buy their items and b.) we get merchandise into their hands as quickly as possible. No need to get fancy or complex. You can also put it this way: what is it that we do as a company that if we fail, we’ll be in trouble. Go with that.
• It’s OK to ignore stuff that’s not a VBF. Continuing with the supermarket example: do I care if email goes down for half an hour on a Saturday? Maybe. But I care more if our point of sale systems go down for half an hour on a Saturday. No point of sales means missed sales, angry customers and reputation loss. I’m not saying that you don’t capture information of services that do not deliver value. There has to be a priority and a hierarchy. This, of course, needs to be consulted and agreed to with the business stakeholders.
• Focus on outcomes. This is another way of scoping a CMDB. In a supermarket, the point of sales systems are essential, so is inventory. The outcome of those two services are clear and unambiguous to the company: one enables the company to collect money, the other to move merchandise around. Always consider IT services against the company’s VBFs.
• Visualize it. This can be a fun exercise. Before you even set out to do it on a tool, draw it out. Grab a big paper or a whiteboard and draw it out at a high level. No need to go down to server specs, version numbers, etc. Draw it at a very high level. Use your imagination or use a technique such as this one.

If you’re intimidated by the thought of building a CMDB monster, don’t be. It’s easier than you think. Having issues with your current CMDB? Take a step back and go back to the drawing board and improve it. You owe it to yourself and your organization to build something that enables better decisions.

Need some inspiration? Watch yourself some Trek. Or reach out.

Have fun!