White Paper: CM: THE NEXT GENERATION of Software CM Standards

Software standards have two main purposes: (1) They help systems work with one another, ensuring consistent interfaces and data exchange mechanisms; and (2) They help to define the use of best practices in a process or series of processes.

As a byproduct, they reduce costs. Standards allow a set of pre-trained personnel to be available on the job market. They provide reduced risk exposure as personnel responsible for processes and for developing standard interfaces/data exchange, are more easily replaced with less risk of knowledge loss. This is because the requirements identified by the standards are well defined. This, in turn, generally means that there are test suites, test plans, and measurements available to monitor processes, and to test out new components. Standards are much more rigorous on the hardware side of things than on the software side. If the hardware pieces don't fit together, neither does the solution. So, too, with communication and network protocols, which are very standards oriented, whether for voice, data or converged communications.

Software has many defined standards, but for the most part, the standards focus on process more than data and interfaces, with a few notable exceptions: ODBC for data exchange, compiler languages for consistency of programming, libraries and linkers for compatibility with operating systems/host platforms, and so forth.

But when it comes down to Software Configuration Management, standards are often relegated to some fairly high-level best practices: you must be able to reproduce a build; you must be able to demonstrate that the product covers the requirements; you must be able to support the product for N years. In my November 2007 article I listed a number of CM best practices. But many of these can hardly be called standard practices or even part of a larger standard.

There are a number of CM "standards" - guidelines, or directives - sometimes specific to the military or some other organization. And there are related process/quality standards which cover CM to some extent. These have been extremely useful to the SCM community over time. They've established some basic CM requirements. They've helped to form CM processes. However, they are often "soft standards" or project/program specific detailed standards.

They do not allow, for example, the transfer of information from one SCM tool/process set to another. Imagine a database standard that did not allow the information in repositories to be transferred from one DB vendor's tools to another. The reports, scripts, process enforcement, etc. of databases may not be transferable (as the standards for these are less developed). But at least the data can be transferred from one database to another and standard tools can be created which operate across databases of various vendors. Not so with SCM tools. There are some tools that treat problems and features the same. Some that do not require change packages. Some that don't have directories under revision control. And so on. How is such information to be passed between tools if we don't agree on what the information is? How are we supposed to gather common metrics across tools, or share development across SCM platforms?

I'm just as much at fault as the next guy. I haven't demanded that the SCM industry produce standards for information interchange. In spite of trying to work with non-standards such as Microsoft's unofficial SCC API, or the Eclipse platform, I have not tried to force the issue on anyone. Instead, I've taken my own views, as formed somewhat by the rest of the industry perhaps, and have marched down the road in a manner that I thought was best. So where to go from here?

Unfortunately, the CM technology space spans several generations, from 1st generation tools dating back to the 1970's to the odd 3rd generation tool (and perhaps even a 4G CM tool). Each tool tends to have a specific feature or feature set that helps it to stand out, but is perhaps very different from other tools in the industry. Trying to reach some concensus on CM standards is a challenge.

What makes things even more difficult is that, with the variety of CM processes, advanced CM tools sometimes act as CM toolkits, where you can not only adjust the existing processes, but even add in your own new processes, schema and user interfaces.

A de facto standard?
Some say that perhaps Subversion (SVN) or other CM tools will evolve into a standard. I don't buy it. SCCS was almost a de facto standard back in the 1970's and perhaps 1980's. But it just didn't have the legs to make it beyond that. The same happened with CVS which started gaining ground, but eventually gave way to SVN. Many people love SVN, but for me, it's a couple of generations behind.

It's not likely that a de facto CM tool will emerge unless a vendor of a very advanced tool goes open source. And even then, there are too many other considerations that make a standard much more than just the tools that are used.

Industry Concensus?
This could be a promising avenue to pursue, but there are significant problems here. We might all agree that change packages are a good thing, but will we agree on viable branching patterns? Will we agree on single Main trunk versus Main trunk per Stream? Will we agree on technology that will allow automation of time consuming functions such as view creation, labelling, and change promotion? The industry is not ready to dictate a CM standard other than from a high level process and best practice perspective.

User Interface?
A more promising approach might be to start introducing common interface elements that in turn imply some level of interoperability or perhaps data exchange capability. Some of the common interface elements might be:

The goal here would not be to identify one tool's presentation over another, but instead to identify all of the common (i.e. must have) features and all of the optional (e.g. vendor variant) features. On it's own, this approach would not give us data interchange capability immediately. However, just as operating systems and computer languages are now largely hardware independent, it might allow the industry to settle, more easily, on what's under the hood because it's really the user interface that becomes the driving force. Even so, this would be a very long road to standardization of CM.

So where do we turn?
How will we attain CM standards? I think we need to address the issue on several fronts. A mix of the approaches above, and a stronger concensus on what are the best CM practices is a start. Existing CM process standards are a useful piece of the puzzle. And some of the more advanced tools will drag the industry along as competitive differences are addressed by the vendors. But we're a long way from what I might want to label a real CM standard.

Another approach I've been looking at for the past year or so has been the possible adoption of existing standards from the hardware side of things. And looking around, the CM II standard from the Institute of Configuration Management (ICM) is interesting. It clearly addresses a need on the hardware side - that the production of hardware must flow from the documentation. That basically means that parts are not version controlled, just the documents are.

CM II
Looking more carefully at this standard, I could not accept that software modules would not be version controlled, but had no problem saying that "Builds", or more precisely, the deliverables that come out of the build process, are not version controlled. Software really tends to be dual-natured, both documentation and, in some cases at least (e.g. Perl scripts), deliverable.

Looking at CM II more carefully, there are also a number of other key elements. A user interface element called the "Baseline View" allows specific frame by frame advance of what the differences are as each Engineering/Enterprise Change Notice (ECN) is applied. CM II does not dictate the full functionality of this view, but does identify some key properties it must have. Similarly, for processes and roles, it identifies key elements that must be present: Change specialists, Users, etc. and Change Control Boards (CCBs) and Change Implementation Boards (CIBs). It also identifies some key data elements that must be tracked: ECRs, ECNs, Problem Reports, Work Orders, Waivers, etc., identifying some of the key properties of each, and even the workflow of them, without limiting the definitions.

It's not a simple task, but the CM II process can be mapped onto the software world. No vendor has done this to date (at least not publicly), even though there are a number of CM II tools for hardware. But I expect one or two software vendors to take on this task in the next year or two. If so, we might have the makings of a software CM standard, or perhaps the framework on which one could be built.

CMMI
Perhaps the most important quality process that applies to software CM has been the CMM/CMMI from SEI (at Carnegie Melon University - also known as CMU!). The industry is fairly well-versed in the Capability Maturity Model. If nothing else, this model has allowed us to broaden the definition of CM so that the model may be more fully supported from the enterprise CM backbone. Some CM tools can be customized to provide CMM-specific support, with some even having specific plug-ins or configurations for CMM.

The advantage here is that a well recognized process initiative, if embraced by the CM industry, will force tools to converge somewhat, at least in offering a common subset of capabilities.

The CM Standard
So, when will the ultimate software CM standard emerge? I suspect it may be never. Let me recommend the standard and it will be very well defined, flexible and cater to things such as Agile environments, automation, CMMI, CM II, and more. But it will be vastly different that the standard that others might recommend if they had the chance.

So don't expect a comprehensive software CM standard soon, even if a CM II for Software process is defined. Our best hope is for an advanced solution to grab 90% of the market and then to go the Open Source route. So do you think we can get a 90% consensus on the best CM solution out there?

Still, if we want a CM standard to emerge one day, we can do something very concrete today. We can start focusing on the elements that need to be standard. Identify them. Expose them. Build concensus on them. And have a very long term goal on reaching some consensus. With the pace of technology, it will be a great challenge just to agree on an approach. But maybe one day we'll be able to look back and ask what all the fuss was about - but perhaps not in my lifetime!

Joe Farah is the President and CEO of Neuma Technology . Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe by email at farah@neuma.com

More white papers:

Find out more ...

Neuma White Paper:

CM: THE NEXT GENERATION of Software CM Standards