In the following table we list the advantages, disadvantages, and considerations (when does the strategy makes sense) to compare whether a software architect should write code or not. You may recognize this approach from our book Disciplined Agile Delivery.
In the Disciplined Agile (DA) toolkit we’ve made it very clear that we expect Architecture Owners to be actively involved with the development of the solution. On Disciplined Agile teams the Architecture Owner is effectively a team member with additional responsibilities around leading the team through architecture decisions, in coaching them on architecture skills, and in working closely with your Enterprise Architecture team (if any) to ensure their development team understands and is working towards your organization’s technical roadmap.
We’re often told that it isn’t realistic to expect architects to write code. Invariably this is coming from people who are currently working in traditional IT organizations that have very well-defined roles, IT organizations that more often than not are struggling to be effective. Our response is always the same – Really? Are development teams following your architectural strategy? Are they eager to work with you, or are they forced to work with you? This generally leads to a discussion that reveals that things aren’t going so well for these architects in practice, and sometimes leads to a positive discussion as to how we can move towards a more effective approach for them. They kind of approach described in the Disciplined Agile (DA) toolkit.
The Disciplined Agile (DA) toolkit suggests a robust set of roles for agile solution delivery. These roles are overviewed in the following figure:
For a detailed description of these roles, please visit the page Roles on DAD Teams.