Agile Architecture

Updated for republication in MrBool.

As readers of my blog must have noticed by now, I am somewhat of an advocate of Extreme Programming (XP). However, for the last nine months or so, my title has been “Lead Software Architect”, and I am the (proud?) author of what Martin Fowler calls “the almighty thud” documents. XP is traditionally skeptical of architects, and often with just cause. I’ve frequently heard the term “architect” defined as someone who restricts the options of developers – a definition I don’t particularly care for. Is it possible to reconcile extreme programming and software architecture?

I have found more and more that my greatest strength is abstract thinking and simplification, but without losing touch with the code. For me, architecture is not about setting rules and honing checkstyle configurations. It is about seeing, defining, inspiring, and communicating the vision of a simpler, more robust, more secure software system. I think inspiring developers is key: A software architect has no way of forcing his will on the developers. If developers don’t like your cool architectural drawings, they will simply ignore them – and they are probably right to do so.

A good architectural description has the following characteristics:

  • It’s both descriptive and prescriptive. It leads the way for the application to develop, but it also reflects the current state of the application.
  • It simplifies: I like to say that the ideal architectural description is almost, but not completely, too simplified to be useful.
  • It focuses on being communicative rather than truthful. This means that MDA, CASE, and BPEL will provide poor architectural descriptions. Martin Fowler calls this approach UML as sketch.
  • It is the springboard and basis for conversation, discussions, and discovery.
  • It highlights important issues that should be remembered and debated.

An agile architecture should provide inspiration, for example in the form of informational posters in work areas, lavatories, or lunchrooms. These displays should highlight issues that the developers should keep in mind, like security, performance, reliability, and scalability. It should inspire everyone to do a better job. And the architect must be available to discuss the details. The architecture that can be described is not the true architecture – the true architecture resides in the minds of all developers in the project.

Comments:

Dan Johnsson - Jun 27, 2005

I really like the stress on the communiction. To me the role of the architect is twofold 1) to keep and evolve the vision (gutfeeling, dream, understanding: take your pick) of the system as a technical artifact 2) to communicate the vision to everybody - developers, testers, users, PLs, board, investors … whoever

ps Welcome back Johannes, we (the world) have been missing your blogentries