Agile architecture metrics
In developing software there is a need for communicating ideas and chosen directions among team members and customers alike. Some sort of overall view and common vocabulary about the domain provides understanding of the system and is a basis for discussion. Software architecture provides such a “gestalt perspective” and is therefore very useful in any but trivial software development effort. In agile methods there is no BUFD, but how do you know you are doing enough architecture?
Lets take a quick look at what three well known methods have to say about architecture.
In XP architecture is just as important as in any other software project [Beck00: pp 113]. XP used the notion of the system metaphor to cope with software architecture up front. The system metaphor is used to create the big picture of the system, the vision of the system’s components and how they work. About 8 years ago Kent Beck defined it as:
“System Metaphor – A story that everyone – customers, programmers, and managers – can tell about how the system works.” [Beck00: pp. 179]
You can learn about the problem at hand by using spikes. The spikes drive the System Metaphor. So even in XP you can have initial “architectural” work to set the baseline for understanding, communication and vision. Kent Beck was quoted saying “The first iteration must be a functioning skeleton of the system as a whole.” [Wake02: pp78].
Unified Process (they say it’s agile)
The UP creates high level architecture in the inception phase. It then creates an appropriate executable architecture during the elaboration phase. The architecture tackles risks, develops a common understanding and is the basis for identifying reuse and for further development during the construction phase [Kroll03: pp120].
Feature Driven Development
FDD suggests that architecture could evolve in parallel during the Develop an Overall Model, Build a Features List and Plan by Feature processes. The goal is to have enough architecture ready to start iterating though the Design by Feature and Build By Feature processes [Palmer02: pp. 204]. During the first iterations a lot is learned about the system and the architecture keeps evolving until it becomes more or less stable during the project.
The common thing here is that they all do upfront work prior to development to establish common understanding about the system domain and functionality. UP does a lot, FDD does less and XP does the absolute minimum. The effort for getting the big picture right is higher initially and then decreases as iterations and increments pass. In agile projects you keep on learning and adapting and therefore do not stop doing architecture work until the end of the project.
So all this would mean that in a healthy agile project you will see something like depicted in the figure below.
Initially you spend more effort on architecture compared to developing features. The amount of architectural work will decrease over time but will only be done when the project is finished. The effort spend on features will increase. So you should also see a steady increase in the number of Running Tested Features http://www.xprogramming.com/xpmag/jatRtsMetric.htm.
By defining some architecture upfront you optimize your throughput not at the level of the current iteration but at the release level as discussed in YAGNI by the book.
[Beck00] Beck, Kent. Extreme Programming explained.
[Beck01] Beck, Kent and Martin Fowler. Planning Extreme Programming.
[Wake02] Wake, William C. Extreme Programming Explained.
[Palmer02] Palmer, Stephan. Feauture Driven Development.
Prinice Hall. 2002.
[Kroll03] Kroll Per and Philippe Kruchten. The Rational Unified Process Made Easy.