While we must acknowledge emergence in design and system development, a little planning can avoid much waste.
—James Coplien and Gertrud Bjørnvig, “Lean Architecture: for Agile Software Development”
The Architectural Runway consists of the existing code, components and technical infrastructure necessary to support implementation of prioritized, near-term features, without excessive redesign and delay.
The Architectural Runway is one of the tools SAFe uses to implement the concepts of Agile Architecture. This runway provides the necessary technical basis for developing business initiatives and implementing new Features and/or Capabilities.
Business Epics, capabilities, features, and Stories constantly consume the runway. They use it to accomplish needed upcoming functionality. In order to support it, the enterprise must continually invest in extending the runway by implementing Enablers. Some of these fix existing problems with the Solution—for example, the need to enhance performance. Others might implement foundational capabilities that will be used by future capabilities.
Agile development avoids Big Up-Front Design (BUFD) and replaces it with a simple belief that “the best architectures, requirements, and designs emerge from self-organizing teams” (Agile Manifesto ). Out of this comes the practice of Emergent Design—the Agile Architecture evolutionary process of discovering and extending the design only as necessary to implement and validate the next increment of functionality.
This new practice works extremely well, up to a point. As Agile practices mature and are adopted by larger teams and teams of teams, there comes a point at which emergent design is an insufficient response to the complexity of large-scale system development. The following problems start to occur:
- Excessive redesign and delays; flow bottlenecks
- Different architecture constructs in support of the same capabilities, increasing maintenance costs
- Reduced collaboration and synchronization among teams
- Low velocity
- Systems that are difficult to integrate and validate
- Decline of system qualities (Nonfunctional Requirements, or NFRs)
- Low reuse of components; implementation redundancies
The net result of all of the above can be poor solution performance, bad economics, and slower time to market.
Intentional Architecture Supports the Bigger Picture
It simply isn’t possible for all teams to anticipate changes that may occur well outside of their environment, nor for individual teams to fully understand the entire system and avoid producing redundant and/or conflicting designs and implementations. Simply put, no one team in a larger Enterprise can see the whole picture, nor reasonably anticipate some of the changes that are 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 initiatives that enhance solution design, performance, and usability and provide guidance for cross-team design and implementation synchronization. The Architectural Runway enables teams to deliver business value faster and more reliably.
Together, intentional architecture and emergent design allow programs to create and maintain large-scale Solutions. Emergent design enables fast, local control so that teams react appropriately to changing requirements without excessive attempts to future-proof the system. Intentional architecture provides the guidance needed to ensure that the system as a whole has conceptual integrity and is fit for purpose. Achieving the right balance of emergent design and intentional architecture drives effective evolution of large-scale systems.
Enable Flow and Agility with Architecture
Enablers are used to build and extend the architectural runway. Enablers are often defined by architects or engineers at the various levels of SAFe, whether by Enterprise Architects at the Portfolio Level or by System and Solution Architects/Engineering at the Program and Large Solution levels, respectively. The architects who define the enablers help steer them through the various Kanban systems, providing both the guidance needed to analyze them and the information needed to estimate and implement them. This enablement 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.
However, implementation of enabler Epics and capabilities and features is complicated by the fact that the “big up-front branch-and-merge” approach no longer applies. Instead, the enterprise commits to implementing architecture incrementally. Doing so means that enabler epics must be split into enabler features and/or capabilities, which are ultimately implemented by individual Agile Release Trains (ARTs). Each enabler feature must be completed within a Program Increment (PI) such that the system always runs, at least at the PI boundaries. In some cases, this means that new architectural initiatives are implemented piecemeal and may not even be exposed to the users in the PI in which they are implemented. In this way, the architectural runway can be implemented and tested behind the scenes, allowing shipment throughout, and then exposed to users when a sufficient capability exists to support the implementation of new business epics and features.
SAFe uses the PI cadence and synchronization of both planning and asset integration as a primary tool to manage the inherent variability of R&D. In this way, ARTs have constant availability of new product for potential shipments. The enterprise is then free to decide whether or not to ship that asset, based on mostly external factors. This means that having solid, high-quality, deployable system-level solutions at (and at least at) PI boundaries is critical. In turn, that means that some amount of architectural runway must exist going into the PI Planning session. Otherwise, there is a substantial risk that architectural rework—followed by the build-out of new features that depend on that rework—adds unacceptable risk to the program.
To mitigate the risk, programs must take care to ensure that the underlying architecture for the most innovative, new features are already in the system when planning for the PI. That is accomplished by building some runway, using the runway, and extending it, as we’ll see in the following sections.
Building the Architectural Runway
In the cases where new platforms are particularly innovative, or in the case of entirely new (greenfield) development, it is common that the System or Solution Architect/Engineer plays a role in the initial definition and build-out of the runway. There, usually the new infrastructure is initially put in place with just one or two Agile Teams—sometimes with the architect/engineer serving as Product Owner—over the course of a few Iterations, as illustrated in Figure 1.
The rules for doing so are both simple and Agile:
- These teams iterate like every other Agile Team on 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 architecture.
Very quickly thereafter, the program is expanded to add some feature teams who test the new architecture with the initial, consumable features, as illustrated in Figure 2.
In the meantime, the teams build up additional architectural runway, as illustrated in Figure 3.
To support a stable velocity, the architectural runway needs to be continuously maintained and extended. Capacity allocations are used to ensure continuous investments in enablers, those activities that are intended 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 providing the enablement for near-term delivery success, the architectural runway should not over-constrain the development with long-range technical commitments. “Just the right amount” of architectural runway is required. Too much, and the architecture over-constrains the teams and is too disconnected from the current context; too little and the teams will have trouble making and meeting near-term commitments.
Consuming the Architectural Runway
All is good up to this point. A new architecture is in place and valuable features have already been deployed on it. This initial success can be temporary, however, as a number of natural forces will tend to cause the architecture to be consumed over time:
- Agile Teams are fast. They have an unparalleled focus and ability to deliver new features, thus consuming whatever runway exists.
- Product Owners and Product/Solution Management are impatient. They’ve invested some time on internal system capabilities, and they will quickly move backlog priorities to the features that users are willing to pay for.
- Architecture itself is fragile and needs to be continuously evolved. Technologies change in short time frames. Stuff obsolesces.
- Customer needs change quickly. In today’s fast paced digital economy, opportunities and threats emerge quickly and customer requirements are constantly evolving.
Unless the Agile Teams are really on their game, the result will be as depicted in Figure 4.
Extending the Architectural Runway
How can teams avoid ending up right back where they started? Simply, investing in architecture cannot be a one-time or infrequent event. This is a flow-based system, after all. Instead, teams commit to continuous elaboration, analysis, and implementation of enabler epics and capabilities and features, using the various Kanban systems. In addition, Architects/Engineers and Agile Teams will need to acquire skills for splitting enabler epics and features into small slices that can be implemented during the course of each iteration and PI, resulting in continuously value delivery to the customer. (See System and Solution Architect/Engineering and ASR , Chapters 20 and 21, for incremental implementation strategies.)
Architectural Runway Backstory
The term Architectural Runway started as an analogy with respect to observing PI-level burn-down charts. It is often the case that when there isn’t enough architecture already existing in code when teams start a PI, then any features dependent on new architecture are high risk, and programs can’t always “land those PIs” (bring the burn-down to zero at the end of the PI). In that case, they do not meet the PI objectives. There has to be some “runway” to land the thing.
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, uses that too . . . there has to be just about the right amount at any point. Extending the metaphor a bit, the bigger the aircraft (system) and the faster the flying (velocity), the more runway that’s needed to land the PI safely. Runway is explained further in Agile Architecture.
Learn More Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007, chapter 16.  Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.  Manifesto for Agile Software Development. http://www.agilemanifesto.org.
Last update: 14 June, 2017