Architecture is basically a container of something. I hope they will enjoy not so much the teacup, but the tea.

– Yoshio Taniguchi

Architectural Runway Abstract

Architectural runway exists when the enterprise’s platforms have sufficient technological infrastructure to support the implementation of the highest priority business epics in the portfolio backlog without excessive, delay-inducing, redesign. In order to achieve some degree of runway, the enterprise must continually invest in refactoring and extending existing platforms as well as building and deploying those new platforms needed for evolving business requirements.

In the Agile enterprise, implementation of architectural epics is complicated by the fact that the “big-bang-up-front branch-and-merge” waterfall approach is abandoned. Instead, the enterprise commits to implementing architectural epics like all other epics (and features, and so on) incrementally in the main codeline. 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 PSI/Release such that the system always runs, at least at the PSI/Release boundaries. In some cases, this means that new architectural initiatives are implemented piece-meal and may not even be exposed to the users in the PSI/Release in which they are implemented. In this way, architecture 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.

Details

SAFe uses PSI/Release 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, 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) PSI/Release boundaries is sacrosanct. In turn, that means that some amount of architectural runway must exist going into the PSI/Release 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 for the most innovative new Features are already in the system when planning for the PSI/Release. 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 first introduced in Scaling Software Agility (SSA, ref [1] chap. 16) and has been extended in Agile Software Requirements (ASR, ref. [2]). 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. It is also 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.

Figure 1. Initiating the Architectural Runway

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.

Figure 2. Building more runway

In this way, the teams quickly build up some architectural runway, as illustrated in Figure 3.

Figure 3 Progress in Building architectural runway

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 very 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.

Figure 4. Using up the architectural runway

Extending It

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 new-found skills that provide for splitting architectural epics and features into small slices that can be implemented during the course of each iteration and PSI/Release, thereby continuously delivering value to the customer. (See System Architect Page and ASR [2],. Chapters 20 and 21, for incremental implementation strategies.)

Learn More

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

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

Last update: 15 January, 2013