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.

I often describe that there is a big CM and a little CM.

Big CM is the field of Configuration Management which I suggest includes:
* Source Code Management
* Build Engineering
* Environment Configuration
* Change Control (seven different types)
* Release Management (coordination and engineering)
* Deployment

while little CM refers to Configuration Control (of interfaces).

From Bob’s original post to this thread

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.
Manager: What’s that when it’s at home?
You: Oooh. Loads of good stuff. Build, release, change….
Manager: Hang on. We do most of that stuff already.
You: Ah. But we’ll pull it all together under one heading. Make it more coherent. Make it better.
Manager: Create a bottleneck you mean.
You: No. No. No. We’d be specialists.
Manager: So CM is just all this stuff under one team?
You: Oh no. We also do identification, change control, status…. *noticing manager slip into comma* Oh, wait. Remember the ITIL course you went on?
Manager: Oh yeah. That was a great couple of week. Great evenings…. Oh. I mean, yes, very valuable.
You: And you remember them saying you needed a good CMDB?
Manager: Yeees?
You: Well that’s what we’ll do.
Manager: As well as all this other stuff?
You: Sure.
Manager: And what about all the people already doing the other stuff?
You: They’ll be part of my team.
Manager: Hang on. Your team?
You: Of course. They’ll be under the CM team.
…. and so on…

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.

In the course of helping a client look for tools to support their development process I recalled that a couple of years ago I looked briefly at JIRA when building a change control system for another client. So, I suggested we look at JIRA as a possible tool for this new system.

Having looked around the JIRA site I noticed that Atlassian had also taken FishEye (a tool I had used before for providing viewing and analysis tools on repositories) into their stable. And they also support a whole suite of integrated tools that can be used individually or together.

I suggested we take a closer look. So, we set about creating a very simple demonstration of the tools.

I have to say, ‘I’m impressed’.

These are great looking, well integrated, easy to use, easy to set up and very competitively priced tools. Based on a couple of months playing around with them, I’d have absolutely no difficulty recommending them to organisations of almost any size—certainly they should be on your list of tools to look at.

Not only are the tools themselves very flexible and easy to configure but the company seems very keen to hear from their customers. They have open beta programmes and actively encourage users to take part in product development (they really do want to know what their customers want). They also provide really low cost licenses; up to 90 days evaluation licenses and then for small teams (or individuals) they offer 10 user licenses for $10. Seriously! This is a brilliant move. It means freelance consultants (such as your’s truly) can actually use their tools and develop for them, without needing to remortgage the house to obtain licenses. (The tools also don’t require a massive hardware commitment—in fact I’m running a system on a Linux virtual machine on my Mac Pro  and it works great for development and creating documentation/training material.)

Oh, and if you’re a non-profit or open source organisation they will let you have unlimited licenses for free! Genius.

Can’t be bothered with all that setup? Atlassian offer a hosted solution for many of their tools too. (Although I can’t comment on these as I have not tried them, but if they’re anything like as good as what I have seen so far, they’re probably worth looking at if you want a hosted solution.)

The price apart, the tools really are very good. And if they don’t do exactly what you want you can always write your own extensions. Atlassian publish comprehensive developer information and the tools all communicate through open web interfaces and all support a plugin architecture (which I understand Atlassian are working hard to make simpler to use).

Another promising sign is that Atlassian ‘eat their own dog food’. They user all their own tools internally and pride themselves on being the guinea pigs for all their product development. Their own website and online documentation is all run through their own products.

Even better! Atlassian let their product speak for itself. No annoying salespeople calling, no pressure to come along and ‘do a demo’. They just provide you with a really simple way to download their product, get an evaluation license, and then let the product do the selling (no kidding I had downloaded, installed and licensed JIRA in about ten minutes—it took about a day to install, license and integrate the entire suite). Brilliant! [Note to all vendors: if you're product is good then let it speak for you. If you're product needs to be explained, then make it better, provide good online documentation, and provide help when it's requested. I understand that some customer like a demo, but many just want to try out your product for themselves. After all, if it can't be setup and used by their own staff, what hope is there for the future? They just end up being highly dependent on your consulting services. Oh. I think I get it now.]

If, as seems likely, the client goes ahead with this solution I’ll be sure to report back on how these products perform under real life conditions, but for now, go take a look.

The problem with many of the other terms is their absolutism; ‘this is the right way’, a sort of ‘here is the solution, not what was the problem’ attitude. I say, ‘no’. I say that the correct approach is always ‘it depends’.

Contingent CM emphasises that there is no one solution, there is no ‘best’ way to do CM and the core CM discipline is independent of the method, process, approach or dogma to which it is being applied. You should learn the underlying principles of CM, then you can apply it in any arena.

