I’ve always been a visual person, so initially I really wondered whether configuration management was for me. When I first started with it, it seemed to be all lists, relationships, and an awful lot of exporting data into spreadsheets. After a while, I got the hang of it and wondered if there was an easy way to represent all the configuration item (CI) relationships that were being created and managed within our configuration management database (CMDB). But we were still very early in our configuration management journey so we didn’t have any off-the-shelf IT service management (ITSM) products or tools to utilize.
Configuration Management Database visualization for free
What I did have, however, was experience of using a free library called D3.JS (a JavaScript library for manipulating documents based on data, with the D3 standing for Data Driven Documents).
I’d previously seen this tool used to map data lineage in a data warehouse and I started tinkering. I should say at this point experimenting with this is not easy, and any sort of software development/computer science knowledge is certainly going to help here.
To help, I would recommend looking at the examples page which shows some interesting takes on visualizing data (including my personal favorite – an interactive, zoomable sunburst representing coffee flavor profiles).
But what next?
Well, this was all good. I had the Configuration Management Database data. I had a wide variety of visual skins that I could apply over it. But then I realized I had missed the first step – understanding what I wanted/needed to show with the data!
Thankfully, I remembered something that I had picked up in my previous life in architecture roles that would be useful here – the concept of viewpoints.
Essentially, as data can be viewed many different ways, a viewpoint is a reflection of how you would diagram/model the data and a view is that diagram complying to a specified viewpoint. Makes perfect sense, right?
Maybe an example will help. I’ve shamefully taken the example viewpoint below from TOGAF and more details on views and viewpoints from TOGAF are available here.
Structure really does help
Now that I had a structure for defining how the data could be viewed, I starting talking to key stakeholders (who would be consuming the data) about what they would find useful and then built up a library of viewpoints based on this.
This was one of the toughest parts of the Configuration Management Database exercise but definitely the most useful. Speaking to people about what is useful to them came up with some interesting ways of seeing the data plus a framework for defining them (in my case, viewpoints).
You never know what people want to see and we ended up experimenting quite a bit. Some of which worked, some not so much.
One of the more ambitious experiments was to create an interactive bubble chart by organizational unit with the total cost of ownership (TCO) of all their services, hardware, software, etc. The bubble size would be linked to the TCO and clicking on the bubble would “pop it” – showing all the hierarchical organizational units contained within the “parent.” I’ll be honest – this one never got done, although I’d still love to see the data visualized in this way. Sadly for now though, the effort involved was a little too much.
Key configuration management and Configuration Management Database learnings
In doing this experimentation, we started to find that the more data you needed to use that wasn’t explicitly contained within the Configuration Management Database (or aggregated from it) – meaning that we were adding and manipulating data outside of the Configuration Management Database – the more there were issues.
It also meant that the data being added wasn’t shared with other systems that take a feed of information from it, therefore losing value. In the end we came up with a key operating principle:
The method of visualization should never use data not taken from the Configuration Management Database
Another learning was that using D3.JS for visualization was too difficult – but don’t lose heart – and we instead found an opportunity to visualize the data by linking the information with our Architectural Repository. However, the existing work on the viewpoints was still absolutely key and continued to be used as part of the ongoing work.
How you should approach visualizing your Configuration Management Database
As a summary, here is how you should approach visualizing your Configuration Management Database:
- Identify your method for visualization (D3.JS, a COTS package, Visio, etc.)
- Build up a library of viewpoints in conjunction with key stakeholders
- Prioritize the delivery of outputs based on complexity and benefit
- Never add or amend Configuration Management Database data in the process of visualizing the data.
If you’re looking for inspiration on the ways in which to visualize your Configuration Management Database data, I would recommend some of the examples from D3.JS. I would also recommend the books “Information is Beautiful” and “Knowledge is Beautiful” which, although not related to ITSM, brilliantly take large data sets and turn them into infographics. Both books are by David McCandless.
Mark O'Brien
Mark has more than 10 years’ experience in the finance industry, working in a diverse set of IT roles including Software Development, Solutions and Enterprise Architecture and more recently Service Management.
A chartered member of the BCS and qualified in ITIL, TOGAF, and other Architecture qualifications, Mark has spent the last 3 years working on finding opportunities for service management and Architecture to work together across strategy setting, the change portfolio and operational needs.
Outside of work Mark’s main interests include record collecting, running, Bike trekking and the RNLI.
