Product and Project Software Configuration Management (SCM)

the one or two projects that they will be around for. It is easier to "come in", and hack something together fast, and get a group up and running and impress management and "ride off into the sunset". But the poor folks who are stuck with the internal support and maintenance of the ill-structured, un-factored, poor-quality code are the ones that the company may end up spending a LOT more money for in the long-run.

Just because we are picking on "consultants" here, doesn't mean that organisations doing it all themselves don't suffer from similar problems. We have seen short term "project thinking" within a large programme of internal development - the teams came together, delivered the projects and then were disbanded (due to internal charging models) without paying much attention to the long- term maintenance requirements.

Deployment Models
There are many possible models of deployment which can apply, particularly to products:

• local deployment & installation, with a private/independent "copy" at each installed site

• centralized, shared, monolithic, such as a travel service web site, or even something like Google Docs
• decentralized and distributed.

There are others too. Each one of these may or may not lend itself well to a particular maintenance and support model:

• supporting multiple historical versions

• supporting only current version while working on the next one
• supporting a product-family of variants of the same set of components

Which model you use depends primarily on upon total number and type of distinct customer-bases and the market (i.e., how likely it is you can expect them to be willing and able to upgrade to new major versions and how much they are willing to pay you to support older ones).

Architecture/SCM/Organization
With the above definition, we can review some of the SCM considerations as to the difference between Products and Projects. We have spoken often about how many release engineering issues can be addressed by a balance of Architecture, Organizational approach, and SCM Strategy.

Also using the above definitions, we can consider project SCM needs to be a subset of product SCM.

Product Development tends to have release lines - potentially multiple independent projects under development at the same time.

As Laura Wingerd discusses in Chapter 7 of her O'Reilly Book (Channeling the Flow of Change):

The Ace Engineering story illustrates typical problems of the software life cycle:

• First, at anypoint in time there is likely to be more than one supported product version available to customers. Ace must be prepared to field customer calls, diagnose problems, and fix critical bugs in all of their currently supported versions.

• Second, not all development tasks have the same urgency. Some are expected to yield results immediately while others are targeted for distantly future releases.
• Third, software development is not entirely predictable; some projects go according to plan, others get mired in unforeseen difficulties.

Laura presents release and project branching patterns, and also discusses the Mainline branching model.

The ITIL Service View
Many organisations undertake a variety of internal projects which deliver new or enhanced applications or systems into live usage within the organisation. A typical new system (or Product), delivered as part of a project might follow a lifecycle and branching model shown below.

From an ITIL viewpoint, the Service Transition phase (e.g. into Live usage) is very important and one of the key measurements is the ongoing documentation and support processes to allow the system to be cost effectively maintained in the future. This recognises the reality that the initial development