CM: THE NEXT GENERATION - Beyond CM to ALM

operating system allowed revisions of files to exist and to be referenced in "views" based on the configuration criteria.  The idea here was, not just to be able to store baselines in the VC system, but to be able to expose a view of these files just as if they resided in the file system of the Apollo Domain platform.  When Apollo was bought out by one of it's competitors (HP), DSEE started to die.  But a group of developers formed Atria Software to create ClearCase, a product capable of running on many Unix platforms.  

In the early '90s, Caseware unveiled Amplify Control, the forerunner of today's Synergy product (IBM).  In parallel, a company called Polytron published its PVCS software, version control for the PC, including OS2.  After numerous acquisitions, Serena became the owner of the PVCS suite, now ported to Unix and OpenVMS.

During the '90s, these companies tried to differentiate themselves:  PVCS with it's strong PC base, ClearCase with its strong DSEE following and unique virtual object bases, Continuus (Synergy) with its flexibility, and CM+ with its full life-cycle capabilities.  Each had severe handicapps to overcome through the '90s, while at the same time, the concept of GUI was defining itself.  From early to later Motif (Unix), from Windows 3.0 to Windows 95 (PC), and with ease-of-use becoming important, all of these products survived and with flying colors, ending the '90s with some momentum.

The signs of a second generation CM tool (no longer called a version control tool), became somewhat clear but also somewhat varied.  The user interface went from CLI (command line interface) to both CLI and GUI.  The GUI was strong in the delta and merge tools, weaker from a management perspective, with a preoccupation of making merging easier.  A couple of tools (Continuus and CM+) actually had some decent management capabilities from the GUI.  

Control went from checkout and parallel control management to various Process control schemes, covering changes (updates/change packages), problem reports (defects/issues), usually implemented through scripting, triggers and file/data permissions.

The CM application suite widened from Version Control (VC, branching, delta, merge) and Make, to include Change Management with Updates/Change Packages, Build and Release Tracking, Problem Tracking, and even Requirements Management.  The CM tool suite evolved as a combination of tools.  In some cases, these were separate tools (database, version control, configuration management, change management, problem tracking, requirements management).  In other cases they were all managed by a single tool on a single database.  Most were somewhere in between.  The big question:  what's better - a consolidated monolithic tool, or the best of breed, glued-together applications, to provide some uniformity and traceability.

Other areas addressed by (second generation) CM included the ability to cope with multiple site development, the ability to serve the big development platforms (Unix, PC, Linux, and to some extent OpenVMS and mainframes), the ability to make tools more scaleable, and some improvements in reporting, query and status accounting.

The end of the 2nd generation of CM tools defined software configuration management fairly clearly to some, but to others, "everything is CM".  Most commercial tools today are primarily 2nd generation tools with some emerging 3rd generation capabilities.

From CM to ALM, the 3rd Generation
Early in the decade, the term ALM (Application Lifecycle Management) started gaining steam.  Perhaps this evolved from the PLM (Product Lifecycle Management) of the hardware CM world.  But, quite independently, software CM requirements evolved into ALM requirements.

Because CM was and is a backbone technology, safeguarding both assets and processes within a software intensive organization, it was natural to extend its application reach