A practical architecture runway

Photo by Daniel Eledut on Unsplash

So I’m a software architect starting on an agile project and wondering how do I integrate seamlessly and add more value than “just another developer.” Or maybe I have hired one who has been a trusted advisor but I want to know what else should I expect from this role, especially as we are trying to move fast.

Many sources that talk about evolutionary architecture in the abstract for projects that are at a scale where design is needed, but not a lot of practical advice on how to foster these handoffs between architects and developers. This lack of definition may stem from a view by agilists that architects used to be a controlling part and choke-point in the waterfall method they were seeking to change around 2000. The rise of product managers and devops roles have blurred a lot of roles around development, so it’s a reasonable perception now to ask “what does architecture do on a software project? And how can it be a valuable contribution that I see in some projects outside my organization?”

The first function of architecture is to serve as a bridge — between the business trends, requirements, and competitive space and the realization of success of a project. Software architects specifically tend to be very close to the lead or senior developer role because this flavor of technology architecture is probably the nearest example of a combination of art form and disciplined design. Like a (construction) architect, the software architect works in the terminology of the client, taking concepts from initial visualization to design to realization. We call this the architecture runway.

Within agile sprints, we’re familiar with breaking our overall backlog into sprints, epics (topic areas), and program increments to timebox development. This works fine when the tasks are easily described as functions — where the developer does not need much guidance in interpreting concise and fully-formed requirements. What do we do when this is a major new service or something like overall performance across a number of modules or a security strategy? The architecture runway represents the work that precedes these development tasks and uses some techniques we’ll describe below to iterate and refine the requirements. We call them architectural enablers in the sense that — for certain epics — the requirements may be vague or the implementation has some cross-cutting concerns which require coordinated design and implementation that the architect needs to do some translation to make the development stories “shovel-ready.”

Types of tasks for arch runway

So what types of tasks can the software architect perform in the architecture runway? In previous architecture methodologies and approaches, these were often heavy artefacts like high level solution design documents. In agile architecture, we need to do smaller, more scoped deliverables in the right channel to reach our developer audience. Ever seen a multi-page UML system model and thought TL;DR? Here’s my list of enabler types:

1. A “short” white paper or guidance note — maybe more like a few paragraphs of description to clarify a use case, terminology (c.f., DDD bounded context) in PowerPoint or email
2. A model description in single ERD or UML diagram, or a view
3. A mockup of an interface (preferably in an HTML tool or something that translates to the UX team seamlessly without rewrites)
4. An OpenAPI description
5. A prototype set of code (yes, the architect should understand how the system will be built in the compiler, just realize that prototypes take more time)
6. A meeting with clear agenda, decision record, and design minutes (try not to just take a picture of a whiteboard!)

Since the artefacts are smaller, these can be delivered in typical developer tools like pages on Confluence, inside a story in Jira, in a Slack channel. Many of the newer online tools like miro.com and Lucidchart make technical diagrams more easily distributable over prior tools which were architect-specific (more on this in another post).

Understanding the epics in the architecture runway

The question we’ll answer next is how to organize the runway. We are doing intentional design in specific functional areas, and also planning for cross-cutting concerns so the runway should be broken down into epics that make sense in our project. These are, by definition, architecturally significant requirements (ASR) areas and often are a combination of epics aligned functionally, technical goals and quality attributes with titles like:

1. Microservices (possibly in a conversion from a monolith, to understand general design principles)
2. Client or partner integration (I often do an epic per client interface, so one epic for client A and a separate epic for client B)
3. Security (a broad quality attribute)
4. Availability or performance
5. Feature set (I ran into a new functional area to do credential rotation within the security service)
6. Definition of done
7. DevOps
8. Refactoring (single epic to prioritize all the refactor tasks which are internal only)

Planning the architecture runway

Let’s bring it all together! We can identify stories inside these epics — which enabler task to which audience (some work may be done for project sponsors or operators or security team who’s not on agile or folks other than the development team) — and put them on the Kanban board alongside the other sprint tasks.

Architecture enablers on the same board as the rest of the team

After defining the epics, we do need to align timing before we finalize the runway. This means understanding the dependencies leading up to the enabler and the timing for when development starts after the enabler is ready. We want a manageable list of enablers that leverages the architecture experience in only the most high-value areas, and leads the development effort by at least a sprint so that resourcing can be planned by the PM.

Specific enabler deliverables mapped to sprints ahead of the development effort (red top arrows)

A couple of things to watch out for — don’t overload the architect! It’s easy to look at the smaller tasks and assume a much higher quantity can be taken on. Also, make sure the handoff to development is consistent — if the architect gets different developers each time on the same epic, or if the developer does not have regular communication with the architect, this can sever the accountability for the design of the quality attribute and the implementation. Is 80% of the performance goal enough? Finally, if no developer is assigned (and the architect has full responsibility for an enabler’s implementation), we run into Conway’s Law where the scalability of the system only represents one team member’s view and the architect is taken away from the other concerns of the system.

The architecture runway is a valuable way to show the value of architecture in the agile sprint cycle. This article shows a practical way to identify, prioritize, and include the architecture runway in a typical software development. Thanks for reading through this — it’s been something I’ve planned on writing up for a while now. Let me know what you think, I’m at brian@princetondigitaladvisors.com