Is Software Configuration Management Technology Regressing?


There are ever-growing ways to organize your project assets with public domain configuration management tools. There's a mistaken belief that these free software configuration management (SCM) alternatives can be just as powerful as leading commercial tools.

Free source code management tools are becoming more and more popular. But is free just as good as commercial offerings? Back in the 1970s, software configuration management (SCM) meant version control. Anything more than that was an in-house, advanced solution. This situation persisted through the 1980s. Two operating systems—Digital Equipment Corporation’s VMS and Apollo Computer’s Domain platform, a  workstation variant of Unix—got into the act, providing various levels of version control. There were a few impressive proprietary, homegrown solutions, but they were largely invisible to the overall software industry.

Finally the 1990s arrived. Yes, there were still version control tools—RCS, CVS, and PVCS, to name a few—but there were also tools such as ClearCase, Continuus (which later became Synergy), STS (later CM+), MKS, and other evolving commercial tools. There was strong competition among the vendors. The UK research firm OVUM performed annual SCM tool product reviews that were highly respected and anticipated. Vendors had to improve their tools in order to stay competitive. Suddenly, the computing world was introduced to real SCM solutions, focusing on the broader software development lifecycle and on process and automation.

However, toward the end of the 1990s and into the new millennium, advances in SCM slowed and mergers took place, such as IBM's acquisition of Telelogic (Synergy) and Rational (ClearCase). The SCM industry  continued to advance, but with reduced competition among vendors, the focus shifted more to lower administration costs than to investing in new features.

There was a move to glue together parts of a solution: requirements management, version control, change and configuration management, build control, test case management, document management, and even   problem tracking.

Some integrated solutions knitted together two or three of these, others combined the tools into a comprehensive suite, and some provided many parts of the solution in a single integrated tool. With few exceptions, these solutions came with hefty price tags. The industry slowly adopted the term application lifecycle management (ALM), synonymous with computer hardware’s product lifecycle management.

There were still new CM tool startups, including Accurev,and Microsoft’s VSS—but, in my opinion, these were largely version control tools with a new twist here or there.

Subversion and Git

More recently, Microsoft’s TFS and IBM’s RTC have shown some real advances. But the software industry has embraced newer version control tools, with Subversion and Git topping the list. Why?

To put this in context, Git and Subversion, both open source version control tools, are battling it out for dominance in the SCM industry, and many organizations are regressing from stronger SCM solutions to more basic Subversion or Git. Some commercial SCM tool vendors have reacted to integrate their tools with these open source version control solutions.

Software teams need advanced SCM or ALM solutions with real benefits that provide real productivity to all product team members. These benefits include fail-safe reliability and accessibility, near-zero administration, full change package support, a mature SCM process, easy process customization (rather than process buried in scripts), advanced user interfaces, reduced training requirements, comprehensive SCM metrics, generation of required SCM and release documents, data security, and navigation of traceability relationships.

With today’s SCM technology, it’s possible for users in each role to increase their productivity and for the entire product team to have all required SCM information at their fingertips. Good SCM tools should result in higher quality products with lower CM costs than basic version control tools.


User Comments

Frank Schophuizen's picture

Great artciel. I fully agree with you observations, especially that the benefits and the necessity of an ALM solution is not sufficiently explained and marketed. To many, ALM is considered a sales pitch to lure customers in buying more tools (or licenses, if you will) from the same vendor. That is what happened in the '90ies.

Moreover, software engineers from the 90ies are now the software development managers of today. So, their frustrations and allergies about "big" tools or "integrated" solutions is now guiding their decisions... Big means expensive, integrated means expensive and commercial vendors means arm-twisting and lock-in.

ALM is not a tool nor an integrated tool suite. It is an integrated solution of processes, practices, tools (not necessarily from the same vendor, and including open source where appropriate), organization and people (!) that collaborate and integrate seamlessly. SCM is out; it is too narrow-scoped and tempts customers to think in terms of tools and licenses, rather than efficiency and effectiveness of the organization.

