Agile Architecture - Oxymoron or Sensible Partnership?

 A number of commentators have been talking about the perceived dichotomy between Agile techniques and architectural thinking.  

In the Agile world architecture is often perceived as BDUF (Big Up Front Design) and as a result is frequently overlooked or delayed in the spirit of “YAGNI” (You ain’t gonna need it).

On the other hand, as stated in the March/April 2010 edition of IEEE Software Magazine: 

Agile development has significantly impacted industrial software development practices. However, despite its wide popularity, there’s an increasing perplexity about software architecture’s role and importance in agile approaches. Advocates of architecture’s vital role in achieving quality goals for large software-intensive systems doubt the scalability of any development approach that doesn’t pay sufficient attention to architecture.

IEEE focused a special edition on the relationship between Agility and Architecture, exploring the “false dichotomies” in the tension between Agility and Architecture.

In the introduction to the special edition the editors quote some of the leading Agile thinkers’ perspectives on architecture:

There’s also the drive to “deliver value to the stakeholders” right from the first sprint or iteration. But what if the developers, not just the end users, are a key class of stakeholders? Alistair Cockburn developed strategies for starting with a walking skeleton, then evolving it iteratively.  Mary and Tom Poppendieck came up with the notion of “divisible system architecture.” And finally, Kent Beck’s advises that “architecture is just as important in XP projects as it is in any software project. Part of the architecture is captured by the system metaphor [one of the XP practices].”

The article goes on to identify the “Real Issues” that need to be addressed in resolving the perceived conflict between Agile and Architecture: 

• Clarify the semantics – what does the organisation or project actually mean by “architecture”.   Not all design decisions are architectural, in fact very few design decisions are architecturally significant, and in many projects they’re made very early in the development process. 
• Context is key – the project’s environment: aspects such as the organisation, business domain, existing technologies , project size, business domain,  rate of change, system age, criticality,  governance, market situation and  expected life span all impact the need for architectural decision making. 
• When in the life cycle – architectural decisions should be made early enough in the life cycle because “architecture encompasses the set of significant decisions about the structure and behaviour of the system.” These decisions will be the hardest to change later, so architectural stories need to be interwoven into the functional stories in early iterations.
• The architect’s role – Martin Fowler talks about two architectural perspectives:

o   Architectus reloadus – the make and keeper of big decisions focusing on external coordination, and

o   Architectus oryzus – code-facing, mentor, prototypes and troubleshooter focusing on internal coordination within the development team

• Not all documentation is bad – in most circumstances architectural requirements can be expressed as a “walking skeleton” prototype of the eventual target architecture supported by a few solid metaphors.  Sometimes, however, there might be a need for a more explicit architecture document, perhaps to prove compliance with external regulations or to convey to a large, distributed team.
• Architecture has methods – the Agile methods tend to be fairly silent on how to go about defining architecture, even those that explicitly state the value of architecture.  It can be worth spending some time and effort exploring some of the available architectural methods (the article lists a number of them).
• Architecture has value – the cost of architecture is easy to show, especially in BDUF approaches, but the value may not always be immediately visible.  Expressing the architectural needs in business value terms helps to expose the value that architecture delivers in the project.

Uncle Bob (Martin) wrote in the Object Mentor Blog that:

One of the more insidious and persistent myths of agile development is that up-front architecture and design are bad; that you should never spend time up front making architectural decisions. That instead you should evolve your architecture and design from nothing, one test-case at a time.

 Pardon me, but that’s Horse Shit

 This myth is not part of agile at all. Rather it is an hyper-zealous response to the real Agile proscription of Big Design Up Front (BDUF). There should be no doubt that BDUF is harmful. It makes no sense at all for designers and architects to spend month after month spinning system designs based on a daisy-chain of untested hypotheses. To paraphrase John Gall: Complex systems designed from scratch never work.

 However, there are architectural issues that need to be resolved up front. There are design decisions that must be made early. It is possible to code yourself into a very nasty cul-de-sac that you might avoid with a little forethought.

 Notice the emphasis on size here. Size matters! ‘B’ is bad, but ‘L’ is good. Indeed, LDUF is absolutely essential. 

Some concrete advice can be found in the Agile Architect website:

Agile development methods attempt to improve the software development process, so that we can deliver useful solutions more often, and more quickly. However, despite some successes larger organisations and projects have been very slow to adopt them. One of the reasons is that many agile methods are perceived as architecturally weak, disconnected from the realities of delivering large systems in complex enterprise environments. At the same time, many architecture processes are seen as slow, clumsy and bureaucratic. They would benefit from a more agile approach. This web site looks at ways to confront this dilemma, by bringing agility to architecture and architecture to agility.

The site discusses the role of the Agile Architect and some Principles for Agile Architecture. 

How does your team bridge the gap between DBUF and LDUF, is there a conflict between Agility and Architecture?