While we must acknowledge emergence in design and system development, a little planning can avoid much waste.

—James Coplien, Lean Architecture

Architectural Runway

The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.

Architectural Runway supports the continuous flow of value through the Continuous Delivery Pipeline, providing the necessary technical foundation for developing business initiatives and implementing new Features and/or Capabilities. The architectural runway is one of the primary tools used to implement the Framework’s Agile Architecture strategy.

Since the development of new features and capabilities consumes the architectural runway, a continual investment must be made to extend it by implementing Enablers. Some enablers address shortcomings with the current Solution, such as improving its performance or User Experience. Others provide foundational capabilities that will be used to support future functionality.

Details

Agile development avoids Big Design Up-front (BDUF) and replaces it with a simple belief that “the best architectures, requirements, and designs emerge from self-organizing teams [3].” This yields the practice of emergent design—the process of discovering and extending the architecture only as necessary to implement and validate the next increment of functionality.

However, organizations must respond simultaneously to new business challenges with larger-scale architectural initiatives that require some intentionality and planning. As a result, emergent design alone cannot handle the complexity of large-scale system development, and the following problems start to occur:

  • Excessive redesign and delays reduce velocity
  • Systems become difficult to integrate, validate, and maintain
  • Decline of system qualities, known as Nonfunctional Requirements (NFRs)
  • Reduced collaboration and synchronization among teams
  • Low reuse of common components and redundancy of solution elements

All of these problems can result in poor solution performance, bad economics, and slower time-to-market.

Intentional Architecture Supports the Bigger Picture

Emergent design is not sufficient at scale. No one team in a larger Enterprise or working on a Large Solution can see the whole picture or reasonably anticipate all the changes headed their way—many of which arise outside their local control. For this reason, teams need some intentional architecture—a set of purposeful, planned architectural guidelines that enhance solution design, performance, and usability—and direction for cross-team design while syncing implementation.

Applied together, intentional architecture and emergent design allow Agile Release Trains (ARTs) to create and maintain large-scale solutions. Emergent design enables fast, local control so that teams can react appropriately to changing requirements without excessive attempts to future-proof the system. Intentional architecture provides the guidance needed to ensure that the whole system has conceptual integrity and is fit for its purpose. Achieving the right balance of emergent design and intentional architecture is the key to developing large-scale systems effectively.

Enable Continuous Delivery and Release on Demand with Architecture

Architects play a critical role in designing systems that can provide a continuous flow of value to the user. Enterprise Architects define enablers for the portfolio, while System and  Solution Architects/Engineering typically define them for ARTs and Solution Trains. The architects who define the enablers help steer them through the Kanban systems, providing the guidance needed to analyze, estimate, and implement them. This support ensures that the affected elements—subsystems, components, functions, protocols, internal system functions—have the architecture necessary to support the near-term Features and Capabilities on the Roadmap.

To avoid the BDUF approach, the enterprise commits to implementing architecture incrementally. This means that Enabler Epics must be split into enabler features and/or capabilities, which are ultimately implemented by individual ARTs. Each enabler feature must be completed within a Program Increment (PI), ensuring that the system always runs—meaning it’s potentially deployable, even during its development.

Architecture is a key enabler of the Continuous Delivery Pipeline (CDP) and the architecture runway is concerned with building the CDP. An effective CDP provides teams immediate quality feedback offered through Continuous Integration and Continuous Deployment. It also feeds Continuous Exploration and Release on Demand with direct user feedback and validated learning (see Lean UX). The result is a higher-quality product that is adaptable and fit for purpose.

Building the Architectural Runway

In some cases, a new innovation may begin with a significant, architecturally-intensive initiative or create an entirely new product (e.g., a Horizon 3 investment initiative). For these situations, the System or Solution Architect/Engineer plays a key role in defining and building out the runway. The exploration and new infrastructure are initially put in place with a few Agile Teams—sometimes with the Architect/Engineer serving as Product Owner during the first few Iterations, as illustrated in Figure 1.

