I was asked recently about the ideal relationship between the architecture and development functions within an organisation. In some sense the ideal relationship can take many forms, because the shape of teams, and the way they interact, are heavily dependent on individuals (in small to medium sized organisations) and organisational context (always). But perhaps there are one or two principles which make the relationship work in almost all situations.

I’ve had good and bad experiences in this area. On the positive side I’ve known architects who work very closely with the development teams, sometimes actually coding with them, and who also spend time elsewhere in the organisation to ensure they have a strong sense of the bigger picture. Their architectural advice has generally been positively received by all stakeholders, including developers. On the negative side I’ve seen architects whose advice and recommendations have been rejected by the teams who have to do the delivery. Sometimes this has been a noisy and difficult disagreement; I remember once when the advice was ignored quietly, and the archicture team never realised.

If there was a common theme for success it would be a feedback loop. Architects have the big picture, but their plans and proposals have to work in practice. The teams doing the coding are the only ones who know what will and won’t work. And it’s no good architects saying the team should be able to do this; we have to be confident the team can do it, and are motivated to. So a continuous conversation, with both parties always adjusting their understanding and knowledge, is most productive. As with so many relationships.

Photo by Richard Lewis