The best architectures, requirements, and designs emerge from self-organizing teams.
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
Architectural Runway Abstract
The Architectural Runway provides one of the means by which SAFe implements the concepts of Agile Architecture. An architectural runway exists when the Enterprise’s platforms have sufficient existing technological infrastructure to support the implementation of the highest-priority features in a near-term Program Increment without excessive, delay-inducing redesign. This runway provides the necessary technical basis for developing business initiatives and implementing new Features and/or Capabilities.
The runway is constantly consumed by Business Epics, capabilities, features, and Stories. They use the runway to accomplish their needed functionality. In order to support upcoming functionality, the enterprise must continually invest in extending the runway by implementing Enablers. Some of these enablers fix existing problems with the Solution—for example, the need to enhance performance—while others might implement foundational capabilities that will be used by future capabilities.
Agile development eschews waterfall thinking and Big Upfront 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
- Deterioration of system qualities (Nonfunctional Requirements, or NFRs)
- Low reuse of components; implementation redundancies
The net result of all 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 thereby avoid producing redundant and/or conflicting designs and implementations. Simply put, no one team in a larger Enterprise can see the bigger 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. These Enablers create the Architectural Runway needed to allow teams to deliver business value faster and more reliably.
Together, intentional architecture and emergent design enable 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 assure that the system as a whole has conceptual integrity and efficacy. 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 extend the architectural runway. Enablers are often defined by architects or by systems engineering at the various levels, whether by Enterprise Architects at the Portfolio Level or by System and Solution Architects/Engineering at the Value Stream and Program Levels. The architects who define the enablers help steer through the various Kanban systems, providing both the guidance needed to analyze them and the information needed to estimate and implement. This enablement ensures that the affected elements—subsystems, components, functions, protocols, internal system functions, etc.—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 upfront branch-and-merge” waterfall 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 the program-level features that instantiated them.
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 necessary architectural underpinnings 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 architectural initiatives, but implementation is the responsibility of the Agile Release Trains. 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 reliably making and meeting near-term commitments.
Using It: The Fragile and Temporal Nature of System Architecture
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, too.
Unless the Agile Teams are really on their game, the result will be as depicted in Figure 4.
How can teams avoid ending up right back where they are started? Simply, investing in architecture cannot be a one-time or sporadic 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 have newfound skills that provide for splitting enabler epics and features into small slices that can be implemented during the course of each iteration and PI, thereby continuously delivering value to the Customer. (See System and Solution Architect/Engineering and ASR , Chapters 20 and 21, for incremental implementation strategies.)
Note: The Source of the Metaphor
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 extant 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 0 at the end of the PI). In that case, they fail to meet the PI objectives. There has to be some “runway” to land the thing.
In SAFe, the red architectural runway line is drawn the way it is, going up and down over time, because the team builds some, then uses some, builds some more, uses that too . . . there has to be just about the right amount at any point. Plus, to extend 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.
 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: 18 September 2015