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.
How does your team bridge the gap between DBUF and LDUF, is there a conflict between Agility and Architecture?
More references on Agile Architecture
* Cope and Kevlin, also on InfoQ:
* Scott Ambler:
* Eoin Woods preso at OOP2010
* And Cope's upcoming book on Lean Software Architecture
Re: More references on Agile Architecture
Upcoming books: Agile & Architecture
The second is mine: Just Enough Software Architecture. I have some sample chapters posted too, and some sections of the book are the subject of blog posts. There's also a video of me on the topic at an Agile Denver group meeting.
Why myths about architecture exist in Agile?
And because YAGNI is very very convenient banner for young, or inexperienced, or simply unskilled developers to hide behind.
Imagine that we try build skyscraper with YAGNI and no architecture upfront: in a sprint we try to add few more floors and then ask customer if that is enough? and then add more and then learn that it needs electrical wires inside, and say, OK, no big deal, we now just need to tear walls apart and drill holes, no biggie :) :)
Re: Why myths about architecture exist in Agile?
The example provided is incorrect because if you are making Sky Scrapers you will not get house masons to build them. If you get the great guys(experienced) you should never/rarely come up with a situation where wiring and plumbing is left behind or they (great guys with no experience in building Sky Scrapers) would have the "courage" to say that we have not built Sky Scrapers ever and it will take us x Years to build expertise in this areas if you want us to do it. If you want it done earlier we are not the best guys.
Remember, Kent Beck described four values of XP -- communication, simplicity, feedback and courage. Though I do agree some people may be mis-using the Agile principles as you suggest, but then I know of nothing that cannot be misused ;-).
Thanks for the great article!
Re: More references on Agile Architecture
I find the talk "Emergent Design & Evolutionary Architeture" by Neal Ford quite enlighting on this topic as well:
For sure! His IBM article series are arguably the most practical and well-rounded source about Agile Architecture today.
Evolutionary architecture and emergent design: Investigating architecture and design
Thanks for the video!
Re: Why myths about architecture exist in Agile?
The reason: cost of change. When you're dealing with "hard goods" like concrete, steel, etc it is VERY costly and difficult to change your mind once you've entered "implementation". Not inherently true with software - it's "soft".
Granted, with software, poor design (all too common) can make change difficult - and in fact this is one of the core reasons for evolutionary design. As counterintuitive as it may seem, experience shows that people who evolve their design, paying close attention to cleanliness all steps of the way, will end up with a much leaner and cleaner design than those who try to spec it all out up front.
Actually, the misunderstanding of architecture as a method or process, even a synonym of waterfall, is clear. There is a problem, though, as there are still many of those voices that think of architecture as design, as blueprints, instead of what it really is: the structure of something that actually exists.
So, the job for an architect is to own the architecture (doesn't mean to design up to the tiniest detail, or even code). The system construction with a healthy architecture is vital, but how does an architect takes care of the architecture during the system construction? Well, we have several methodologies. Some are agile. I we look at that this way, we can see we are comparing apples to cherries here.
Furthermore: Architecture is not BDUP, and it is not just LDUP either, and it is not even just systems construction. Architecture goes beyond that. It is needed when a system needs to be maintained, updated, extended, integrated...
William Martinez Pomares