What should a Scaled Agile “architectural runway” actually look like?

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 practise, 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.

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.

About me

I am a London-based technical architect who has spent more than twenty years leading development across start-ups, digital agencies, software houses and corporates.
Over the years I have built a lot of stuff including web sites and services, multi-screen applications, systems integrations and middleware.

My current focus is on enabling scalable SaaS delivery and providing architectural leadership in agile environments.
I currently work as Chief Architect for Wolters Kluwer UK leading them to cloud heaven, one service at a time. Opinions are my own and not the views of my employer, etc.

Recent

There does seem to be growing confusion over what Service Fabric is really for. Is it an orchestrator for microservices? A means of lifting and shifting legacy applications into the cloud? An application development framework?

Azure Functions only provides direct support for a narrow range of authentication providers. If you want to use an external token provider or custom solution, you’ll have to create the plumbing yourself.

ArchUnit is a java library that provides a fluent API for creating self-testing architectures via unit tests. A similar library can be written for .Net Standard that acts on compiled assemblies rather than raw code.

There is a growing sense of unease around how larger organisations have implemented agile. In particular, there is a tendency towards centralised control that can be at odds with the agile preference for individuals over process.