How should architects collaborate with development teams?
There's no doubting that architects have something of an image problem. They have become associated with overly heavy governance processes and are often regarded as overpaid relics who have long since forgotten how to write code.
Some organisations have gone so far as to do away with architecture all together, regarding it as a high status, low accountability role where expensive people can lurk without making much impact.
No architects?
You can banish "architecture" teams and eliminate the "architect" job title, but development teams will still have to make architectural decisions all the time. They will debate which components to build, how they will collaborate, and where best to deploy them. They will need to consider the performance, scalability, and resilience of each component, how easy they are to change, and how they can be secured.
All these decisions need to be aligned with the wider objectives of the business, the interests of other stakeholders, and the intentions of other engineering teams. This becomes more difficult as development scales up, making the problems bigger, more complex, and more expensive to solve. Some design co-ordination is needed.
This is where architecture as a specialised discipline can add the most value. We want teams to be autonomous, responsive, and take ownership of their decisions. Architects can support this by bringing a wider perspective to bear and encouraging more strategic decision making.
The question here is how to organise architectural efforts so architects can collaborate effectively with teams.
The "benevolent dictator"
"Enterprise" architecture tends to suggest that architecture is organised as a separate discipline, dispensing wisdom wherever it goes. Consistency is enforced through a thorough governance process, often involving a "council of elders" who can dictate development decisions from a safe distance.
This is increasingly recognised as an organisational anti-pattern. Architects in this position risk making simplistic interventions based on a limited grasp of the problem domain. This "benevolent dictator" model creates an inefficient feedback loop that undermines the flow of delivery. Teams are expected to seek the counsel of an external architect who in turn must spend time getting up to speed on recent developments before they can provide any meaningful contribution.
Engineers need architectural support, but only if it can relate to them and understand the problems they are trying to solve right now. This is difficult to achieve through top-down governance or centralised decision-making. Architects need to adopt a more collaborative stance with engineers, where they can support decision making through a shared understanding of the domain.
Embedding architects
One approach for ensuring greater collaboration is to embed architects directly into engineering teams, rather than maintaining a separate team of architecture specialists.
A recent description of this embedded approach is in "Team Topologies" (Skelton and Pais, 2019), where the authors make the case for "stream-aligned" teams that are optimised to enable a steady flow of delivery. This requires that teams incorporate the full range of capabilities needed to progress work from the drawing board to production, including security, UX, infrastructure, testing, and architecture.
One problem here is that there often aren't enough specialists to go round. The relative importance of specialist concerns will also tend to vary both between individual teams and over time. For example, mobile application teams will need a lot of UX input throughout development but may only need occasional contributions from architects. A collaboration model based on embedding specialists doesn't necessarily allow for this evolving engagement.
Architects should have a different perspective to engineering delivery teams. They should seek to compliment the iterative, emergent design encouraged in development teams with more strategically driven initiatives.
This means that architects should generally consider a horizon that is at least a few months ahead of development teams. They should be collaborating with a wide range of colleagues to help ensure that technology roadmaps are aligned with the needs of the business.
Embedding may cause architects to become too close to teams, limiting their horizons so they lose sight of the strategic concerns that should be driving technology decisions. This can encourage the creation of more silos that fragment the wider architecture community and make it more difficult to establish a coherent sense of technology strategy.
Alignment as opposed to embedding
If embedding risks undermining the more strategic aspects of architecture, a more appropriate model could be to ensure that architects are aligned to a small number of teams. This allows architects to adopt a more collaborative stance, while allowing them to foster a wider, cross-team perspective.
Architectural decision making can still be embedded in teams, though this doesn't mean we need to embed the architects themselves. In an alignment-based approach, teams can remain responsive, autonomous, and able to make decisions quickly. The architect can still support the teams in making decisions without creating any long feedback loop or unhelpful governance culture.
In this approach, a relatively small team of architects can be spread across an entire development ecosystem. Each architect has an established "beat" that allows them to specialise and deepen their domain knowledge, while retaining the wider perspective they need to be effective strategic thinkers.
This can be demanding on the architect who will need to be available and approachable. They will need to be aligned with teams within a specific domain so they can remain an effective part of the decision-making fabric. This tends to limit the number of teams they can work effectively with to just a small handful.
Much depends on the personality of the architect. An architect should be a collaborator and advisor to delivery teams. Architects need to be willing to delegate ownership of architectural decisions to engineers wherever possible. They can't be there all the time, neither should they be. Their ambition should be to empower teams to be able to make architectural decisions for themselves.