Figure 1. Initiating the Architectural Runway

 

The rules for building the runway are both simple and Agile:

  • Teams that build the runway iterate like every other Agile team in the program.
  • Credit goes to working solutions, not models and designs.
  • Time is of the essence. It should take no more than a few iterations to implement and prove the new technology.
  • Feature teams validate the new architecture. They provide feedback by building, deploying, and releasing features on top of the new technology as illustrated in Figure 2.
Figure 2. Implementing some new Features on the new runway

To support a stable velocity, the architectural runway needs to be continuously maintained and extended. Capacity allocations (see Program and Solution Backlogs) helps ensure continuous investments in enablers—the activities required to extend the runway.

Product/Solution Management and Architects/Engineers, in collaboration with the affected teams, define many of these enablers. But implementation is the responsibility of the ARTs. While supporting successful near-term delivery, the architectural runway should not overly constrain development with long-range technical commitments. Just the right amount of architectural runway is required:

  • Too much, and the architecture limits the teams and is too disconnected from the current context
  • Too little, and the teams will have trouble making and meeting their near-term commitments

Continually invest in the Architectural Runway

Forces consume the architecture over time:

  • Agile teams are fast – They quickly deliver new features, thus consuming the existing runway
  • Product Owners and Product/Solution Management are impatient – They’ve invested some time in internal system capabilities, and they will quickly move backlog priorities to the features that users are willing to pay for
  • Architecture requires innovation and should continuously evolve – Technologies change rapidly and become outdated
  • Needs change – The business must be able to quickly respond to opportunities, threats, and new customer requirements

These forces consume architecture investment as shown in Figure 3.

Figure 3. Using up the Architectural Runway

Consequently, the architectural runway requires continuous investment and is not a one-time or infrequent event. Each iteration, teams commit to the elaboration, analysis, and implementation of enablers. Architects/Engineers and Agile teams will need to acquire skills for splitting enablers into small slices that can be implemented during the course of each iteration and PI, resulting in continuously delivering value to the customer (see Agile Software Requirements, chapters 20 and 21 [2], for incremental implementation strategies).

The Architectural Runway in Large Solutions

When building really big systems, the architectural runway takes on an even more critical role as multiple ARTs are contributing to the same Solution as part of a Solution Train. The Enterprise Solution Delivery article describes nine practices for building large solutions, of which several interact heavily with the architectural runway:

  • Continually refine the fixed/variable solution intent – The Solution Intent defines many constraints in the form of Non-Functional Requirements (NFRs). Many NFRs are cross-cutting concerns that can be addressed and simplified by intentionally building architectural support for their implementation and testing. Changes in the Solution Intent may create additional work to build more architectural runway or invalidate the existing runway.
  • Apply multiple planning horizons – In large solutions, foundational capabilities may take an extended period of time to implement. These systems require a longer architectural runway often implemented with Enabler Epics in the Program and/or Solution Kanban systems.
  • Architect for scale, modularity, releaseability, and serviceability – 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 testing and generation of compliance data to provide more effective and predictable outcomes. This goal typically requires early engagement with compliance auditors and authorities to agree on an acceptable approach and then creating capabilities through the architectural runway ensures consistency and removes significant compliance risk.
  • Evolve deployed systems – A fast, economical Continuous Delivery Pipeline means systems can be released early and evolve. Therefore, systems must be architected to support continuous deployment and release on demand.

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 a 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 safely land.

In the SAFe Big Picture, the architectural runway line is drawn going up and down over time, because the team builds up some runway, then uses some, builds some more, and then uses that, too. In short, there has to be just about the right amount at any point.

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. Architectural Runway is explained further in Agile Architecture.

Learn More

[1] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[3] Manifesto for Agile Software Development. http://www.AgileManifesto.org

 

Last update: 12 February 2021

 

The information on this page is © 2010-2024 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions.