In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
One of the biggest problems with software configuration management (SCM) standards is that the industry is currently too fragmented. Sure there are lots of ways to do things and plenty of high-level standards out there, but as a whole the industry uses different terminology for the most basic concepts, and fails to understand that standards must go beyond ability and push the industry forward. I do like the maturity model as a framework for helping to move forward.
The high-level standards are primarily process standards: make sure you identify every component, manage and control change, have a means of tracking the state of your CM artifacts and ensure that you can prove that you build is what was asked for. These are important but very high-level criteria. The problem has been that, as we look deeper, there is greater divergence there are various basic capabilities without guidance.
For example, it's fine for an SCM standard to say that all revisions of a file, once registered in a CMDB, must be available for all time. It’s fine to say that parallel branches of revisions must be supported. These capabilities, though, without guidance, can lead to poorer SCM. Just look at those projects where branching and/or labeling have gotten out of control.
Now one of the more frustrating things I find is the lack of a basic standard for terminology. What do you mean by status accounting, or even worse, is it a change package, an update, a change set or a change? Maybe it's time to start nailing things down a bit. Of course if we try to do this, we're in for a real battle. That's just the nature of standards.
Perhaps there are some of you who would like to add your opinions so that we can somehow march toward some better standards over time. I'm not going to try to bite off the whole standards issue in one article. It's just too big.
So perhaps, to simplify the process of the SCM process standards discussion, I'll focus on terminology. I hate to leave behind the "push the industry forward" part, but for now I will, while addressing that in a future discussion on standards.
Terminology is such a crucial part of a standard and often the most visible component. Lack of consistent terminology can cause confusion even with the best standards. Even if the standards clearly define what the terms mean, if the definitions are unnatural or divisive, the standard, clear as it might be, might lead to overall confusion and rejection.