Is CM about maximizing change or about minimizing change?

“Not every change is an improvement, but an improvement is always a change”

Configuration management is about managing change, assuring the integrity of the business assets during their lifecycle. This implies that the work products of a project are protected against loss or damage. Every change is a risk of introducing bugs, damaging the existing functionality or degrading the system’s performance. A good way to assure the integrity is to minimize the amount of change: if you don’t change it, you can’t break it.
This is precisely what a CCB (Change Control Board) is doing. Every change request is discussed and only when the business value of the change is high enough, the change is accepted for implementation. Other changes are rejected. Thus, the system will undergo minimum change and minimum risk of degradation. A positive side-effect is that this approach leads to minimizing costs and to minimizing time-to-market: if you don’t change much, it does not cost must money or time.

On the other hand, especially in a consumer market of retail or professional products such as mobile phones, audio and video equipment, medical diagnostics and treatment systems, transportation or manufacturing, the competition is tough. The game here is to maximize the amount of functionality, to maximize the level of quality, but at the same time to minimize the costs and to minimize the time-to-market.

Now what should configuration management aim for: minimizing change or maximizing change?

Well, in fact the answer is quite simple: that’s not up to configuration management. Regardless of the amount of change being high or low, configuration management should manage the work products and their changes, assuring their integrity. The decision to minimize or maximize change is a business decision. This may be different for different businesses, but also for different projects within the same business. It may even be different depending on the time of the year (e.g. Christmas season). But of course, the CM approach must be different in both cases, so it must be aware of the business situation.

This implies that there is no single best CM approach; there is no one-fits-all solution. To find a common solution, we need to focus on the one thing that both have in common: change will happen! Any change may be an improvement or a degradation (or both). We must avoid that changes that we don’t want are slipping through to the customer, and we must assure that changes we do want are actually brought to the customer, with quality and in time.
This requires at least a proper level of visibility, which bring us to the four pillars of CM:

  • What changes do we want, and what changes don’t we want? (Configuration identification)
  • What solutions do we have, and which ones don’t we have? (Configuration control)
  • At what stage is every change? (Configuration Status Accounting)
  • Are we sure about that? (Configuration auditing)

The most important job of configuration management is to achieve a maximum speed for propagating desired changes, for instance storage when the change is available, promotion when the promotion criteria (e.g. quality criteria) are met, distribution to the teams for the next processing step (e.g. verification) and communication for visibility (e.g. to enable project monitoring and control). But at the same time configuration management is to detect undesired changes as soon as possible (preferably before someone is working on them), and stop the propagation of solutions of undesired changes when they slip through or when we change our minds about desired and undesired changes.

So it is always a balance between speed and control, between volume and quality, between maximizing and minimizing change. Moreover, it is a constantly change balance too, which makes the profession of Configuration Management a challenging and interesting one!

Advertisements

About Frank Schophuizen (fschop)

Hi, my name is Frank Schophuizen and I am working as a consultant in CM, Agile and ALM for TOPIC Embedded Systems. I have over 30 years experience in software development in the technology industry, with the last 15 years mainly in process improvement, deployment and integration of methods and tools in the area of CM, Agile development and ALM. I am strongly interested in the complexities of collaboration and integrations in multi-project and multi-site organizations. I have worked with various technology companies such as Philips, ASML, NXP and Vanderlande, and with various tool vendors such as IBM Rational (e.g. ClearCase, Synergy, Jazz products) as well as open source tools (e.g. SVN, Git, Jenkins, Trac, Eclipse). I am living in Eindhoven, the Netherlands, with my wife. We have 3 adult children. My main hobbies are classical music and photography.
This entry was posted in configuration management. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s