Grab a ladder and help your Architects down from the Ivory Tower
In our quest of *building the best software team* it’s important to reconsider the relationship between architects, developers and the flow of work into your teams. In the past an Enterprise Architect could at times seem decoupled from the reality of the software teams and their challenges. Perhaps they were hidden away in an office with the door shut, making UML diagrams, rarely talking to developers, and who would if they didn’t have to? We’ve all worked with the kind of software architect that makes all the decisions, puts their drawings somewhere in Share Point, somewhere you have no hope of finding it, and maybe, just maybe a development team might get an in-person overview of the final vision. This is no way to collaborate, no way to build teamwork and definitely no way to arrive at an optimal software solution.
Developer/Architect
Today, all developers share some architectural responsibilities. Especially, Sr. developers are expected to make sound architecture decisions when faced with choices. A dev/arch is an architect who is also an individual contributor pulling stories out of the backlog just like everyone else.
A dev/arch can be found having in-depth discussions in an effort to better understand the actual problems a developer may be faced with, perhaps even building a proof of concept ( POC ) project of their own in order to flush out as many concerns as possible before putting pen to paper. This same dev/arch may be seen having impromptu meetings with the lines of business that are asking for new features or changes to an old feature.
Product Owner/Architect
An exciting new-to-me role is when an Architect also occupies a Product Owner (PO) position. Like the dev/arch position this is an emerging pattern that helps keep the software architecture aligned with business needs and development teams ultra aligned with architectural vision. Having your architect take on PO responsibilities also provides opportunities for deeper discussions with developers and allows the story priorities to be controlled by the person that best understands future direction, the architect. My current services team is using this PO/Arch role and it has just been killer. Another benefit to this role is the exposure more jr. developers get to making architectural decisions.
The old school ivory tower paradigm for software architect leaves a lot of untapped opportunity and communication on the table. Whereas the blended models of Dev/Arch and PO/Arch helps to exploit opportunities for communication and shared vision of the systems. Today’s software architects are much more in touch with what is actually going on and knows the difference between solutions that are needed and which are just academic exercises. So, go grab a ladder and help those poor folks down so that they can get to work building a great software team.