Whenever you are looking at a new methodology or technology. Whenever you are designing a new process or procedure. Ask yourself, ‘what problem does it solve?’. If you can’t come up with a clear well defined answer then the chances are you should not proceed with an implementation.

If you cannot answer the question ‘what problem does it solve?’ then why is the tool, method, process, or whatever needed? If you don’t know why it’s needed, why are you spending time implementing it?

Perhaps my greatest personal challenge is a need to respond in full to forum posts. Lengthy responses are often unwelcome (of even impossible on some forums). People so often want a ‘simple’ answer to a quite complex question. Seldom are there such simple answers and even when there is a simple answer I feel the need to discuss options, to point out fundamentals, and to get the questioner to think about the problem rather than simply adopt some rote implementation based on a simplified reply. I feel strongly that people must understand why an answer is appropriate, otherwise nothing has been learned beyond the most superficial ‘getting it done’ answer. If I don’t feel able to spend time giving a full answer that would satisfy myself, I tend not to offer one at all.

Of course, some technical questions and answers demand such direct and simple handling but again, without understanding, the questioner is simply following a script and when subsequent complications occur they have no idea how to deal with them. Inevitably they return to the forum with a stream of follow-up questions (a sure sign that someone has not understood the answer but is simply following it rote).

Then there is the question of how one keeps up with all the sites that offer community facilities. It’s simple enough to monitor most blogs and forums (well, those wise enough to offer RSS feeds) even though it takes time to read and comprehend what the author is trying to communicate. Other facilities, such as groups on CM Crossroads or web sites without RSS feeds (or some sort of notification system like mailing list), require me to visit them regularly to see whether anything interesting has happened (great for the site’s hit count, sucks for taking up my time). Frankly, it’s hard enough to to keep up anyway without needing to keep cycling through checking for updates. The result of this demand is that I just don’t do it; both I and the community lose out.

Then there are more dynamic community resources like IRC or Twitter. I tend to have an IRC and Twitter client open on one screen just to keep an eye on various resources I find useful or I feel I can contribute to. Mercifully, these tend to be, by their very nature, places where people point to more comprehensive resources or ask very straightforward technical questions. I have occasionally been drawn into protracted exchanges, but generally these resources provide a great way of finding new information without committing too much time. (Of course, the follow up of reading the indicated information can be time consuming ).

This all on top of reading books, journals, and keeping up to date on published papers.

And I still see people comment that ‘there is not much information available’. Where are these people looking?

I suspect that one of the reasons for a lack of contributions to the body of knowledge is people feel rather vulnerable offering opinions in writing on a public forum. Committing your untested view to writing can be a daunting prospect, especially when you lack confidence in your ability to clearly express yourself in writing and your audience is well informed and apparently well established on the forum/site. I know I’d benefit greatly from such a forum, even though I contribute to blogs and forum debates now.

While it is satisfying to exchange ideas in forums or through blogs, it is not quite the same as a more real-time interactive session. There is simply no substitute for sitting down in a relaxed informal environment and talking over a subject that interests you. Things like the ALM Expo help but I think they are still too formal and often little more than a series of marketing pitches by vendors, which is not what I’m looking for. I want a sort of ‘watercooler’ or ‘drinks in the bar’ exchange of ideas.

I want to move away from a stultifying formal environment, where we feel our every word is being judged and consequently we feel the need to be ‘professional’ at all times, into a more relaxed environment where we can have a proper conversation.

To this end I have looked at a number of possible mechanisms for sharing and interacting in real-time.

One obvious method is the webinar. Most webinars I have seen get the format horribly wrong (or rather, they corrupt the format into something so far removed from a webinar that it’s unrecognisable). A webinar should be like a face-to-face seminar (a host makes a short presentation on the topic at hand to stimulate participation, followed by an extended period of dialogue between participants). Most ‘webinars’ that I have attended are little more than a marketing pitch in which the host presents their product (sometimes thinly veiled behind some more general question) followed by one or two selected questions. This format is more like a lecture but would be more accurately described as ‘ad-inars’. Completely useless for what I want, which is a dialogue, an exchange of ideas—in other words, what I would expect from a seminar/webinar.

Then there are broadcast forums such as BlogTV. Again, while this is primarily a broadcast medium, the interactive chat available to all viewers does provide the audience with a means to direct the ‘show’ by asking questions and challenging the presenter. So, perhaps a little more of the dialogue I am looking for; a chance for people to ask questions and challenge the host’s views. BlogTV also has the opportunity to co-host, allowing for the interesting possibility of debates, interviews and the like. BlogTV’s non-commercial nature also, in my opinion, makes it more relaxed and less formal than some other formats.

Another interesting possibility is the chat room style interaction offered by services like Stickam or YouCams. These allow several people to interact via audio/video links while others contribute in chat format. People can “step up to the mic” when a slot is released, making for a fairly dynamic interaction.

