While we must acknowledge emergence in design and system development, a little planning can avoid much waste.
—James Coplien, Lean Architecture
The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features with minimal redesign and delay.
Architectural Runway enables a continuous flow of value through the Continuous Delivery Pipeline, providing the technology required to quickly define, build, validate, and release Features and Capabilities. It also supports the practice of Agile Architecture by allowing an organization’s technology landscape to evolve in response to changing business needs.
Agile development avoids big design up-front (BDUF) with a simple belief that “the best architectures, requirements, and designs emerge from self-organizing teams .” This yields the practice of emergent design—defining and extending the architecture only as necessary to deliver the next increment of functionality.
However, emergent design alone cannot handle the complexity of large-scale Solution development. At scale, relying solely on emergent design leads to the following problems:
- Lack of standards increases delivery costs and delays
- One-off solutions become difficult to change and maintain
- Systems become vulnerable to security and stability issues
- Quality becomes dependent on tribal knowledge
- Solution components have poor interoperability and reusability
These problems can result in poor solution performance, unfavorable economic outcomes, and delayed time-to-market. Organizations overcome these problems by balancing emergent design with intentional architecture, which requires some centralized planning and cross-team coordination. Both are implemented with Enablers and, together, ‘pave’ the architectural runway (Figure 1).
Intentional Architecture Supports System Evolution
Agile Teams apply emergent design through the development of enabler Stories that incrementally evolve their parts of the solution. However, they typically lack the breadth of knowledge of the end-to-end solution that would allow them to design components and infrastructure across all domains effectively. Many of these design factors are simply beyond their scope of responsibility.
Intentional architecture accounts for these systemic design considerations and provides purposeful, planned architectural guidelines that enable the independent work of Agile teams to be integrated into a cohesive, sustainable solution. These cross-cutting guidelines are typically defined by Enterprise Architects, Solution Architects, and System Architects in close collaboration with Product Management and Solution Management. These roles are well suited to the task because of their broad knowledge of the technology landscape and deep knowledge of the Solution Context.
Intentional architecture is codified as enabler epics, capabilities, and features in the Portfolio Backlog, Solution Backlog, and ART Backlog. Architects then help steer the enablers through the appropriate Kanban systems, ensuring they produce the intended architectural runway.
Building the Architectural Runway
Several roles may be involved in defining architectural runway, but its implementation is the responsibility of Agile teams. These teams are often responsible for delivering end-user-focused products or services. Therefore, building the architectural runway should not overly constrain them.
Just the right amount of architectural runway is required at any given time. Too much, and the architecture bottlenecks the teams and over-engineers the current solution increment. Too little, and the organization will not have the runway it needs to meet near-term business commitments. Capacity allocation is applied to the Team Backlog to help ensure that the ratio of enabler work to customer-facing work is always in balance.
A dedicated Agile team often oversees the initial implementation when significant investment in architectural runway is called for—such as to enable a new product launch, Horizon 3 portfolio initiative, or legacy environment. (Figure 2).
In this scenario, an architect often assumes the role of Product Owner, acting as the voice of the customer and content authority over a backlog composed primarily of enablers. A specialized group of team members handles development, and a Scrum Master/Team Coach guides execution.
This team continues until the volume of runway work required by the ART is no longer sufficient to warrant a dedicated team. At this point, the responsibility for implementing additional architectural runway as needed becomes shared among the ART’s persistent Agile teams, as illustrated in Figure 3.
Regardless of who performs the work, the rules for building the runway are both simple and Agile:
- Teams that build the runway iterate like every other Agile team on the ART
- The value is in working systems, not models or specifications
- Enabler features and stories should take no more than a PI or iteration, respectively, to deliver
- Agile teams are stakeholders of the architectural runway, leveraging it to deliver on customer commitments and providing feedback on its effectiveness
Continually Invest in the Architectural Runway
Architectural runway is dynamic. It is ‘consumed’ by delivering near-term features and must be extended to support future features. The following are examples of forces that consume architectural runway:
- Fast-moving Agile teams – They quickly use the newest runway to deliver near-term features
- Customer preferences – After investing in architectural runway, stakeholders often shift backlog priorities to the features that directly benefit customers
- Technology innovation – Technology changes rapidly, rendering existing runway obsolete
- Changing business needs – The needs of the enterprise shift in response to emerging opportunities and threats
Architectural runway is consumed to deliver planned features. As business needs change and new features are requested, additional runway is required (Figure 4).
Because the development of new features and capabilities consumes the architectural runway, a continual investment must be made to extend it. Teams commit to extending the runway as needed in each iteration to support quick, sustainable delivery velocity. This could include adding automation to the CDP, enhancing DevOps practices, increasing server capacity, or any other activity that accelerates delivery velocity.
The Architectural Runway in Large Solutions
When building really big systems, the architectural runway takes on an even more critical role as multiple ARTs contribute to the same Solution as part of a Solution Train. The Enterprise Solution Delivery article describes ten Lean-Agile practices that guide large solution delivery, several of which relate directly to architectural runway:
- Specify the solution incrementally – The Solution Intent defines many constraints as Non-Functional Requirements (NFRs). Many NFRs are cross-cutting concerns that can be addressed and simplified by building architectural runway that supports integration and testing. Architectural runway also allows elements of the solution intent to smoothly and incrementally evolve from variable to fixed.
- Apply multiple planning horizons – Large solutions generally require a longer architectural runway, implemented with enabler epics over several PIs or even years. Efficient delivery of these long stretches of runway is orchestrated through connected iteration plans, PI roadmaps, and solution roadmaps.
- Design for change – Achieving these goals in large solutions requires intentional architecture to implement an effective Continuous Delivery Pipeline and ensures simplified operations with strong feedback via application telemetry.
- Continually address compliance concerns – A Lean approach to Compliance automates the collection and testing of compliance data to provide more effective and predictable outcomes. This goal requires early engagement with auditors and stakeholders to agree on an acceptable approach. Creating capabilities through the architectural runway ensures consistency and removes significant compliance risks.
- Evolve deployed systems – A fast, economical Continuous Delivery Pipeline means solutions—and changes to those solutions—can be released on demand. Architectural runway delivers a CDP whereby deployed solutions can evolve incrementally with minimal customer disruption.
It is critical to implement long runway incrementally. Enabler epics are split into enabler features and/or capabilities, then implemented by ARTs. Each enabler feature must be completed within a PI, and enabler stories within an iteration. This allows significant investments in architectural runway to evolve with the right balance of intentional architecture and emergent design.
The Backstory of the Architectural Runway
The term ‘architectural runway’ started as an analogy while observing PI-level burn-down charts. Often, when there isn’t enough architectural runway when teams start a PI, any features dependent on the new architecture are high risk.
ARTs can’t always ‘land those PIs’ (bring the burn-down to zero at the end of the PI). In that case, they don’t meet the PI objectives. A PI, like an airplane, needs enough runway to land safely.
In SAFe, the architectural runway line goes up and down over time because it is built up, then used, then built up some more, then used, and so on. There has to be just the right amount at any point to support near-term business objectives.
To extend the runway metaphor, the bigger the aircraft (system) and the faster the flying speed (velocity), the more runway is needed to land the PI safely.
 Manifesto for Agile Software Development. http://www.agilemanifesto.org
Last update: 9 January 2023