May 15, 2014 - 1:59am
Brad Appleton's picture

Hi Joe!
I believe another reason for the apparent regression in SCM tool functionality is the influence of Agile/Lean development cultures that call for extreme simplification combined with a rebellion against having SCM tools "imposed" on developers via their organizations and so called "formal" SCM experts, and how such a tool selection+deployment strategy takes away control from developers both in the definition of their SCM process as well as its automation.

DevOps-related tools are even supplanting more traditional SCM toolchoices in this area, and many are redefining what SCM (or at least the perceived value of it to their development teams) in terms of automated+"continuous" build/integration/deployment capabilities.

From the dev/ops teams perspective, ditching these higher-tiered tools is a way of taking back control over their own processes and development models, and eliminating a lot of the perceived "overhead" of what they felt was being imposed on them unnecessarily, or in a way that was more of a burden to  them than a benefit. Once they rid themselves of those chains/shackles they were free to automate and integrate the needed pieces themselves the way they felt was most effective & efficient.

We witnessed the same thing happening with tools for doing "project-management". Not only were the methods and techniques being used no longer perceived to be "current" and "useful" but they were seen as imposing old ways of heavyweight processes that took control away from the developers. The more popular agile/lean/kanban-based methods not only support a different model, but they do so in a way that gives full control to the team and not just a project manager.

I think we're merely seeing the same thing happen with SCM, and that a lot of the more advanced capabilities were perceived to be implemented in a way that is more closely associated with process overhead and disempowering bureaucracy and a single controlling (configuration) manager rather than employing a simpler model with more distributed control/power among the rest of the team.

More and more developers and development teams are simply trying to take-back control over their own SCM processes and activities (for better and for worse) and are willing to take a step backward in functionality as long as they get to be in control of their own SCM destiny and  the corresponding way they envision seeing it automated. Eventually more vendors (and open-source offerings) will take notice of this and come up with offerings that have the missing functionality in a way that is a better fit for them.

May 19, 2014 - 2:54pm
Joe Farah's picture

Hi Brad,

Great observation.  Control is paramount in expanding and simplifying process.  And no doubt there are a number of tools that simply don't allow the flexibility needed by developers.  I'm sure we can both name a few.  But there are others where the customization capabilities are a key factor in providing control.  If I may reference our own tool, Neuma's CM+ is a prime example of a tool where both as a developer and as a CM manager, you have process and control capabilities that are likely well beyond what you might have by regressing to a simple VC tool and adding in functionality via the various scripting capabilities.

And I think it comes down to a few key capabilities that SCM/ALM tool simply need to support:

   1) Centralized database/repository that all phases and functions of the application life-cycle have access to.

   2) Data capabilities beyond SQL, which provide data revisioning, large objects, simple 1-many relationships, etc.

   3) Very high-level scripting capabilities (well beyond Ruby, Python, etc) which integrate data, process control, UI generation (dashboards, forms, etc.) and ALM functions without requiring a mountain of scripting code.

   4) Tiered control that customizations may be applied to an organization, project, group, role or individual users, along with the capability for any user to take advantage of the customization capabilities, and to share their advances with other users.

To be honest, I have not seen a lot of tools that are strong in the customization area.  Way back in the early '90s, Amplify Control (later Telelogic Synergy) showed a lot of promise.  But instead of improving the customization capabilities it had, it instead took a (perfectly good) approach of delivering pre-canned customizations.

The customization/process/data management space is not specific to CM.  But CM is a great place to grow this backbone technology so that we don't have to go back to the basic wheel to regain control.

So I think you have really hit the nail on the head in suggesting that developers want to regain control.  I just think there are better ways to do this than to go back to version control basics.

May 19, 2014 - 10:43pm

About the author

Upcoming Events

Jan 30
Apr 29
Jun 03
Jun 25