Evolution Perspective

A somewhat overused business maxim tells us that the only constant is change, and most software architects can identify strongly with this. The very ability of software to be "soft" means that stakeholders expect a software-based system to be able to evolve very quickly. Couple this expectation with other common factors such as misunderstood requirements, rapid business change, and the effect of actually delivering a system on end-user requirements, and it is easy to see why change is such a major factor in the lives of software architects.

The commonly adopted iterative approach to system delivery can make an ability to deal with change all the more important. When a system is delivered in iterations, its users can start using some parts of it much earlier and thus provide early feedback to the developers. This is an extremely valuable process because it allows requirements to be validated early. However, it also means that there is constant pressure during the delivery cycle to change the system's behavior.

Although, in principle, software is easy to change, experienced software developers agree that this is true only if change is explicitly considered during its development. Software developed without any concern for the changes that will likely be needed can be much harder to change than anyone expects.

We consider the process of dealing with change in the system development lifecycle under the term evolution, by which we mean all of the possible types of changes that a system may experience during its lifetime.

This perspective addresses the concerns relevant to dealing with evolution during the lifetime of a system and so is relevant to most large scale information systems because of the amount of change that most systems need to cope with.

Desired Quality	The ability of the system to be flexible in the face of the inevitable change that all systems experience after deployment, balanced against the costs of providing such flexibility
Applicability	Important for all systems to some extent; more important for longer lived and more widely used systems
Concerns	- magnitude of change - dimensions of change - likelihood of change - timescale for change - when to pay for change - development complexity - preservation of knowledge - reliability of change
Activities	- characterize the evolution needs - assess the current ease of evolution - consider the evolution tradeoffs - rework the architecture
Tactics	- contain change - create flexible interfaces - apply change-oriented architectural styles - create variation points - use standard extension points - achieve reliable change - preserve development environments
Pitfalls	- prioritization of the wrong dimensions - changes that never happen - impacts of evolution on critical quality properties - lost development environments - ad hoc release management

find out more about the Evolution perspective ...