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.
Software standards have two main purposes: They help systems work with one another by ensuring consistent interfaces and data exchange mechanisms. They also help to define the use of best practices in a process or series of processes.
As a byproduct, software standards reduce costs, by allowing 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.
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. Many of these can hardly be called standard practices, though, or even part of a larger standard.
There are a number of CM "standards" (guidelines or directives) that are sometimes specific to a certain organization. There are also related process/quality standards which cover CM to some extent. These have been extremely useful to the SCM community over time. They have established some basic CM requirements and have helped 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). 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 both problems and features the same. Some do not require change packages, while others 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 can we 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, 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 consensus 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 subversion or other CM tools will evolve into a standard, but I don't buy it. SCCS was almost a de facto standard back in the 1970's and perhaps 1980's. It just didn't have the legs to make it beyond that, though. 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. 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, labeling, 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:
- Source tree browser
- History browser
- In-boxes/to-do lists
- Gantt charts
- Delta and merge operations
- Baseline definition
- Problem report forms
- State flow diagrams
- Trigger and rule definitions
The goal here would not be to identify one tool's presentation over another, but rather to identify all of the common (i.e., must have) and all of the optional (e.g,. vendor variant) features. On its 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 above approaches and a stronger consensus on what are the best CM practices is a start. Existing CM process standards are a useful piece of the puzzle. 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 that 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. In looking around, the CM II standard from the Institute of Configuration Management (ICM) is interesting. It clearly addresses a need on the hardware side: the production of hardware must flow from the documentation. This basically means that parts are not version controlled, but rather only 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.; 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. 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 (CMM). 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. It will, however, be vastly different than the standard that others might recommend if they had the chance.
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. 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 consensus on them. 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. Maybe one day we'll be able to look back and ask what all the fuss was about, but perhaps not in my lifetime!
