Architecture is basically a container of something. I hope they will enjoy not so much the teacup, but the tea.
Architectural Runway Abstract
Architectural runway exists when the enterprise’s platforms have sufficient, existing technological infrastructure (code) to support the implementation of the highest priority features in a near-term Program Increment without excessive, delay-inducing, redesign. In order to achieve some degree of runway, the enterprise must continually invest in refactoring and extending existing platforms.
Implementation of architectural epics and features is complicated by the fact that the “big-bang-up-front branch-and-merge” waterfall approach is abandoned. Instead, the enterprise commits to implementing architecture incrementally in the main code base. Doing so means that architectural epics must be split into architectural features, which are implemented by individual release trains. Each architectural feature must be completed within a 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, 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 instantiate them.
SAFe uses Program Increment cadence and synchronization of both planning and software asset integration as a primary tool to manage the inherent variability of R&D. In this way, Agile Release Trains 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 (least at) PI boundaries is sacrosanct. 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 assure that the necessary architectural underpinnings (code!) 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
The concept of architectural runway in agile was introduced in Scaling Software Agility (SSA, ref  chap. 16) and has been extended in Agile Software Requirements (ASR, ref. ). In the cases where new platforms are particularly innovative, or in the case of entirely new (greenfield) development, it is common that System Architects play a role in the initial definition and build out of the runway. There, it is common that new infrastructure is initially put in place with just one or two Agile Teams—sometimes with the architect serving as Product Owner—over the course of a few Iterations, as illustrated in Figure 1.
The rules for doing so are simple, and Agile:
- These teams iterate like every other Agile team on the program
- Credit goes to working code, not models and designs
- Time is of the essence. It should take no more than a few iterations to 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 is illustrated in Figure 2.
In this way, the teams quickly build up some architectural runway, as illustrated in Figure 3.
Using It: The Fragile and Temporal Nature of System Architecture
All is good up to this point. A new architecture is in place and value features have already been deployed on it. This initial success can be temporary, however, as a number 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 Managers are impatient. They’ve invested some time on internal system capabilities, they will quickly move backlog priorities to the features the users are willing to pay for
- Architecture itself is fragile. Technologies change in short timeframes
- Customers needs change fast, 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 even spasmodic event. Instead, teams commit to continuous elaboration, analysis and implementation of architectural epics and features, using the Architectural Epic Kanban system. In addition, as described in the Framework, system architects and Agile teams have newfound skills that provide for splitting architectural 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 Architect Page and ASR ,. Chapters 20 and 21, for incremental implementation strategies.)
An Historical Note: Source of The Metaphor
The term “Architectural Runway” started as an analogy with respect to observing PI level burndown. We often observed that when there isn’t enough architecture already extant in code when you start a PI, then any features dependent on new architecture are high risk, and programs can’t always “land those PIs” (bring the burndown to 0 at the end of the PI) and thereby fail to meet the PI objectives). You need some “runway” to land the thing. In SAFe, it’s drawn the way it is, going up and down over time, because you build some, then use, build some more, use that too…..you have to have just about the right amount at any point. Plus, to extend the metaphor a bit, the bigger the aircraft (system) and the faster you were flying (velocity), the more runway you will need to land safely. You can learn more about runway in Principles of Agile Architecture.
 Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007, chap.16.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 22 July, 2014
Leffingwell et al. © 2011-2014 Scaled Agile, Inc.
Information on this page 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. For permissions, visit the Permissions FAQ and Form.