Architecture and agility: the ultimate trade-off?

Architecture-centric design is meant to minimise the probability that structural changes in the system will occur.

Changes in a system, as pointed out in the great “Software Architecture in Practice” book from the Software Engineering Institute (SEI), can be either:

• Local - affecting only one element;
• Non-local - affecting multiple elements but not the architecture itself; or,
• Architectural - affecting the pattern of the architecture, i.e. the “fundamental ways in which the elements interact with each other”.

The system structure should therefore be created in a way that it minimises the likelihood of architectural changes. If possible only local changes should be necessary. 

Of course this requires design to be done upfront which is something that some “agilists” love to hate.

In fact, by using an architecture-centric approach such as the Attribute Driven Design (ADD) the system is decomposed recursively into components in a way that the desired qualities are achieved. The system can then be developed and prototyped incrementally like a skeleton into which the components can be added, tested and refined until the final product is achieved. This also allows components to be developed externally with minimal risk.

This kind of approach ensures that the system qualities, or non-functional requirements, are met, also in expected growth scenarios.

At first glance it contrasts with agile methodologies such as Scrum. These are based on developing in small iterations that build functionality incrementally. Each of these “sprints” is a small project that takes a chuck of requirements, or user stories, from the product backlog, and provides an increment to the product. Requirements are not very clear until they get prioritised and included in a sprint.

This approach is usually focused on functional requirements but it doesn’t have to be. As long the architect is involved in the development process, the backlog prioritisation is aligned with architecture scenario-based priorities, and enough design decisions are done upfront, there’s no reason why Scrum and Architecture can’t provide synergies. Moreover, architecture intermediate reviews or even trade-off analyses can be performed during the development process, after certain iterations.

After all, agile methodologies are frequently applied in projects where the architecture is implicitly defined anyway, via frameworks such as Spring, Hibernate, Grails, etc. So the idea of "no design upfront" doesn't really apply.