Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed Agile Development Teams, Agile System Teams, Iterations , Agile Product Owner, Backlog, User Stories and the Iteration Backlog , Release , Vision and Release Backlog , The Roadmap, Agile Product Manager, and the Release Management Team. In this post we’ll describe Architecture Runway [callout 12] below.
For any familiar with this blog or my book (Chapter16 of SSA – Intentional Architecture), the topic of agile, intentional architecture is not a new topic. The blog series on this topic is here. A whitepaper in this topic, Principles of Agile Architecture: Intentional Architecture in Enterprise-Class Systems, coauthored by myself, Ryan martens and Mauricio Zamora can be found here. Also, I recently presented a Rally webinar on this topic and you can see that webinar here.
In Scaling Software Agility, I defined architectural runway as:
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.
Continuous build out and maintenance of new architectural runway is the responsibility of all mature agile teams. Failing to do so will call cause one of two things to happen, either of which is very bad:
- Release dates will be missed as large scale, just-in-time, in-situ infrastructure refactoring adds substantial risk to scheduling
- Failure to address the problem systemically means that the teams will eventually run out of runway. New features cannot be added and the system becomes so brittle and unstable that it has to be rewritten from the ground up.
Architecture in the Big Picture
With respect to the Big Picture, Intentional Architecture appears as a “red thread” through various levels of the hierarchy.
- Level 3 – At Level 3, Architectural Runway is represented by Infrastructure initiatives that have the same level of importance as the larger scale requirements epics that drive the company’s vision forward. While many architectural initiatives will be addressed routinely by the teams over time, others require elevation to the portfolio level to assure awareness and communication of these important initiatives. They will consume substantive resources and failing to implement them will compromise the company’s position in the market. They must be visible, estimated and planned just like any other epic.
- Level 2 – At Level 2, Product Managers, System Teams and other stakeholders translate the architectural epics into features that are relevant to each release. They are prioritized, estimated and resourced like any other feature. At each release boundary, each architectural initiative must also be conceptually complete, so as to not compromise the new release, though it may or may not surface itself to the user.
- Level 1- At level 1, refactors, design spikes, evaluations etc. that are necessary to extend the runway are simply a type of story that is prioritized like any other story. Architectural work is visible, accountable and demonstrable at every iteration boundary. This is accomplished by agreement and collaboration with the system architects (Level 2) and agile team and tech leads (Level 1) who determine what spikes need to happen when, and who work with the Product Owner to prioritize the iteration backlog. (see picture below).
In this manner, architecture is a first class citizen of the Big Picture and is a routine portfolio investment consideration for the Agile Enterprise.
In the next Post, we’ll elaborate on the Agile Portfolio Vision.