Configuration Management - A process, not a toolset

One of the first questions that usually comes up when talking about Configuration Management is "What software should I use?" While the choice of tools is important, this should not be the first decision made. I would argue that you can't even answer that question until you have gone through a lot of other stuff first.

In many ways implementing CM is similar to software development itself. With a typical software project the client comes to the table with a very broad, very sketchy idea of what they are hoping you can give them. They don't know much about the way software is developed, they know nothing of the available development languages and environments, and they aren't sure what the purpose of a database is. What they do know is that they want a system that allows their customer service folks to pull up a user account, view the account history, see any notes and alerts on the account, and see how long it has been since the customer called last, all based on the caller-ID information of the incoming phone call.

The funny thing about it (funny as in remarkable, not as in "ha ha") is that they THINK they know exactly what they want. Anyone who has done any work directly interacting with the client knows what I am talking about. The best thing to do is to listen intently without interrupting, take careful notes, and let them go through all of their ideas about how it should work. Then (probably at a later meeting), each of the features sets they identified should be clarified. You may ask a series of questions such as:

What if two callers have the same phone number (for example, a man and his child or spouse) but different account numbers?
What if there is no caller ID information with the call?
What if someone calls from a friend's phone? How do you know you are really speaking to the right person?
What if there is more than one phone number for a person(examples: cell phone, work phone, home phone) and they could call from any of them?

These types of Q & A sessions usually leave the client dumbfounded at the number of scenarios and situations that they simply did not think of when they were dreaming up this simple application. As each point is worked through, a clearer picture emerges of what the application really needs to be able to do and how it will do it. Eventually everyone has a clear understanding of the problem to be solved with the software and the real planning can start. It would make no sense to decide on a development environment and order software licenses before you even know what they really wanted their system to do.

CM is very similar. When I first meet with a client and they make the statement of "We want to implement a CM system", I know that this is just the very tip of the iceburg, and almost without exception they don't really know what is involved in what they are asking for. But it never fails that not very long into the conversation they will ask what CM softare tools I recommend that they look at.

Now let's think about this for a second. The choice of a tool for any job requires knowledge of how the tool will be used. For example, if you decide to hang a picture on a wall, you need to know how this will be done before selecting a tool. Is the wall wood, sheetrock, or concrete? How heavy is the picture? What height will it be hung at? If you fail to consider these questions, you may end up trying to drive a screw into sheetrock with a hammer or screw a nail into concrete with a screwdriver. Obviously these would be poor tools for the job, but without knowing the answers to the simple questions up front there is no way to know what tools you will use or how you will use them. Besides, trying to nail a screw into sheetrock with a hammer will probably not result in a happy client.

It makes just as much sense to try to select a configuration management tool before you have gone through the process of determining exactly what their goals and requirements are for configuration management.

Perhaps you are not a CM consultant attempting to implement CM for a client though. What if you are just trying to do the right thing on your project? The most natural thing to do is start looking for a software tool that will make implementation easier. After all, if the tool will do it, why bother going through the pain of figuring everything out up front? Unfortunately that logic does not hold up well. When you don't know what you really need the tool to do, they all look equally good. It then comes down to a matter of which one looks the most useful.

I used to have a friend who loved power tools. He would see one on some home improvement show and decide it was just the thing he needed, run out and buy it, and then have no idea what to do with it. I came by one day and he wanted to show me his new compound miter saw. I agreed that it was very cool and potentially useful, but questioned where he planned to use it since he lived in a smallish apartment. Of course this question had never entered his mind. Neither had what he was going to cut with it, or for what purpose. But it was a VERY nice saw...nobody could say any different. He also had several electric guitars although he couldn't so much as play "Wild Thing" or "Foxy Lady" on them. And several high powered rifles and a handgun or two even though he would have to drive 50 miles to be able to actually fire them legally. And a motorcycle that...never mind. You get the picture.

My friend's problem is that he bought the tool and then looked for something to use it on. This is the way most people shop for CM software. They purchase it (usually for a wholly unbelievably high price), install it, and then (and ONLY then), start thinking about how it will be used. Of course software vendors love this approach because it means they don't have to really solve the problems of CM, they just have to offer a longer feature list and cooler screen shots on their web site. And there you sit, staring at a computer screen with software that costs more than your annual salary, wondering what the heck you are supposed to do with it. To rely on prepackaged software is to turn part of the decision making process over to some programmers who you have never met and who don't really care whether or not you have to spend your time trying to make it work right. The goal of most software companies is to sell software, not make your job easier, despite what the sales guy tells you.

Over the next few months I will be going through the process of preparing a project for true configuration management. You will see that the topic of what software I recommend doesn't come up for quite some time. The truth is that it is my belief that a good CM plan does not assume the use of ANY software.

If you are serious about implementing Configuration Management in your project(s), stay with this blog and I will guide you through it. I find it to be a fascinating topic that actually does make a lot of sense when the details are better understood.

M@