Read Notes from a Gojko Azdic builds on the work of Nick Hines at ThoughtWorks to suggest the need for a specialized role called an Agile Architect. Yet another role - this is what we rail against being carried over from Waterfall/RUP world. Gojko defines the role of an architect to:
On the topic of evaluating software architects, the final argument was that a ‘good architect needs to spot refactoring risks and to know how much it will cost later to refactor‘. Again, this architect figure somehow appears in an agile context, now effectively possessing the power to decide whether to do the simplest thing possible or to build more structure into the solution. Answering questions from the audience about up-front design, panelists somehow came to the conclusion that the architect shouldprovide‘enough design to keep the development going smooth, identifying the risks along the way‘. To perform this continuous design, an architect should be one step ahead of the team, always providing other developers with enough insight so that they can implement the next set of stories.
I think we would all agree that there is value in sketching out the layout of the applications components in advance of writing them - assuming we allow the design to evolve as we start to understand the problem better. I differ from Gojko and Nick in thinking this isn't just a role for a single person. Every member of the team shares this responsibility. As soon as someone is named the architect several things happen:
- We stop taking responsibility for the problems we see, instead we say: "Oh that' the architect's concern"
- Now we have a team member who is first among equals. Her special status means that we're less likely to question her ideas/decisions.
Creating a new role doesn't seem justified. We're better off coaching the team to spot and discuss architectural issues on their own.
If you enjoyed this post, subscribe now to get free updates.
Update Pete Brehens has mentioned this post in the most recent Carnival of the Agilists
