What is “Project Integrity Management”? How is it different from Configuration Management? How does it make it any easier to prevent the dreaded project meltdown? I’m glad you asked.
As mentioned in a previous article, Configuration Management attempts to control elements of a project, specifically controlling and managing the constant change of information associated with the project. The amount of information to be tracked can be overwhelming, and the task soon becomes too complex to be performed manually. This leads most projects to seek a “toolset” to manage their configuration for them. While many commercial and some open source toolsets exist today, they all seem to be solving different problems. This is most likely due to the variations in different people’s understanding of what Configuration Management consists of.
What many projects call CM is actually not configuration management at all, but simply source code control. For this task, there are a number of software packages available that provide varying degrees of functionality and frustration. But source code control is not configuration management. I would even go so far as to say that it is not even part of the configuration management process, but I will save that argument for a later time when I feel like starting a flame war.
In the interest of avoiding splitting hairs on what Configuration Management is or is not, I have opted to create a new term altogether that will represent the concepts that I feel are the ones that need to be defined in order to get a handle on the mess that many of us know as the “development project”. This term is Project Integrity Management and although it is similar in some ways to Configuration Management, the two are not interchangeable, at least not with the definitions I have seen of CM. So from here on out we will be speaking of IM instead of CM unless I am referring specifically to a Configuration Management concept.
Definition: Project Integrity Management – The methods utilized to ensure that a project remains in a consistent known state throughout the product lifecycle.
First of all, IM is not source code control. This has been done many times over and, although I don’t think that the approaches that are currently being used are great, I have nothing to add to that debate. It isn’t that I don’t think source control is important, I just think that the process is well understood and we should focus on some of the more vexing problems that have not been so thoroughly studied and developed for.
At the highest level, IM consists of the two following areas:
Versioning
Environment Management
These two concepts represent everything needed to completely track and control a project’s variables. As you may have guessed, there are many lower levels to these concepts which we will explore, but first I would like to describe what is meant by these two terms.
Versioning is the most important concept in IM. Without versioning, the rest is impossible. In PIM, everything is versioned. If it is not versionable, we are not interested in it because the definition of “versionable” is “possible to change“. If something is impossible to change throughout the life of a project, then why would we care about it? It is in an eternally known state and tracking it would be silly. What would we track?
The catch in this definition is the very important word “possible” is a pretty wide-open one. For example, you may consider that the operating system that is being developed against is not going to change during the project, but you would likely be wrong. Service packs change operating systems all of the time. Operating systems even have their own versioning scheme already built in. Servers can crash and be replaced with different machines. Documents can be edited, corrected, and revised.
The upshot of this is that pretty much everything associated with a development project can change. Nothing is “set in stone”. What that means in IM is that everything must be versioned. Yes, that includes operating systems, servers, and documents. If it can change and it is part of a project (i.e. part of a deliverable), it must be versioned. We will explore the finer points of versioning soon, but for now this short discussion will serve our purposes.
The other high level concept in PIM is Environment Management. This may or may not be a new term to you; I didn’t make this one up! But I am going to heavily redefine it to suite PIM’s purposes. What I am referring when I mention Environment Management is the control of all versioned items in each project environment. Examples of environments in this context are “development”, “test”, “training”, and “production”. However, as you will find out, this is not to say that there is only one development or test environment. In most projects there are several. The PIM approach to Environment Management is one of “Just In Time” environment creation and destruction. Environments are like Krispy Kreme doughnuts. As soon as they are created, they start going stale, so they are best while still warm and soft. I will also provide a detailed approach to implementing this JIT environment control plan.
What this means is that the environments themselves are versioned. From a practical standpoint, this means that if product testers are testing a fix to an older version of the product, they can re-create the specific test environment that matches the software version they are testing, right down to the system configuration settings and hardware driver versions.
Those are the high level concepts. On their own they are not very useful though. In fact, at this point, they may not even be comprehendible to any meaningful degree. But if you could see the picture in my head (which I hope to bring you around to doing), you would see that not only is it comprehendible, but very elegant and flexible. Now that we have gotten the mile-high view, in my next article, I want to jump to the other end of the spectrum and give you a peek into how this can be pulled off. But first, a quick trip to the store.
M@
