More white papers:
Find out more ...
Neuma 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.
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
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.
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
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?
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
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
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
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?
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.
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.
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
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
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
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.
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
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.
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 firstname.lastname@example.org