There is a pervasive myth that architecture and agile are somehow in conflict. After all, rapid, iterative delivery can feel at odds with the more ponderous and centralised stance associated with "enterprise" architecture.

Team autonomy is a key aspect of this. A team should be able to design and build applications independently of any other teams. This enables a faster flow of change with quick feedback loops and minimal dependencies.

This doesn't leave much room for architects in the day-to-day business of building and delivering software. Rightfully so, as a team should have all the skills it needs to deliver features without needing to rely on any external specialists.

However, there is still a place for architecture as a specialised discipline in agile organisations, as team autonomy and agile practices on their own are no guarantee of fast flow. The role of architecture is not to guide teams or oversee solution development, but to create an environment that allows teams to be productive, by enabling a rapid rate of change through iterative development.

So how can architecture support autonomous teams and help to establish this fast delivery flow?

Modular architecture

Team autonomy does depend on the creation of a modular architecture with service boundaries that are a close fit for the problem domain. This allows you to carve up responsibilities between teams so they each control a cohesive set of data and behaviour.

A modular architecture can also help to support establishing the smaller units of work that are essential for agile delivery. Large changes that involve multiple systems tend to be more difficult to test and review. If you can split development into smaller, self-contained pieces of work then it becomes easier to enable a constant flow of change with fast feedback.

This kind of modular architecture doesn't just come into being by accident - it needs to be planned. Techniques such as Domain Driven Design can help to analyse your domain and identify these boundaries, but earthier concerns such as security and resilience needs can also play a part. These boundaries also tend to shift over time in response to changing circumstances.

A common platform

Autonomy has its limits and larger organisations need to achieve some economies of scale. You may not want every team to build their own solutions for shared concerns such as authentication and incident management. You probably don't want them building their own Kubernetes clusters. You should allow some latitude in terms of tool choice, but you may not want to support more than a handful of languages over the long term.

Most agile organisations maintain some notion of a shared platform to define and manage these concerns centrally, preferably in close collaboration with engineering teams.

The scope and nature of the shared platform can vary between organisations. For example, the Netflix "paved road" approach attempts to balance freedom and responsibility by encouraging teams to use shared tools rather than forcing compliance. The hope is that by providing a mature set of facilities it becomes a no-brainer for teams to take part.

Other organisations take a more proscriptive approach to compliance, but this does not necessarily undermine agile flow. Constraints can be strangely liberating for engineering teams as they limit the decision boundary, focus attention, and reduce the overall cognitive load. You're not wasting time figuring out how to authenticate a user or expose your monitoring data – there are solutions in place that you can lean on.

It can be difficult to get the balance right here. It's easy for a platform-based approach to tip over into platform-based tyranny where you are forced to use solutions that are a bad fit for your use cases. This can make shared platforms a burden on teams rather than a means of fostering agility.

Ideally, a shared platform should be treated like a product where the main customers are the engineering teams. It needs clear ownership and should evolve over time in response to the shifting needs of these customers.

Rules of the road

Any collaboration between services needs some common understanding of the protocols, formats, and technologies you use to exchange information. This is related to the notion of a common platform, but it's important to call out separately as no team is an island.

For example, if you want to enable event-driven collaboration between services, then you'll need a shared solution to serve as a common publishing medium. You'll also need some agreement around how to format event messages so a consumer has some chance of being able to understand them.

If teams publish APIs you may want some predictability and consistency around how they are presented.  Endpoint design may remain a team concern, but clear expectations around documentation, sandboxes, support, versioning, and connectivity should help to make collaboration easier.

These "rules of the road" should apply to teams when they expose data and behaviour outside of their domain. This defines a contract between teams that reduces cognitive overhead enables more efficient collaboration.

The direction of travel

If teams are to maintain any degree of agility over the long term, they need to design solutions that can evolve in response to changing requirements. Early prototypes may be built to demonstrate viability, but they eventually grow into fully scaled systems with much greater depth of functionality. In most environments, you don't have the option to start again from scratch just because the world has changed around you.

There is a similar need to support evolution for the wider architecture. The needs of the business will evolve and priorities will change. The architectures that supported early growth may not scale to meet current demand.

Many engineering organisations have evolved over time, often from monolithic web applications to more fluid distributed architectures. This kind of evolution does not happen without guidance and encouragement. You need to set a direction of travel for engineering teams so they can gradually evolve towards a clearly defined future state.

Where do architecture specialists fit in?

In theory, you can leave these concerns to engineering teams. You can attempt to leverage a "inverse Conway maneuver" and create platform teams tasked with building shared infrastructure. You can establish communities of practice to collectively figure out the rules of the road. You might even get these communities to eventually agree on a direction of travel or division of domain responsibilities.

However, engineers tend to have a siloed and technology-focused view of the world that focuses on their immediate domain rather than more strategic concerns. Architecture specialists can develop a wider perspective that spans the entire domain and encompasses both technical and business concerns. This leaves them in a better position to define a boundary within which engineering teams can operate autonomously.

Filed under Agile, Development process and Strategy.