Enterprise SCM is essentially the application of consistent processes, tools and practices across an organization through the application of enough money. Please note that free solutions are not generally acceptable since CxO’s generally believe that you get what you pay for, and what they want to pay for are solutions. This is why I have started to register a new product – Silver Bullet SCM Suite. This will install itself on any platform, always work as desired, come out-of-the-box with an exact model for the process already in place, allow transition to new process models at the drop of a hat while maintaining internal integrity, and require no administration overhead. It will even correct your code for you upon check-in so that there will no longer be a need for those resource intensive Continuous Integration builds.

This, of course, is a pipe dream; but it is one that is often sold to upper management by vendors. And there is a model where free solutions are chosen when taking tools to the Enterprise level.

When is it Time to Take SCM to the Enterprise Level?
There are almost as many justifications and rationalizations to take CM to the Enterprise level as there are organizations that decide to do it. The common denominators seem to be one of more of:

• Certification – When it is desired to gain a certification at the organizational level in order to capture a contract or to have a product accepted by the target audience
• Minimizing Resource Load – This includes the economies of scale for tool licensing and support infrastructure, minimizing the sets of unique training required and maximizing the use of personnel across the organization due to consistent processes, tools and procedures
• Contractual Requirement – Sometimes a large project comes along that is worth the pain of making CM (and other disciplines) consistent across an organization

In other words, when it becomes either less painful or more profitable to go Enterprise-wide than it is to keep doing business as usual.

The 80% Paradigm
Most of the time Enterprises decide to standardize on one set of COTS (Commercial Off The Shelf) SCM tools. There are many reasons COTS solutions are chosen, but often it is the result of a Development tools vendor also having an integrated SCM solution available. They may own the tool suite directly or be in a marketing partnership with another vendor. Regardless, it will give a single-source purchase and support option where not only the total scale of purchase/licensing makes the tools seem inexpensive, but keeps the finger pointing to a minimum. As an example, assume the Development and SCM tools both cost $1000USD/person in project level quantities. By bringing all projects under a common agreement, including the projects that would have to migrate to the new tools, the cost per person of the Development tools might drop to $600USD and the SCM tools might be “thrown in” for only $250USD. The vendor is making a large sale where the incremental support costs are minimized, so they can afford to cut some remarkably attractive deals.

When an integrated COTS SCM tool suite is available from a single non-Development tools vendor, but that integrates with the chosen Development tools, it goes onto the short list as well. Other than being able to couple the two types of tools together for pricing purposes, all of the same benefits apply.

Finally, when an internal evaluation team is chartered to select a new Enterprise level set of SCM tools, it will do the best it can in the time allowed. Single-source vendors have an advantage in today's marketplace over other solutions by allowing the review time to be minimized. It also allows for zeroing out the expected integration time.

The 20% Paradigm
The other solution is to select a set of FOSS (Free/Open Source Software) solutions to make up an integrated SCM tool suite. Here, it is expected that the cost of configuring and integrating the tools will be essentially a one-shot cost that can be recouped over time by not having to pay license and maintenance fees. It may even be possible to bolt on one or more COTS tools to provide required features such as Project Management and Metrics Reporting (including Dashboards), but if a FOSS solution providing these features is available it will tend to be selected instead.

The selection of this paradigm is almost always the result of one of two situations: Management Edict or Grass Roots Pressure. If the Development tools, or at least the IDEs, are FOSS then this paradigm is likely to be explored as well.

The Other 20% Paradigm
There is one other alternative – selecting a set of COTS and FOSS SCM tools that can be integrated together to form a solution similar to the one above. In many cases, the COTS vendors will already have available integrations with other tools that can be leveraged to reduce the time spent configuring and integrating them. This allows the best of all worlds from the perspective of the SCM Team. It allows the tool selection be based on “best of breed,” rather than on just what is available from a vendor or the FOSS community. The problem with this choice, even though it may represent an optimum solution, is that it involves both license and maintenance fees plus in-house integration time.

The Common Ground
Having a single set of SCM tools makes it easier to have one set of processes and procedures that everyone follows, regardless of the project one is involved in. It makes it easier to develop and train new personnel and to allow already trained personnel to switch projects without having to be retrained. A standard set of metrics can be developed that is consistent across all projects, so Upper Management has an easier time of comparing relative performance, productivity and quality across all projects. Having a single set of SCM tools also allows economy of scale to reduce the cost per head of the tools and minimizes the number of CM Tool Administrators required to keep the infrastructure running.

The Downside
The biggest downside is that once the infrastructure is in place and working, it is almost impossible to change it for another set of tools without a heavy cost. This is especially true for single-source COTS solutions and this lock-in effect should not be trivialized.

Another problem comes into effect only if projects can differ in scale. What is required to keep a project with 80 developers running smoothly will probably bring a 5-person project to its knees with overhead. And vise versa, scaling up processes, procedures and infrastructure from one intended to support small teams to one that will support the controls necessary for a really large project is non-trivial.

The same is true if different projects use different development methodologies. When anything is tuned to work one way, changing it, even subtly, can be difficult. A friend used the example of NASCAR, where the cars are set to make only left turns. When they have to make right turns, they tend to flip over.

Summary
It might sound like I am against Enterprise SCM, but that could not be further from the truth. What I am against is picking the wrong tools for the wrong reasons, or leaving the CM Team out of the loop when the tools are selected. If properly planned, and with the resources needed to accomplish it within a reasonable amount of time, having an Enterprise SCM solution can't be beat. The transition needs to be driven by an understanding of the problems to be resolved, not the symptoms of those problems or some reactive response to improper use of the infrastructure already in place. Design your solution for the general case so that both the worst case and the best case are covered. And don't rush the transition, make haste slowly!

Ben Weatherall is currently based in Fort Worth, Texas where he practices Practical CM on a daily basis supporting a modified Agile-SCRUM development methodology. He uses a combination of AccuRev, CVS, Bugzilla and AnthillPro (as well as custom tools). He is a member of IEEE, ASEE (Association of Software Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), FWLUG (Fort Worth Linux Uscers Group), NTLUG (North Texas Linux Users Group) and PLUG (Phoenix Linux Users Group).

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment