In the Star Trek universe, a master systems display (MSD) is the screen that appears behind Worf in \u201cThe Next Generation,\u201d 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\u2019s conveniently used as a device where characters would gather around and discuss how to get the Enterprise out of a pickle.\nIn 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\u2019s CMDB.\nAs 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\u2019m staying close to ITIL v3 best practice. I\u2019ve 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.\nThis 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\u2019s 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.\nThe MSD is well scoped\nWhat is the scope of the MSD in Star Trek: The Next Generation? The starship Enterprise. Full stop. It\u2019s not concerned with things that are not within that scope. There are relationships with external entities (Starfleet, for example) but while it\u2019s out there, the ship operates on its own. In IT, I\u2019ve read and seen many CMDB 'projects\u2019 fail because it\u2019s not well scoped. So how do you scope your CMDB?\nEnterprise has a clear-cut mission\n\u2026and we all know what it is: \u201cTo explore strange new worlds.\u201d 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.\nIt\u2019s visible, and open\nWatch any Star Trek episode and you\u2019ll see the MSD everywhere. It\u2019s on the bridge, on main engineering. Data can see it in his quarters and so can the Captain. It\u2019s information that everyone can consult at any time (it can be safe to assume that there are security restrictions. You don\u2019t 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\u2019s 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\u2019ll know what\u2019s happening.\nThe MSD provides for better decision making\nBecause 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\u2019s not always clear. Since this visibility doesn\u2019t always exist, diagnosing for incidents is difficult. Same goes for assessing changes.\nIt\u2019s the living history of the ship\nOn the poster I have at home there is a statement that reads: \u201cNote: views incorporate Starfleet Yard changes from stardates xxx to yyy, plus authorized field repairs, replacements, upgrades, and equipment abandoned in place\u201d. This is important, as it recognizes that there are frequent changes to the ship\u2019s 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\u2019m pretty sure that by the 24th century change management works better than now. Hopefully. Maybe?)\nHere\u2019s the thing: building a CMDB is not a technological project. It\u2019s a management project that needs to be tied to the business and its VBFs. I\u2019ll 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:\n\nRemember, it\u2019s a management project first. Don\u2019t get hung up on the technological aspects of it at the beginning.\nWhat is the company\u2019s mission and VBFs? Become familiar and understand what is it that the company values. For example, say that I\u2019m 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\u2019ll be in trouble. Go with that.\nIt\u2019s OK to ignore stuff that\u2019s 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\u2019m not saying that you don\u2019t 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.\nFocus 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\u2019s VBFs.\nVisualize 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.\n\nIf you\u2019re intimidated by the thought of building a CMDB monster, don\u2019t be. It\u2019s 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.\nNeed some inspiration? Watch yourself some Trek. Or reach out.\nHave fun!