What the Next Standard of CM Will Look Like


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.

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.

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.

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

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. 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 at farah@neuma.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!