I had originally intended to make this blog about mental health. A supportive article for those of you trying to support change in your own environment wrestling with the stubbornly persistent caricatures and silos still so dominant in many IT organizations.
It was inspired by a rather nasty line in a novel my one of my favorite writers, Milan Kundera, translated from the Czech—“Nothing is more useless than trying to explain a new idea to idiots.” Feeling this was humorously appropriate to many ongoing dialogs endured by people trying to change the way things are to the way things ought to be– I was going to council patience — in something of a self help mode directed in part of course at myself.
My first step was to look at ITIL’s notion of “configuration management “and the many (so many!) roles associated with it as both of guidance and encouragement and an absurdist form of purgatory. It was triggered by a vendor briefing with a set of powerful options targeted at the so-called “configuration manager.” I mentioned that while I had spoken to many people with that title- -who often shouldered a heroic form of evangelism across their organizations—they typically came from other skill sets with very defined, tangible interests – e.g. architects from Infrastructure and Architecture Services, or in some cases more executive roles with strong cross-domain and communication skills.
When I opened ITIL’s “Service Transition” to revisit role definitions, however, I was stopped in my tracks. I was reminded once again of why there is such a love/hate relationship with ITIL—and why it is, in its own words, such an excellent “departure point,” and so often such a poor endgame.
ITIL’s “Service Transition” meticulously lists and spells out service asset manager, configuration manager, configuration analyst, configuration administration/librarian, CMS/tools administration and change manager– as just some discrete roles (implying separate individuals) not to mention other discrete roles such as performance and risk evaluation manager and service test manager ad infinitum.
Reading through the list of these responsibilities is, on the one hand, an excellent way to codify process requirements and break out steps in terms of managing change. On the other hand, when viewed as separate protagonists in a Hollywood cast of thousands, these “roles” could easily create such a massive bureaucracy that nothing could ever get done. (One of the telling verbs in, for instance, the Configuration Manager’s role is “agrees”— meaning presumably that he or she better not disagree or else there could be hell to pay.)
Needless to say, even in large companies, these roles tend to be collapsed into generative functions with architectural skills, coordination functions with good communications and process skills, and administrative functions—which only makes sense. And in many smaller enterprises, even these can be collapsed into one tired, overworked superstar—almost all of whom teach me something new every time I speak with them.
But aside from the massiveness of this ghostly bureaucracy- there is something fundamentally wrong with the language and concepts in ITIL when it comes to “configuration management” in my opinion. And that is – it lives at a level of haunting abstraction without consistently reflecting the fact that there are hard and fast skill sets, often with unique domain expertise requirements— needed to make any of this meaningful. The processes of configuration, release and change management means nothing without strong architectural skills and a tangible awareness of application or systems, or network design points.
And this gets to ITIL’s term “configuration management” and the notion that it’s a discrete discipline in itself. In my experience, it isn’t. Rather, it is a disciplined “mindset” shared across a team of individuals who realize the need to understand, capture, model and optimize physical and logical interdependencies in support of desirable service outcomes. The CMDB and CMS emerge when leadership is given to this “mindset”—once again usually by someone with strong architectural and communication skills armed with administrative support (e.g. database skills) and executive backing.
So what about mental health in facing all the very human and political obstacles surrounding the above?
ITIL can be part of the cure—if taken as a reference – or part of the problem in my opinion—if taken too literally. One has to be glad it’s there because there is tremendous insight captured in its peculiar and sometimes foreign language. But it won’t replace, for instance, Milan Kundera or other outside-the-box thinkers who keep a sense of humor and a deep understanding of human futility in the forefront of how they write and think.
Which makes me wonder what ITIL must be like in its original Czech.
Related Links:
