Change control: is it a tool or is it an attitude? Maybe it's a little of both.

Last month, we talked about some of the myths that seem to surround change management. Now let's take a few moments and talk about what a change control system should be.

What It Ain't

What better way to start than by summarizing what was said last month about what change control isn't. Despite what we might think, change management or control is not a mechanism for ensuring that problems don't get introduced into the system.

It's not a vaccination or an insurance policy to prevent things from going awry. Most issues that cause production problems are injected into an enhancement or a fix during the design process. Because change management deals with things that happen after the design, it's not the controlling process.

Unfortunately, many companies today see having a strong change management system as the way to prevent problems in production. And what's the result of that frame of mind?

Well, it generally yields a control system that has a lot of fat attached to it but not necessarily a lot of muscle. Typically, everyone in sight is involved in the process, and while broad involvement may sound like a good idea, the more cooks you have the less likely you are to get a successful meal.

What's worse is that often everybody gets their day in court with this. By this, I mean that everyone is asked whether the enhancement works. Or if it does what it's supposed to. But those are difficult questions to answer and sometimes require a fair amount of time to answer honestly. So most people will give the app a pass. They simply don't have time to put things through their paces. In the end, all that it really does is waste a lot of time.

There are other pieces of fat too, but let's not dwell. And the muscle? Well, that would involve using the control system for something other than covering yourself and the organization.

What It Is: Separation

The first thing that change management should provide is separation. Of people. And projects. That is, you need to have some way to be sure that two or more people are not simultaneously fooling around with the same module.

In many environments, this is taken care of by organizational structure. One programmer does billing, another does inventory, etc. But increasingly, even in these situations, more and more projects are becoming interdisciplinary. In addition, more and more modules or service programs are being used in multiple application areas.

As a result, there's no way to be sure that more than one person isn't working on a section of code without some sort of checkout procedure. This isn't a technically difficult thing, but it does require some automation, just a simple system to automatically note who's working on what and to lock all others out from getting into that module at the same time.

In addition, it also requires that you have your source code in one spot—perhaps not one library but at least somewhere where the system can find it. And it requires that people actually use the checkout system rather than just get into the source module (or copy it manually) and go to town. Strangely enough, sometimes just getting people to follow the rules is the tough part.

What It Is: Automatic Deployment

The next thing change management provides is automatic deployment. That is, there's nothing more annoying (or more surely to get screwed up) than having to move seven or eight modules from one library to another, either moving both source and object or, more likely, moving source and then compiling. It is an accident waiting to happen. All you need to do is forget one module and you have a problem.

What you need is a system that will do this for you based on a code, like a project number or some such nonsense. You would have entered this along with the modules associated with it when you did the checkout. Now you can take advantage of that to automate your deployment.

What It Is: Backup

Backup consists of two things, and these things come into play when something bad happens with your new release.

First, you need the ability to save copies of the current version (both source and object) of all modules that are being moved to production.

Second, it would be swell if there was a way to restore the saved source and object to the production libraries with just a flick of a switch rather than having to move modules manually and recompile them to get the object. This is the restore part of it.

People who don't have a big, fancy change management system will generally at least do the save of the original modules. And that's good. Where it falls down is that it doesn't allow you to quickly restore those copies, and it doesn't do so as a unit based on a project number. All of that has to be done manually.

What It Is: Cleanup

Once your project is done, there's always cleanup work to be done.

How many different test environments do you have? Do you work in your own library and then move the modules to IT to test for the first round? And then to a user test area for the shakedown cruise? And finally to production?

As you go through each state, you leave behind a set of modules and possibly other debris that's better off removed when you get finished with the project.

An integrated change control system should do that for you, either as you go from step to step or at the end of the process.

Or should it?

Certainly, you want to clean up your own personal environment, but at the same time, you don't want to just clear the new mods out of the test environments. You want to clean out debris, but at the same time you want to promote any permanent enhancements to your test environments just as you promote them to test.

Exactly how you do this depends on how your test environments are defined, how many of them there are, and what the relative humidity is (although many experts dispute just how critical the relative humidity reading is; it's a judgment call).

But cleaning up the mess from your project as well as rolling it immediately into your test system is critically important.

What It Is Really

But when all is said and done, change control is more a state of mind than a tool. I know I've described it in tool terms, but it really isn't.

Unfortunately, even though I believe that to be true, I've found it impossible to write the closing paragraph in a way that doesn't sound tool-like. Most people would take that as proof that change control systems are indeed mostly tools. But not me. Like I said above, it's more of a state of mind, a state of mind that forces you to find a set of tools to help you organize and mechanize the development and deployment process.