[Blogging is a bit like working out in the gym - when you get out of the habit, it is so hard to get back into it. So here goes with my first day back on the blog-cycle. dja]

Here is a meme for an agile architecture control board - no it's not a committee - board is used literally. During recent FDD projects, we've taken to using a white board with the object model / functional architecture as a visual control and communication mechanism. Figure 1 shows such a board from a recent real project building telecom grade infrastructure.

Figure 1

The board shows the entire domain object model for the seven week iteration. Note that the project is being built with a Coad Method architecture where the domain model directly reflects the classes being built. There is no concept of an "analysis model" and a "design model", they are both the same. The dotted lines on the board show package level separation and there are small arrows showing the package direction dependency. The detailed design causes small changes to the model to resolve two way dependencies and occasionally to refactor the original model as more understanding was gathered in the detailed design stage. The names of class owners are also written on the board. Any team member can come by at any time and see what represents the definitive architecture for the iteration and see who they should be working with to complete any given feature or set of features.

Note the screen in front of the board. This is deliberate. It's a pair programming station which also serves other purposes. The morning standup meeting is held in front of the board to aid communication. The CP running the meeting directly enters issues and feature status updates into the KMS accessed via the computer. This way project status is electronically captured immediately in the standup meeting.

The machine is also used for refactoring work where the agreed changes have been modeled on the whiteboard first. Typically refactoring is at the package level, i.e. a group of classes are being assigned into a package. We practice a technique of assigning packages and component boundaries at the last responsible moment. At the beginning of an iteration all the classes are in one package often simply called "domain". As the project continues and the interfaces between classes are firmed up with detailed design, then component boundaries are fixed and classes are repackaged. I'll be talking more about this "bottom-up" style of distributed architecture at Borcon 2004 in September.

Figure 2 shows a print out from Together-J with the domain model from a previous iteration. This printed model together with the whiteboard model represent and the working architecture for the current project. There is only a one class overlap between the two diagrams - the leftmost pink class in Figure 2 is the 3rd pink from the left on the top row of Figure 1.

Figure 2

Figure 3 shows an adjoining whiteboard which contains the map of package/component dependencies for the entire project. All of these design diagrams are available in the project control room and anyone in the team can come and look at them and hold team discussions to modify and update them. A general rule exists that no one team member is allowed to make a change. Changes to the architecture require a consensus of chief programmers and other senior members of the team.

Figure 3

Now it might be easy to say - gee we could do all of this electronically - and yes you could! In fact a tool like Together can generate the HTML documentation for all of this directly from the source code and publish it to an intranet site such as an FDD KMS but...

The electronic version is not so accessible. A group can't so easily gather around a screen as they can a whiteboard. Changes are not so easily made on the screen and require the use of the tool and the use of version control software. The electronic version is buried inside a web site and not every team member will visit it and look at it, when it is on the wall everyone sees it, at least once per day. The version on the board is considered definitive. If someone brings a design or code for review which is not congruent with the board then the review should be rejected. If the board is out-of-date then that must be fixed and clearly communicated to the whole team before the review material is passed.

Sketching versus Design

In the product design world, they clearly understand the concept of a sketch - an idea, a work in progress - from a design - a plan for something to be manufactured. Designers use subtle clues to separate sketches from designs such as elongated lines, rough approximate lines, sketch strokes and other noise in the image to communicate "This is not finished! It is just an idea".

The architecture control board model counts as a design. It is not supposed to be reworked constantly - in fact, rework and changes happen very seldom. The team uses a separate war room for sketching - for dialoguing about new models or changes to a model. The sketching area often has what Peter Coad calls "model fragments" - models which map only a small piece of functionality. Several model fragments may be joined in the design model on the main control board. The model in Figure 1 is very carefully drawn to signify that this is a design artifact and not a sketch - note the careful horizontal and vertical lines, note the attention to layout which minimizes crossing lines, note the spacing of the classes and the alignment of related elements - anyone skilled in color modeling will be able to pick out the sequence of pink <<moment-interval>> classes in the middle of Figure 1 which usually indicates a business process or value chain in the domain. By taking the time to draw a clean, well thought out model, derived from the model fragments agreed in the sketching area, everyone on the team realizes intuitively that this is design and definitive and not merely a suggestion of what they are supposed to be doing.