June 27, 2014
Managing Configurations in IT's Future
Configuration Management continues to both seduce and strangle IT organizations, despite the documentation of ITIL. What we're frustrated with is not the process of configuration management -- instead, we're frustrated with the procedures. Organizations need guidance on how to get procedural complexity in line with the justifying impact on the business. Alignment increasingly means understanding who has the architectural capabilities (both design and investigation) to do the procedures efficiently, and getting them to do it as a service to other necessary types of management.
Let's review "process" as well as history. Imagine the chaos that would result if bookkeeping was removed from financial management. We can easily show that investment forecasting and risk management are distinct from bookkeeping and closer to "generating business value" in some sense, but it is just not viable to do them without bookkeeping. The value of the bookkeeping process is not ambiguous, nor optional, to the responsibility of business finance.
What has always been aggravating about configuration management is that it is a process looking for a procedure without being able to warn us how hard the procedure will be. The process is simple; the procedure is often wickedly complex. The process can be described in five bullets; the procedure can be described in hundreds of pages and/or millions of lines of code. Even if the procedure was easy, doing it reactively has been necessary because of a weird, circumstantial flaw in the logic of operations. What flaw? The flaw is that systems engineering did not include, inherently, change alerting as a prerequisite of item deployment into *systems*. We've been relying for decades on ever-newer technology to fix that flaw, and now making fantastic progress as "sensors" (in many different forms) start coming into their own and data analysis can keep pace with sensor data streams.
But the fundamental management logic to be respected is going to stay the same in the future as it has been in the past, and ITIL neither owns it nor invented it. In non-ITIL language, Accountability is exercised in order to support Quality, in order to support Risk, in order to support Capacity, in order to support Capability. It's why we stick to the recipe, follow instructions, and do testing on things we make before we give it to someone and tell them that they can rely on it to live up to what we say they can do with it. It's the same story whether we're talking about meals, physical fitness, buildings, cars, or networks...
"Configuration" is just a fancy word meaning "how it was composed to behave the way we intended". If we say we will not manage that, then we're saying we don't care how it was composed, or how it will behave, or both. Once any pretense of reliability is gone, then the idea that it has utility is... well... wishful, and of course, mostly risky.
But change happens, affecting reliability. Configuration change is sometimes on purpose and sometimes not, so if utilization is a source of changes to configuration, then utilization must be managed -- which is the science of Administration. Administrators have *always* asked engineers to make things in a way that would make those things easy to administer!
Here's the key point: we don't do configuration management of things that were not "built to a design for a purpose". The problem is that we are forced to do configuration management on things that are not securely restrained to the purpose of their design. Automation offers the prospect of increasing the "secure restraint" by making it more persistent in real-time and also operationally simpler. So it would seem that we'll be herding the cats less.
But automation will still leave the significant pressures of on-demand use, innovations, variable performance targets, and the political side of asset management. In other words, the things that are thought to typify efforts that "generate business value" will predictably require us to do other things that make managed change a reasonable effort.
What we're frustrated with is not the process of configuration management -- instead, we're frustrated with the procedures. Organizations need guidance on how to get procedural complexity in line with the justifying impact on the business. Alignment increasingly means understanding who has the architectural capabilities (both design and investigation) to do the procedures efficiently, and getting them to do it as a service to other necessary types of management.
Posted by Malcolm Ryder at June 27, 2014 3:04 PM