These five modes (blogs, forums, webinars, broadcast, and video chat-room) each has merits and shortcomings. I already participate in most of these formats but only the first two in a professional capacity. I find myself dissatisfied with the interactions provided by the forum and blog formats (it’s like having a conversation in slow motion and it takes too long to write the post and then spend time clarifying and resolving misunderstandings that could be cleared up in seconds face to face). So, what about the other formats?

Well, the most obvious problem with each of the other three is precisely their real-time nature. At what time should I offer to take part in them? I have good conversations with people in India, Europe, and the US and these cover a wide range of time zones. To cover all of them would require several sessions. Then there is the matter of when people can take part. Some of you can access audio or video at work, others cannot. Some are willing to take part in these sorts of conversations in your spare time, others are not. To reach as wide an audience as possible, to discuss the topic with as many people as possible and benefit from different viewpoints means running multiple sessions but obviously I want to make each session as relevant and accessible as I can.

How many people want to spend their spare time talking about their profession? When I first thought about this my reaction was ‘not many’, but then I thought, ‘but you want to, there must be others like you’. But maybe I’m just strange? We shall see.

All of this musing lead me to the conclusion that the only way to proceed was to ‘give it a go’. So, over the coming months I will be setting up some open webinars, doing some BlogTV, and coordinating some video chat-room sessions. Some will start with a specific topic, others will be more open-ended. I will try to run sessions at different times in the hope you can join in at least one of them.

If you are interesting in making your own presentation at a webinar (I want people willing to present a 10-15 minute introduction, a well framed question would make a good introduction, to stimulate dialog—no vendor style ‘ad-inars’), or you want to co-host a blogTV session, then contact me and we’ll sort something out. If you want to participate but cannot find a suitably timed session then contact me and let me know your time zone and when would be a better time for you (no promises, I do have to work and sleep too ).

Oh, and if you have any suggestions for topics for these sessions, let me know and I’ll see what I can do.

I will blog, tweet, post to the CM Forum, and announce on the ITSLM Body of Knowledge web site all of the sessions.

Whether I continue with these will depend upon whether people are interested in participating (there’s no point in them if people don’t take part).

I hope to speak with many of you in the near future.

First, complete the Subversion Guru training course. There’s been a lot of interest but most people are deferring the buy option until the course is finished. I understand this position, so I shall now work to finish it (well, perhaps it would be better to say complete it because I suspect it will never be finished as Subversion continues to develop and I continue to find new ways to use it).

Second, and no less significantly, I shall finish the Subversion Guru book. I am now in the ‘grind’ stage of editing, formatting and indexing (although I still find much to be added and equally much to refine).

Both tasks are perfectly possible and with no distractions I see no reason they cannot be completed on schedule.

Right, back to it.

The obvious, and probably correct, answer is ‘probably not essential‘ but if you work in software configuration management it is well worth considering.

Perl is fairly ubiquitous, there are few platforms that do not have a Perl implementation available and it is a standard part of many Unix distributions. Perl code is (with a little caution needed to avoid explicit platform dependencies) portable too, the Tk packages even provide a reasonably portable GUI system should you need it. Perl is a fairly simple language to learn and has a legacy of library code freely available from CPAN that offers a multitude of useful utilities to the SCM practitioner.

While a similar case can be made for Java or Python, I contend that, excellent skills to have though they may be, both languages place more demands on the casual programmer, requiring more time to learn and more discipline to write code. Perl benefits from a much more relaxed approach to scripting. Being a semi-compiled scripting language it is easy to write quick scripts and easy to develop these in a more-or-less ad hoc way.

It is undoubtedly true that Perl’s relaxed approach can bite the unwary, and it is very easy to end up with unmaintainable systems if you let them get out of control. But with a little discipline you can, so to speak, have your cake and eat it — benefiting from simple, rapid scripting facilities, leveraging libraries and ease of developing small scripts into greater things.

If you get serious about your Perl then you will need an IDE. I use ActiveState’s Kermodo and it serves well with its integrated code assistance, online help, coverage analysis, and debugger being major benefits. Activstate’s Perl developer package also comes with a nice packaging tool that wraps a Perl interpreter with your code to provide a single executable package that does not require Perl to be installed on the user’s environment.

If your tastes run more to the Eclipse IDE then there’s an extension for Perl, which also supports the Perl debugger, called EPIC. Having used both, I favour the ActiveState environment for all the additional features their package supports, but that’s a personal choice.

Over the past fifteen years I have found my Perl skills have enabled me to quickly develop and reuse Perl scripts in many different environments, on many different projects, for many different clients. So, for me, Perl has been one of the skills I have been very glad to have in my toolbox.