Is Agile Architecture Oxymoronic?

TL;DR

Software architecture is the important part of the software structure that is costly to change once implemented.

With agile engineering practices, software structure is easier to change. Architectural design issues becomes non-architectural when irreversibility can be overcome. Thus, less architectural decisions are required upfront.

Waterfall Architecture

In traditional SDLC environment, software architects create architectural artifacts such as UML, sequence diagram, use cases and ERD, and submit them to the Architecture Review Board (ARB) for blessings. Approval from ARB is required before funding is approved.

The objective is to ensure compliance to architectural standards and improve the re-usability of technology stack and application components. This approval process looks great in cleanly drawn swim lane diagram except that reality is often riddled with exceptions.

“Everybody has a plan until they get punched in the face” — Mike Tyson

Agile Architecture

In agile, we embrace changes. The agile approach starts with a minimal architecture and enables the architecture to evolve as the team learns about the technical requirements and constraints of the operating environment.

There are two key principles underpinning the agile architecture approach:

1. Defer decisions to the last responsible moment

Making decisions at the Last Responsible Moment isn’t procrastination; it’s inspired laziness. It’s a solid, fundamental risk avoidance strategy. Decisions made too early in a project are hugely risky. Early decisions often result in work that has to be thrown away. Even worse, those early decisions can have crippling and unavoidable consequences for the entire future of the project — Jeff Atwood

2. “Continuous attention to technical excellence and good design enhances agility” — Agile Principle #9

Agile software engineering practices such as test-driven development (TDD), continuous integration and technical spike keep software ‘soft’ and malleable. With agile engineering practices, adapting to technical changes is much easier than waterfall approach. Corollary, lesser need for upfront architectural decisions.

Key differences

1. Although there are less upfront architectural decisions in agile, the effort to identify software structure that is costly to change remains. Agile development team will still benefit from someone who is familiar with the technology stack to identify potential architectural concerns.
2. Agile team uses technical spike to identify architectural concerns and make architectural decisions. Unlike waterfall, these activities are performed throughout the delivery and are less time-compressed. By deferring important architectural decisions to the last responsible moment, agile avoids the most common architectural evil — premature optimisation.
3. In waterfall, the traditional architect produces comprehensive design blueprint for implementation. In agile, the team defers architectural decisions to the last responsible moment by reducing the cost of change, which requires more finesse than traditional approach.
4. In agile, architecture is a more of an activity performed by the agile team. In waterfall, architecture is often centred around a role. And as a result, it often sends a wrong message that developers do/need not participate in architecture activities.

Conclusion

Contrary to popular myth, there is no dichotomy between agile and architecture. Architecture is important in agile, albeit a different mindset and different approach. If your organization is adopting agile, try to use a different archetype instead of architect. In GDS, a technical leader leads the architecture activities. A different archetype helps to change people’s expectation and drive behavioural changes.

If you enjoyed this piece, you might like to read about our technical adventure and how we test and refactor CSS in Business Grants Portal

Sharing is caring. Please ❤ if you find this useful. Let’s make our software industry more awesome.

Cheers! :)