Is Software Configuration Management Technology Regressing?



SCM technology appears to be regressing. It’s customerdriven. But look again and perhaps you’ll see that this shouldn’t be the case. The software industry, in its adoption of version control instead of SCM, is charting a  course that is not much different from what we witnessed back in the 1980s.

What do you do to fill in the holes in your SCM? Or is version control your only third-party tool? How do you justify the cost of maintaining your own scripts to support the version control tool you use? Are you considering  changes to how you perform SCM or version control? Take a good look at what’s available out there. It’s time to advance! {end}

[email protected]

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

Oct 01
Oct 15
Oct 24
Nov 05