Jan 192009
 

How much architecture does an agile team need up front? Most agile methods are surprisingly silent when it comes to this question. Scrum regards architecture as an issue the team has to deal with on its own discretion — and thus does not include any advice. In Crystal Clear: A Human-Powered Methodology for Small Teams, Cutter Senior Consultant Alistair Cockburn suggests having a lead designer who is responsible for creating the system architecture description — “usually fairly early in the first iteration” — but also emphasizes that “the architecture will probably evolve” and gives two strategies to help evolving: Walking Skeleton and Incremental Rearchitecture.

XP finally suggests using a metaphor to keep up the technical vision of the system; unfortunately, one of the most neglected practices of XP. XP also relies heavily on refactoring to evolve the architecture in addition to unit tests to scaffold it. In the second edition of his book Extreme Programming Explained, Cutter Senior Consultant Kent Beck finally introduced the architect as a role in the XP team, emphasizing that,

Architects sign up for programming tasks just like any programmer.

Consequently, whenever there is an open space on agile development, the architecture question comes up invariably: “How much architecture do we need up front?” My standard answer to this question is: “31 square feet.” Since the answer is not obvious, I will explain it a little bit further.

First, we have to understand that there is no software system without an architecture. The architecture may be adequate or not, it may meet your nonfunctional requirements or not, it may be helpful or troublesome, it may be obvious or extremely dodgy, but it always exists. There is no way to build software without building an architecture. But of course, there are millions of well-trodden paths toward extremely bad architectures.

The second insight is that there is only one place where the true architecture of a system resides: the code. You may have tons of PowerPoint presentations about “your architecture” or not a single one: in any case, it is only the architecture living in the code that determines the nonfunctional behavior of your system, such as maintainability, readability, performance, scalability, and so on. Therefore, architects not walking in the code up to their waists are similar to nannies refusing to meet children — and as helpful.

This also means that there can be nothing like an up-front architecture before coding starts: no code, no architecture. All you can have is an up-front vision of the architecture, a goal you’re heading for. The vision may be very coarse, like the XP metaphor, or extremely detailed, like the 200-page architecture document I wrote back in 1993 for my first crashed project.

So we have to rephrase the initial question: How much up-front architectural description does a team need to create a software system with a helpful architecture? Today, many architectural choices are already made by frameworks and application servers, so there is no longer any need to deal with all the details of database access, transaction handling, and all this stuff in many projects. But every project needs a domain vision — an idea shared and followed by the whole team about the structure of the core domain classes and how they interact. A good architecture consists of only a handful of classes, maybe six or 10. Everyone in the teams is on a first-name basis with these classes, and everyone knows under which classes’ umbrella new, smaller classes belong. The structure of these core classes is quite stable and usually not subject to refactoring.

The size of a standard white board is 31 square feet. This should be sufficient to capture a UML-like diagram of these classes as it was developed very early in the project. The white board should be easily accessible in the team space and this should be the place where architecture and design discussions are conducted. For many projects this is sufficient unless they have extra documentation requirements, in which case I suggest writing the architecture description document quite late based on what you extract from the code. If you are surprised by what you find, you may have an interesting issue to talk about during your next retrospective: not only the fact that the vision may have gone astray, but particularly the fact that you were not aware of the problem earlier when you worked on the code.

avatar

Jens Coldewey

Jens Coldewey, based in Munich, Germany, is a Senior Consultant with Cutter's Agile Product & Project Management Practice. He specializes in deploying agile development and object-oriented techniques in large organizations.

Discussion

  2 Responses to “The 31-Square-Foot Architecture”

  1. Let’s see how these arguments play in the original realm of architecture, i.e. building:
    “There can be nothing like an up-front architecture before building starts”. “There is only one place where the architecture resides: brick and mortar”. “Architects not up to their elbows in mixing cement and laying bricks are … etc”

    Clearly something wrong here, and an indication of an idea that has been pushed too far. It might work for a garden shed, but probably not for a house and certainly not for a skyscraper.

    Granted the map is not the territory, and the territory may turn out to be somewhat different from the map, but that doesn’t mean that maps (architectures) are pointless, and that every journey must be an exploration of uncharted territory.

    Let’s get back to common sense. The amount of upfront architecture that’s needed depends on the size and complexity of the system, the experience of the team(s) working on the project, and many other factors. That may be 31 square feet or 50 slides or 100 pages. Emergent design may be appropriate for some projects in some environments, but a one-size-fits-all approach is just dogmatic.

  2. Tom,

    I prefer calling the approach provocative rather than dogmatic. Of course you are right, there’s no one-size-fits-all: If you have an embedded system you may be forced to design some aspects of the SW/HW interface very early. However, this the kind of architecture I was talking about: The core vision the team keeps and follows in their design. If you need 100 pages to describe this vision, you may want to invest some time to extract the core ideas and separate them from detailled (and probably too early) decisions about the design. If you cannot do that in a given project, I’m ready to question, whether that vision exists at all – even at the risk of being called a dogmatic.

    The comparision with building architecture falls short in my opinion, because it compares two things that are very different: Software and buildings. Buildings have some very tangible mostly 3-dimensional properties and their design goes along a few well-known physical characteristics, expressed by mathematical formulas. On the other hand buildings are very hard to change once they have been set up.

    Software is inherently intangible, does not have a clear dimension (though many argue that it is multi-dimensional) and has some non-deterministic properties that qualifies it as complex system in the sense of Chaos Theory. This is the bad news and the reason why upfront-designs work so poorly as compared to building construction. The good news is that software is changeable, at least if done right.

    One of the core ideas agile inherited from lean development is to make decisions as late as possible but not later, so you know more alternatives and have a better understanding of the forces and implications in your system. In building construction this “as late as possible” is during detailled planning while detailled construction in software takes place during programming. In software the detailled plan is runnable itself. One of the consequences of this is that a good vision is more important than 100 pages of detailled decision that most probably have been made too early to really understand their implications.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)