Perceptions of SCM

People often have a perception of SCM which is both shallow and narrow. They tend to consider SCM only as a support function, in the context of software development. As a result, they would fail to identify as SCM problems, symptoms they meet in arbitrary domains of their experience. Let's try to give a couple of examples.

1. When releasing software to customers, one is faced to several problems:

• How to minimize downtime, in order to install the updates?
• How to manage custom changes for one customer, with respect to main line development?

These questions take a different context, if we consider that some SCM tool could be embedded in the product, and that the releases could happen under its management. I do not go into details here, but want only to show that SCM may be part of the product itself, and need not be restricted to the realm of the development environment.

2. Looking at job offers in specialized sites, one meets a huge amount of data offering lots of redundancy. The tools available seem all to be geared toward the production of data, by filling in templates. Very few is done to assist factoring commonalities and extracting differences, which would typically be an SCM approach.

3. The postmodern world is plagued with an overwhelming abundance of data, and a lack of support to memorize, analyze, classify, compare, the various representations under which information reaches us. All these tasks have a generic component (beside the obvious semantic one, requiring careful expert analysis), which cries to be identified as an SCM requirement.

The common culture turns its back to management concerns. Graphical User Interfaces and web tools serve only specific, predefined, purposes, and make it difficult to cross these boundaries.

-- MarcGirod - 16 Dec 2007