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 needed to implement near-term features without excessive redesign, and delay.
It provides 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 development of new features and capabilities consume the architectural runway, continual investment must be made to extend it, by implementing Enablers. Some enablers fix existing problems with the Solution, such as improving performance or user experience. Others might provide foundational capabilities that will be used to support future functionality.
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” (Agile Manifesto ). 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. Therefore, there comes a point at which emergent design is an insufficient response to 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
In turn, this can result in 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 their environment. Nor can individual teams 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, 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 Flow and Agility with Architecture
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, and—very at least—at the PI boundaries. In some cases, this means that new architectural initiatives are implemented piecemeal. (They 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, yet allowing shipment throughout. It then can be exposed to users when a sufficient capability exists to support implementing new business epics and features.
PI cadence and synchronization helps manage the inherent variability of R&D. This way, ARTs have new product constantly available for potential release. Then the enterprise is free to decide whether or not to ship that asset based on mostly external factors. Having high-quality, deployable, system-level solutions at PI boundaries, at the very least, is critical.
In turn, that also means that some amount of architectural runway must exist prior to the PI Planning session. Otherwise, there’s a danger that architectural rework—followed by the build-out of new features reliant on that rework—may add unacceptable risk to the program.
To mitigate that threat, programs must ensure that the underlying architecture for the most innovative new features are already in the system when planning for the PI. As we’ll see in the following sections, that’s achieved by:
- Building some runway
- Using the runway
- Extending the runway
Building the Architectural Runway
When new platforms are particularly innovative, or in the case of entirely new development, it’s common for the System or Solution Architect/Engineer to play a role in defining and building out the runway. 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 during 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 after that, 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—the activities 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 supporting successful near-term delivery, the architectural runway should also 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.
Consuming the Architectural Runway
With a new architecture in place, and valuable features already deployed, all is good up to this point. This initial success can be temporary, however, as a number of natural forces will tend to consume the architecture over time:
Agile Teams are fast – They have an unparalleled focus and ability to deliver new features, thus consuming the existing runway.
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 rapidly and becomes outdated.
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 what’s shown in Figure 4.
Extending the Architectural Runway
How can teams avoid ending up right back where they started? By realizing that investing in architecture cannot be a one-time or infrequent event. After all, ARTs operate in a continuous flow process using various Kanban systems. Therefore, teams must commit to continuous elaboration, analysis, and implementation of enablers (epics and capabilities and features). 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 delivering value to the customer. (See System and Solution Architect/Engineering and ASR , Chapters 20 and 21, for incremental implementation strategies.)
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 architecture already existing in code when teams start a PI, any features dependent on 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. 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. 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. Runway is explained further in Agile Architecture.
Learn More Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.  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: 1 August, 2017