The Differing Points of View about CM
A recent conversation on LinkedIn asked a very important question: Is CM a management discipline that choked itself to death in an attempt to eat "everything?” I once thought this problem could be summed up as being hardware CM vs. software CM, but now it seems the problem has morphed into a product CM vs. enterprise CM dilemma.
As a practitioner—and I hope a voice of reason—I would like to espouse a larger role for CM so it gets its rightful place in the sun. You might ask yourself why these discussions are important and why CM folks should even care? For me, I think the discussions are very important to our field; the problem arises when they become self-defeating arguments, and we end up squabbling ourselves out of existence.
Bob Aiello espouses the idea of CM being a role or function.. He breaks CM down into source code management, build engineering, environment configuration, change control, release engineering, deployment, and tools.
I like this approach because it explains CM functions and the way they relate to the four core processes of CM—configuration identification, configuration control, configuration status accounting, and configuration audits. When one mentions the four core processes of CM, it is hard to explain those concepts to a new person. The main reason is that the four core processes are no longer “done” by CM folks on the software side; they may be more appropriate for hardware CM people and their daily activities.
For better or worse, software CM is a piece of the larger application lifecycle management (ALM) puzzle. CM activities are spread throughout the lifecycle of the software product. One of the major proponents of this view is Brad Appleton. His vision, I believe, is for CM to take a larger role in the ALM process. I agree with this approach as well because CM touches all areas of a project’s lifecycle—from initiation to turning the system off and archiving it.
In Appleton’s view, we have a place at the table, as we should. We have a service to offer development, project managers, product managers, quality assurance and quality control, operations, and business users. A blog on MSDN.com sums up this viewpoint in a way that we all can understand and appreciate.
Which side of the argument do you fall on? Do we need to redefine CM in a way that is more modern? Do we need to move beyond the four core processes of CM? No matter where you fall in this argument, we will have to address this sooner or later.
