Configuration management is about collecting and maintaining useful information. In IT service management (ITSM), this means knowing about everything from hardware and software through to documentation and people – all of which is used to deliver services. We collect and hold data about those items, including information on how they are connected together.
Configuration management itself is way older than ITSM, with its roots firmly in old-fashioned engineering. Although we don’t know the equivalent term in Ancient Chinese, Egyptian, or Mayan, I guarantee that configuration management was being done in those times. They all must have understood the principles in order to get the Great Wall, the Pyramids, and Stonehenge right. And those creations look relatively simple compared to the bridges, ships, and railroads that mechanical and civil engineer Isambard Kingdom Brunel and his successors were building – and crucially also maintaining – in the 19th century.
Of course the world has changed but there are lessons from that old engineering perspective that still have value today. At the same time, we should be very aware of how configuration management needs to be different for our new IT- driven world.
At first sight Configuration Management seems to be telling us to capture as much data as possible. After all, you can never have too much data can you? Big data is still a valid fashion goal for ITSM, so configuration management capturing as much data as it can sounds like the right approach.
In fact, however, pay attention in your ITIL® Foundation course and you’ll learn otherwise. ITIL teaches that there are situations where we shouldn’t gather configuration data, such as:
And besides these things we might choose not to record, we should also learn to accept that that there are some things we simply will never be able to capture.
These concepts and caveats were central to having reliable configuration data in the past, certainly pre-IT and also in 20th century IT. Back then everyone recognized that some items simply could not be monitored with sufficient frequency and accuracy to keep the information up-to-date and relevant. The driving thought was that it was better to know you didn’t know, than to think you knew and be wrong, making decisions on false inputs.
There is an argument for that concept – of some items being unmonitorable - being out-of-date and no longer a concern or, at least, much less of an issue nowadays.
With modern software tools, we can automatically find software and hardware across our multinational infrastructure, and our tireless technology can look for updates and changes several times a day if we wish. Nowadays, the internet of things (IoT) can even come and tell us when things have changed, not waiting to be asked by the software but proactively enthusiastic to tell us. And the plummeting cost of processing and storage means maintaining the data should be so much less of an issue.
Configuration concepts – like variants – that made sense in the past are no longer sensible with modern data systems allowing multiple views into a single set of data. Variants were a popular exam question in ITIL V1 and V2 days, but disappeared when V3 arrived – a sign that the guidance does evolve J (and if you never needed to learn about them, don’t do it now, it doesn’t matter anymore.)
Technology has provided us with the ability to capture and hold just about everything, but maybe there’s still logic and reason in not capturing some things. I mean, besides the technology we still need processes and people to turn the data into something useful, right? I’d say that keeping technology, processes, and people in balance is one of the skills that differentiate good ITSM organizations from the rest.
There are a few things to consider when looking at how the almost limitless data can be used:
The still relevant underpinning question to all of this remains: can we turn the data we capture into information and then into knowledge? Because only then is it useful, and that takes us back to some of the configuration management thinking of earlier days.
While the technology might make it possible to capture any data we can possibly conceive of, we still need to ensure the processes and people, who are part of our ITSM organization, can cope and make sense of it – fast enough and accurately enough to be useful.
Hitting everything may be effective, but it’s rarely as efficient as aiming for what is needed. Knowing what to aim for comes from understanding what is to be achieved. There is still value in knowing why you want to know something before you start recording it, and that is still driven by the priorities of the organization as whole. Maybe we still need to ask ourselves the same question our parents did – what configuration data will offer us the best value? And use that as our starting point.