The 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.

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	product management magnitude of change dimensions of change likelihood of change timescale for change when to pay for change changes driven by external factors 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 extensible interfaces apply design techniques that facilitate change apply metamodel-based architectural styles build variation points into the software 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 overreliance on specific hardware or software lost development environments ad hoc release management