The antithesis as presented by Marc is rather extraordinary, and it does not reflect the approach that many product development companies apply, nor does it reflect the approach of modern (S)CM tool vendors.
- CM and SCM both are about control. But in general, software development project have a very fast cycle of change, sometimes spanning to minutes, resulting in often and fast changing configurations. CM (as in ITIL) deals with slowly changing configurations that may take months, where every change is carefully planned and deployed.
- SCM is very dynamic, while CM is rather static. But both aim for a controlled process to manage change from one configuration to the next.
- Neither CM nor SCM is a restriction of the other. Indeed, SCM is about software not because it happens to be "software", but because it is a rapid kind of CM that is mostly found in software development. But in practice also (some) hardware development have similar rapid CM dynamics.
- CM seldom aims at producing from scratch. Many organisations have a defined process configuration (procedures, tools, etc.) and grow to the next generation. It hardly ever occurs that organisational processes are produced from scratch. Every individual configuration item is accurately identified, including a version id, to identify the contents of the configuration.
- SCM also aims at producing either as development or maintenance. In both cases, the objective is to produce the next version of the system, which is expected to be an improvement compared to the previous one. Because of the high dynamics at a low level of detail, identification is essential to distinguish between (the contents of) different configurations.
- When taking into account classical CM tools, they indeed mainly focus on storage of the current configurations, without much caring about the dynamics of change. So, from this perspective SCM is not pro-active or prescriptive at all. It is generally accepted that SCM is more than mere version control.
--
FrankSchophuizen - 02 Jun 2003
See also
Brad's reply.
[Moved to a new page by
MarcGirod - 06 Feb 2007]