Why We need architecture runway?

Agile principle states that “The best architectures, requirements, and designs emerge from self organizing teams”. So architecture emerges in agile and it is the responsibility of the self organizing teams to evolve an architecture that can reliably host the existing and new requirements. This works well when agile is applied in small team.

As agile scales across the enterprise, the teams and teams of teams are building ever larger systems. When teams build components that need to integrate and work together, each component must be built to a well defined interface. It must also be ensured that changes in one component do not ripple to changes in another component, which would cause a cycle of refactoring that could affect a large number of teams.

One way to minimize large scale refactoring and to help disparate teams build features and components that integrate easily is to have some amount of Architectural Runway.


What is Architecture Runway?

Dean Leffingwell states

“A system that has architectural runway contains existing or planned infrastructure sufficient to allow incorporation of current and near term anticipated requirements without excessive refactoring”
Architecture runway is defined as a part of the “Big picture” defined by the same author . The enterprise is divided into three different levels . Portfolio, Program and Project. Even though Architecture runway is part of the Portfolio level, The impact is felt in all the levels.

Portfolio – At the Portfolio level, architectural runway is represented by ongoing infrastructure initiatives. These initiatives should have the same level of importance as the larger scale requirements epics that drive the company’s vision forward. Architectural epics must be visible, estimated and planned just like any other epic.

Program – Once identified, architects, system teams, project teams and other stakeholders translate the architectural epics into architectural features that are relevant to each release. They are prioritized, estimated and resourced like any other feature. And, like features, each architectural initiative must also be conceptually complete (no overhang, no implied but missing functionality) at each release boundary, so as to not compromise the release increment.

Project – At the Project level, refactors, design spikes , evaluations etc. that are necessary to extend the runway are simply a type of story that are prioritized like any other story. Like user value stories, architectural work is visible, accountable and demonstrable at every iteration boundary. This is accomplished by agreement and collaboration with the system architects, product owners, and agile tech leads that determine what spikes need to happen, and when.


Building Architecture Runway

When building large scale systems in agile manner, components are the basic building blocks . The components and their interfaces are defined by the system architecture. Agile teams should organize around components , each of which can be defined/build/tested by the team that is accountable for delivering it.
However in order to form such teams we should have sufficient architecture established prior to substantive development and deployment of teams of teams to build the application. This becomes a chicken and egg problem because there cannot be teams without architecture and there cannot be architecture without a team.
To solve this, the organization will drive creation of an architecture team consisting of senior architects in the organization or a collection of architects and/or technical leaders from other teams . This team will have the responsibility to determine the initial component based architecture that will influence the eventual formation of the application teams. In addition it is likely that a prototyping team may be created or may exist, and that team may be used to test the architecture in the first few iterations.

In the next few iterations, additional resources are added to the project. It may be a component team implementing pieces of infrastructure, such as persistence or API or SDK, or it may be a feature or application team responsible for implementation of specific customer functionality.

All these teams follow the same iteration pattern and are forced to integrate with the architecture as frequently as possible, ideally on a daily, continuous integration basis.


The architecture thus developed must include domain models, component models, deployment models, and whatever else is required to support feature development for some reasonable, upcoming portion of the application lifecycle. In systems of complexity, building and maintaining sufficient architectural runway is a key to overall productivity.

Extending architecture runway

During the course of time there will be new and changing customer requirements. There will also be changes in the technological landscape. To accommodate this we should handle two things
a) Constant, incremental refactoring
b) Constantly extending the architecture runway.

While the principles of refactoring are well described in agile and out of scope for this text, Let us look at the methods of extending architectural runway. It is also to be noted that efficient extension of architecture runway will itself avoid unnecessary refactoring. This is an additional team skill that must be mastered so that the teams can avoid architectural dead ends that eventually doom the product.

Extending Architectural Runway: A Lean, Pull based Approach
There are many methods that teams can apply to extending runway, and they are as varied as the teams themselves. Much depends on where the architectural expertise lies. In larger scale systems, architects or an architecture team may operate somewhat independently of the component iteration process, working in advance to extend the architecture prior to the needs of the component teams. This pull based approach looks over the horizon at the upcoming release plans to determine what features the system may require that are not presently supported by the architecture. The architects may do their own spikes in synchronization with the release train, or they may work in an asynchronous manner driven by their own resource and schedule concerns. In any case, the teams are driven to a common set of objectives:
1 . Just enough architecture to support the next few releases
2. Available just-in-time prior to the iteration or release boundary that creates these new demands.
3. Architecture that is proven in code, either via the architecture teams themselves or via development spikes that are implemented by the component teams.

Extending Architectural Runway: Synchronizing with the Iteration
One way that teams approach the extension of architectural runway is to "program" design spikes into each iteration. Design spikes are activities intended to address design challenges, architectural extensions, and the impact of new technologies or to explore critical problems with the existing solution. As such, while design spikes do not directly deliver end user value, they are critical to the long term ability of the team to do so, and they are therefore treated just like user stories in the iteration. In other words, they take resources and they are therefore defined, prioritized, estimated, completed, and demonstrated like any other story in the iteration. They are not refactors in that the application code may be completely unaffected—the spikes just serve to extend the architectural understanding by some small amount in a specific technical direction.
In application, design spikes create a more ad hoc, but still programmatic, iteration pattern, as shown in the illustration.

Of course, these design spikes affect the value delivery velocity of the team because they use resources, and often key lead and technical resources at that. But they also extend architectural runway and are critical to the ability of the team to provide customer value over the long haul.

Another way to address the problem is to dedicate entire iterations to building runway, as specified in this illustration.



The advantage to this approach is that the entire team is engaged. Engaging the entire team fits the agile mantra by empowering the team to make its own technical decisions. The disadvantage is that those iterations will have little if any other delivered value, and it takes real management discipline and a supportive customer context to make that work.

Conclusion

Either way, for systems of scale, it is incumbent on the enterprise to have sufficient architectural runway to support the future requirements on the system.

It is also important to look at agile requirements practices and gain insights to how teams come to understand the requirements to which their "just sufficiently adequate architecture" must respond.