Building Evolutionary Architectures

For a long time, the software industry followed the notion that architecture was something that ought to be developed and completed before writing the first line of code. Inspired by the construction industry, it was felt that the sign of a successful software architecture was something that didn’t need to change during development, often a reaction to the high costs of scrap and rework that would occur due to a rearchitecture event. This vision of architecture was rudely challenged by the rise of agile software methods. The pre-planned architecture approach was founded on the notion that requirements should also be fixed before coding began, leading to a phased (or waterfall) approach where requirements was followed by architecture which itself was followed by construction (programming). The agile world, however, challenged the very notion of fixed requirements, observing that regular changes in requirements were a business necessity in the modern world, and providing project planning techniques to embrace controlled change. In this new agile world, many people questioned the role of architecture. And certainly the pre-planned architecture vision couldn’t fit in with modern dynamism. But there is another approach to architecture, one that embraces change in the agile manner. In this view architecture is an constant effort, one that works closely with programming so that architecture can react both to changing requirements but also to feedback from programming. We’ve come to call this evolutionary architecture, to highlight that while the changes are unpredictable, the architecture can still move in a good direction.