Blogs Featured Blogs Mark Bools Why you’re wrong…
Why you’re wrong… |
 |
| Written by Mark Bools |
| Tuesday, 28 June 2011 02:45 |
|
…if you think build, change, or release management are part of configuration management. Bob Aiello lit the blue touch paper (again) on the debate about ‘what is configuration management?’ and, once again, he seems to be trying to redefine configuration management to fit the role of Configuration Manager identified (incorrectly) in many organisations. This is absolutely the [...]
 …if you think build, change, or release management are part of configuration management. Bob Aiello lit the blue touch paper (again) on the debate about ‘what is configuration management?’ and, once again, he seems to be trying to redefine configuration management to fit the role of Configuration Manager identified (incorrectly) in many organisations. This is absolutely the worst way to define configuration management. Let’s now look at Bob’s list of things he want to dump on CM’s lawn.
This is simplifying CM? In this article I hope to show why this redefinition is unnecessary, flawed, and ultimately damaging to CM. If we were to accept that a discipline is correctly defined by looking at the roles identified in organisations then we would never get anywhere (much like this debate). I for example often have the role named ‘Configuration Manager’ and yes I also do builds, releases, etc as identified in Bob’s list. But then I also fetch coffee for the team and I do the odd bit of development or testing, I write technical documentation, perform product evaluations, project management, risk assessment, and I assist in problem solving for production systems—and yes, sometimes these things (with the exception of fetching the coffee) are part of my official role (although given the current economic climate, who knows). Does that mean these too are defining features of configuration management? No. This is a silly way to define a discipline. Even if you observe that ‘many’ organisations lump the things together it still would not justify redefining configuration management because there’s absolutely nothing to gain, and much to lose, from doing so. Configuration management (the discipline) has a perfectly sound definition (all together now); identification, change control, status accounting, and auditing. To change this definition is to define something other than configuration management and I have no objection to defining an umbrella term to cover all the disciplines identified by Bob; in fact I do, I call them Development Support Services. Yes, we could do more to clearly communicate what CM is. Although, I cannot recall a time when I was ever confused by what the the four core activities were, the difficulty always stemmed from more subtle issues like ‘how do I select good configuration items’ and Bob’s redefinition does precisely zero to address these problems. Adding more complexity by mixing in a load more disciplines is hardly likely to aid clarity. If the idea is that by lumping all of these disciplines under the CM heading we can make CM appear more useful or make it an easier sell to management, then I think that’s horribly misguided too. You: We want to introduce CM. Obviously I’m being slightly facetious, but hopefully you see my point; why complicate things? The manager is now more confused about what CM is than he was at the start. Sure, you’ve made a pitch to create a service team supporting development, but you’re not closer to furthering the CM cause than you would have been had you just reminded the manager about his ITIL course in the first place. You’ve made no real progress in explaining CM, you’ve just hidden it amongst a load of other stuff, possibly to the point of obscuring it completely. ‘But we should move with the times’ is a common enough response. I agree. Let’s draw a parallel to show how it’s unnecessary to abandon the existing definition of CM but still move with the times. Science is decomposed into disciplines. Physicist will often joke (and in some cases only half-jokingly) that all other sciences are ultimately reducible to physics and therefore physics is the only science we need. This seems to be what those who want to lump all these other disciplines into configuration management are set on doing, lumping all the other disciplines into one. And, just as with the science example, it’s a bad idea. Continuing the parallel between CM and science. Just because scientists resist the temptation to mangle all their disciplines together hardly means they’re not moving with the times. Biological science is unrecognisable from fifty years ago, but it’s still Biology. Similarly, configuration management’s scope has increased as we have more powerful tools we can realistically monitor and control to a finer and finer degree of detail. Where in the past a configuration item’s scope would be limited by the capacity of a paper system to realistically track it, we can now declare almost every file in a system to be a CI if we so choose. What Bob (and I’ll use Bob as a proxy for all those who support the view that CM should absorb all these other disciplines) seems to be proposing is something like the following (I’ve reduced the list to just build and release management to keep the diagrams simple, my point is still made I think).
Or, heaven forbid, the following.
In the first case build and release management become intrinsic parts (aggregate into) configuration management. In the second (shudder) they become inner classes, only accessible through the configuration management wrapper. Both of these system architectures are… well. They’re terrible design. If a software engineer came to me with this design I’d fire his ass. (If people are sufficiently interested in me expanding this claim, I will do so in another post.) One observation, made by Joe Townsend, was that the four activities that constitute configuration management are still to be performed within many of the sub-discplines identified by Bob. If this is so, then why not keep the CM discipline separate and have these disciplines use it rather than mangling them all together? What possible benefit is accrued by redefining CM in this way? ‘Oh well, CM is still a part of some of the disciplines we want to put under the CM banner. Erm. No. Wait. The ‘four activities formerly known as CM’ as now part of some, but not all, of the disciplines that now make up CM’. It just makes no sense. It’s adding insult to injury. It’s muddying the waters. You get the idea; you’re doing nothing at all to help clarify CM and your piling in a load of additional stuff that does not belong in there. Let me be clear. If you want to be called ‘Configuration Manager’ and cover all the disciplines Bob identifies, good luck to ya. You won’t be the first, or the last, to do that. Heck, you can take the title ‘Lord of all he surveys’ if you like. Makes no odds to me. My gripe is about redefining the discipline of Configuration Management in these terms. The following diagram shows how build and release management simply use configuration management. A much more elegant structure and one that benefits from modularity, making it much simpler to explain each discipline—also making it simpler to ‘debug’ the processes involved. (The benefits of such modularity should be obvious, but if people are keen for me to expand I will do so at another time.)
It’s simple. It’s elegant. It’s modular. It’s scalable. And IT’S WHAT WE HAVE NOW! (Well, those who have not polluted the well.) Another objection is that this combination of disciplines under the CM rubric is only done for Software Configuration Management (SCM). What! Why? Why do people insist on making this asinine distinction? SCM is ‘Configuration Management of Software’, which, according to the correct definition of CM is precisely the same discipline as, for example, ‘Configuration Management of automotive engineering’, ‘Configuration Management of hardware’, or ‘Configuration Management of X’ for whatever ‘X’ you care to put in there. If you accept the universality of CM principles then the multi-discipline agglomeration proposed by Bob makes even less sense. Most engineering CM systems, for example, have no build discipline within them; the CM discipline is used by fabrication plants to provide reference material (engineering specification, computer controlled tool programs and the like) from which the fabrication plant build the items. The closest these CM teams get to performing a build is assembling a baseline to be passed to the fabrication teams. It is simply coincidental that people labelled ‘configuration manager’ in the software business tend to be qualified to do build management. This is not sufficient justification for putting build management under the CM (or even SCM) banner. Even if you claim justification for putting these other disciplines under the CM banner by saying something along the lines, ‘oh, well CM does not ‘do’ the builds necessarily, they’re just responsible for ensuring they are done’ I say that road leads to perdition. You could justify the inclusion of almost anything you want under the CM discipline using that argument, and you’d be wrong every time. Filed under: CMCrossroads, Configuration Management, ITSLM, Plain Old Blog, Software Configuration Management Tagged: CM, cm definition, Configuration Management, SCM, SCM definition        Author:Mark
Set as favorite
Bookmark
Email this
Hits: 367 Trackback(0)Comments (0)
|
TrackBack URI for this entry
Subscribe to this comment's feed