The Scaled Agile Framework talks about an "architectural runway" as the main deliverable for agile architecture, yet it tends to be vague on the details of what this includes.

This is a metaphor as much as anything else, suggesting that you should aim to provide a “safe landing” for development. It implies that you have a flexible and scalable framework in place that can accommodate any immediate changes. This is about providing “just enough” architecture to allow teams to deliver.

But what are the specific deliverables that you would expect to see as part of this runway?

Emergent vs intentional design

Scaled Agile identifies two main strands of systems design. The first is the notion of emergent design where teams take an evolutionary and incremental approach to system design. This is largely derived from the agile manifesto's statement that “the best architectures, requirements, and designs emerge from self-organizing teams”.

This lean approach to design makes it easier for teams to respond to changing user needs. It is more efficient than the dreaded “big design up front” approach as it allows teams to evolve the system design in response to their growing understanding of the requirements.

The problem is that emergent design cannot address every design challenge on its own. It's not possible for a development team to anticipate how every external influence will affect them. Some problems are just too big for a single team to solve or need some specialised knowledge and experience. Most solutions require on-going collaboration between teams that needs to be facilitated somehow.

SAFe recognises this and allows for intentional design in terms of planned architectural initiatives that enhance solutions and facilitate cross-team development. The onus here is on building the simplest architecture that can work rather than building out complexity. It's also important to point out that the team are still responsible for building and testing solutions – the intentional design enables those areas that they cannot solve themselves.

It's this combination of emergent and intentional design that gives rise to the architectural runway.

So what's on the runway then?

This isn't like a TOGAF-style repository of documents governed by an architecture board. The architecture runway can be best thought of in terms of a framework of conventions, technologies and strategies that define the boundaries within which teams can innovate and evolve their solutions.

In more practical terms, I would typically expect an architectural runway to address the following concerns

• Establishing the “rules of the road” for collaborating services in terms of the protocols and conventions that they will follow
• Putting in place large scale shared infrastructure such as API gateways, message brokers or shared database platforms
• Identifying shared solutions and services to avoid re-inventing the wheel
• Providing guidance in terms of widely accepted best practice, normally stopping short of any centrally-enforced set of standards.

Beyond these practical deliverables there should also be a sense of an over-arching vision for how the emerging architecture will address the longer-term business strategy. This is the conceptual glue that binds development together by identifying the broad target architecture that an organisation is aiming for.

What role do architects have in defining the runway?

Architects should take a lead role in both the evolutionary and intentional aspects of the architectural runway, but as somebody who enables design rather than governs.

Emergent design doesn't just happen. It requires some advanced planning and deep experience in building long-lived systems and knowing how different design approaches can accommodate change. This kind of expertise and experience is not always available to development teams.

For example, you need to recognise how different types of system coupling can inhibit change, appreciate the importance of continuous delivery pipelines and understand how to design flexible data structures. Numerous techniques associated with evolutionary architecture can come into play such as anti-corruption layers and architectural fitness functions.

Architects can also help to bring a wider perspective to bear rather than being focused on the tactical demands of each sprint. This makes them well-placed to spot dependencies that need to be managed or common solutions that can accelerate development.

The important thing here is to stress the need for collaboration. Architects don't dictate anything, neither are they directly responsible for delivering solutions. Teams are still responsible for writing and testing any code generated as part of the runway. Any architecturally-driven work needs to be defined as epics and broken down into stories by teams in much the same way as business requirements.

This means that the architecture runway is a collectively owned asset that is principally delivered by teams. The architect's role is to support the teams in designing and building better solutions that leverage the components, infrastructure and conventions that make up the architecture runway.

Filed under Agile, Architecture, Development process and Governance.