Is Software Configuration Management Technology Regressing?


6. A lack of customization capabilities in commercial offerings

Open source version control tools have very limited customization capabilities, including scripts, triggers, and settings—perhaps sufficient, considering version control is a small part of the SCM and ALM puzzle. SCM and  ALM tools, on the other hand, must support a greater variety of users, process, and data. Whereas version control needs may slightly differ between one organization and the next, this is not the case for SCM and ALM.

And while some commercial tools support large processvariations that fit many projects, other offerings are much less configurable. SCM and ALM tools need to support significantcustomization and configuration, including the definition of metadata, tuning of the user interface for specific roles, defining the presentation and navigation of data, defining custom information links to to-do lists, and modification of process. In addition, the tool should provide documentation support, report and dashboard creation, and metrics required for a project.

With a high level of customization capability, each user can look at the complexity of SCM and ALM through views specific to his roles and requirements. The easier to customize, the more value the tool adds, resulting in increased productivity.

7. An overall poor understanding and poor marketing of the true benefits of full ALM

There are plenty of inexperienced team members out there. But they are going to remain inexperienced if the benefits of a full ALM solution are not easily and readily explained. The software SCM industry has not done  a good job of educating the industry or marketing ALM.

Proper marketing of true benefits might take the form of annual tool competitions, where real-world SCM and ALM issues are addressed by all commercial tool suppliers, and even open source solutions.

SCM product reviews can help, but the complexity of SCM may preclude a thorough review and result in comparing only the basic common elements of each tool. You cannot compare an open source tool such as Git to an advanced, modern SCM and ALM tool. It would be like comparing a bicycle to an automobile.

8. The perception that building around open source tools is easier to sell to management than capital expenditures of ALM tools

“How much does the tool cost?” is usually the first question. And if the answer is that it is free because it’s an open source tool, then the response a software manager will most likely give is “Great! No cost? Go for it!”  However, a decision like this would never pass a business case review. The cost of licenses is not the largest cost of SCM. Training, process implementation, scalability, and integration with existing systems can be very costly.

Every company needs an ALM solution. How much of that is manual or done piecemeal is a separate question, but the cost of ALM is the cost that has to be measured in a business case.

Free version control, no matter how good, is not an ALM solution. Solutions may be built around it and engineered for cost-effectiveness, but it’s even better to have a version control component specific to a full ALM solution. Then certain things become more obvious: You don’t check in files; you only check in changes. You don’t just type in comments; you reference and link to approved problems and feature activities.

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
Nov 05
Nov 14