Show The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay. Architectural Runway supports the continuous flow of value through the Continuous Delivery Pipeline, providing 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 the development of new features and capabilities consumes the architectural runway, a continual investment must be made to extend it by implementing Enablers. Some enablers address shortcomings with the current Solution, such as improving its performance or User Experience. Others 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 [3].” 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. As a result, emergent design alone cannot handle the complexity of large-scale system development, and the following problems start to occur:
All of these problems can result in poor solution performance, bad economics, and slower time-to-market. Intentional Architecture Supports the Bigger PictureEmergent design is not sufficient at scale. No one team in a larger Enterprise or working on a Large Solution 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 Continuous Delivery and Release on Demand with ArchitectureArchitects play a critical role in designing systems that can provide a continuous flow of value to the user. Enterprise Architects define enablers for the portfolio, while System and Solution Architects/Engineering typically define them for ARTs and Solution Trains. 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—meaning it’s potentially deployable, even during its development. Architecture is a key enabler of the Continuous Delivery Pipeline (CDP) and the architecture runway is concerned with building the CDP. An effective CDP provides teams immediate quality feedback offered through Continuous Integration and Continuous Deployment. It also feeds Continuous Exploration and Release on Demand with direct user feedback and validated learning (see Lean UX). The result is a higher-quality product that is adaptable and fit for purpose. Building the Architectural RunwayIn some cases, a new innovation may begin with a significant, architecturally-intensive initiative or create an entirely new product (e.g., a Horizon 3 investment initiative). For these situations, the System or Solution Architect/Engineer plays a key role in defining and building out the runway. The exploration and new infrastructure are initially put in place with a few Agile Teams—sometimes with the Architect/Engineer serving as Product Owner during the first few Iterations, as illustrated in Figure 1. Figure 1. Initiating the Architectural RunwayThe rules for building the runway are both simple and Agile:
To support a stable velocity, the architectural runway needs to be continuously maintained and extended. Capacity allocations (see Program and Solution Backlogs) helps ensure continuous investments in enablers—the activities required 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 not overly constrain development with long-range technical commitments. Just the right amount of architectural runway is required:
Continually invest in the Architectural RunwayForces consume the architecture over time:
These forces consume architecture investment as shown in Figure 3. Figure 3. Using up the Architectural RunwayConsequently, the architectural runway requires continuous investment and is not a one-time or infrequent event. Each iteration, teams commit to the elaboration, analysis, and implementation of enablers. Architects/Engineers and Agile teams will need to acquire skills for splitting enablers into small slices that can be implemented during the course of each iteration and PI, resulting in continuously delivering value to the customer (see Agile Software Requirements, chapters 20 and 21 [2], for incremental implementation strategies). The Architectural Runway in Large SolutionsWhen building really big systems, the architectural runway takes on an even more critical role as multiple ARTs are contributing to the same Solution as part of a Solution Train. The Enterprise Solution Delivery article describes nine practices for building large solutions, of which several interact heavily with the architectural runway:
The Backstory of the Architectural RunwayThe term ‘architectural runway’ started as an analogy while observing PI-level burn-down charts. Often, when there isn’t enough architectural runway when teams start a PI, any features dependent on the 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. A PI, like an airplane, needs enough runway to safely land. 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. Architectural Runway is explained further in Agile Architecture. Learn More[1] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007. [2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011. [3] Manifesto for Agile Software Development. http://www.AgileManifesto.orgLast update: 12 February 2021
|