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|