The Software Craftsmanship in Israel 9th group meeting was held today at SAP offices in Raanana. The format of the meeting was a panel, discussing the merits of the software architect.
Three thought leaders participated in the panel:
The host was Uri Lavi, who skillfully led the discussion.
There was interesting debate on what is an architect, the difference between design and architecture (no one really knows… but I share my view at the end of the post), how to identify a potent software architect, feature teams, and much more. It was educational, refreshing, thought provoking.
During the discussion it hit me – the role of the software architect. To be more precise, the role of the agile software architect.
Photo by Joone Hur, source: http://www.flickr.com/photos/joone/3050331298/
The architect is the person most suitable to translate the business/product language into engineering terms, and the one most suitable to translate engineering terms between various groups.
In contrast, the traditional architect’s role that is to author the high level design, as detailed and accurate as possible. Thinking as an agilist, this more than just waste; Such approach keeps architects on their Olympus, others having to understand what the architect meant to say. Not good.
Instead, the architect should work with the product manager, defining a solid Definition of Done, in order to create the requirements with solution in mind (thank you Eshed)
The architect should work with designers, developers and testers, to talk in their native language, in relevant engineering terms, describing the business needs of the customers, so they can produce the right software.
The architect should view the software, in various stages of being produced, in order to highlight quality issues, refine requirements, adjust the architecture – in other words, respond to feedback early.
In order to achieve the above, the software architect could be the one writing the high level design, creating solution overviews and diagrams, etc. Could be, but does not have to be. The organization might gain more if the architect assists the above mentioned to product all these documents.
One option that worked very well for me is pairing. Very similar to pair-programming, the architect sits together with the product manager to author the requirements; and with the development team to author design and testing artifacts.
In order to achieve that, the good architect will be fluent in the business lingo, as well as a highly skilled engineer.
More importantly, the architect should be a people’s person; someone who is able to work in pairs and in teams; someone who can drive and navigate (a-la pairing) without prejudice.
Regarding the difference between design and architecture – here is my view. Design is an engineering skill. In design we take a requirement and turn it into a blueprint, that will be used later to create the product.
In architecture, we use engineering terms to describe the requirements, without losing the business context.
It so emerges, that in an agile framework the span of the architecture is wider than before. Since we want to keep the business context until as late as possible – and to continue using the business notion in the development team (As a <WHO> I want to <WHAT> so that <WHY> – remember?), the architect is a key for success.
Some will say that it sounds like the product owner. I think that you will be right. A good agile architect will also be a good product owner (not always vice versa).
How do you experience the architect’s role? Do you see the agile architect different to the traditional architect? In what sense?
Becoming agile 