Enterprise Agility-The Big Picture (12): Architectural Runway

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.


Big Picture 12-Architectural Runway

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:

  1. Release dates will be missed as large scale, just-in-time, in-situ infrastructure refactoring adds substantial risk to scheduling
  2. 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).

    Architecture is a role collaboration

    Architecture is a role collaboration

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.

Upcoming September 10, 2008 Webinar – Principles of Agile Architecture

For those interested in the Agile Architecture Series, I’ll be presenting a webinar on this topic on September 10, 2008 at 1:00PM Eastern time. The webinar Principles of Agile Architecture: Intentional Architecture in Enterprise Class Systems is described below:

“As Agile development practices cross the chasm to the enterprise, many interesting debates continue about the role of systems architecture. As the continuous refactoring of emerging-only architectures becomes less practical as the system size and complexity grows, there is a natural desire to minimize unnecessary refactoring as well as to build systems from components that work in a like manner. This defines a role for “Intentional Architecture” in agile, enterprise-class systems development. In this Web seminar, learn about seven core principles that can be applied to architecting these large scale systems without sacrificing the principles or benefits of true software agility.”

This is part of a series sponsored by Rally Software, in collaboration with Sticky Minds and Better Software Magazine, designed specifically for the Enterprise Agilist. This webinar series is designed around specific topics of interest to the larger enterprise adopting agile methods. The description from the website is below:

“Join leading Agile experts, coaches, and authors—including Jean Tabaka, Dean Leffingwell, Stacia Broderick and Ryan Martens—as they paint a picture of successful Enterprise Agile adoption from a team’s first project to enterprise-wide transformation. During this Web seminar series, you will learn proven organizational transition approaches and best practices around Agile project and product management, Agile architecture and quality management. Development, management, and product teams will gain both an understanding of what it means to transition to Agile as well as specific best practices for their role in the organization.”

The series is now available for registration at: http://www.bulldogsolutions.net/SQE/SQE09242008/calendar.aspx?bdls=15887.

And it is FREE!

Principles of Agile Architecture – A Whitepaper

The whitepaper, Principles of Agile Architecture: Intentional Architecture in Enterprise-Class Systems, has now been posted on the Resource page. This whitepaper grew out of a series of blog posts wherein we were trying to define some governing agile principles that teams could use  to guide their agile, system-level architectural practices. My coauthors are Ryan Martens, Rally’s CTO and founder, and Mauricio Zamora, Executive Director from CSG Systems, both of whom are experienced enterprise agilists, architects and thought leaders in their own right.

Agile Architecture – The Whitepaper Now On Line

For those of you following the agile architecture series, you may know that I’ve been working with Ryan Martens, Rally’s CTO and founder, and Mauricio Zamora, from CSG Systems, to put our thoughts on agile, intentional architecture into whitepaper form. Rally has given a big assist to the production and publishing process and I’m happy to announce that the final whitepaper, Principles of Agile Architecture: Intentional Architecture in Enterprise-Class Systems: is now on line at the Rally Knowledge Portal. There’s lots of other enterprise-level content there as well so it’s well worth the simple registration.

For context, here’s an extract:

“In this paper we’ll discuss the role of “Intentional Architecture” in the development of enterprise-class systems built using agile methods and techniques. In order to gain a better understanding of this important practice, we’ll describe:

• The context and challenges of large-scale system architecture in Agile development

• The need for Intentional Architecture to buttress emerging architecture

• How the traditional systems architect can contribute to Agile teams”

The paper goes on ……

” There are a number of governing principles teams can apply to the challenge of architecture development in large-scale systems. These governing principles are:

Principle #1 The teams that code the system design the system.

Principle #2 Build the simplest architecture that can possibly work.

Principle #3 When in doubt, code it out.

Principle #4 They build it, they test it.

Principle #5 The bigger the system, the longer the runway.

Principle #6 System architecture is a role collaboration.

Principle #7 There is no monopoly on innovation.”

If you are building big systems, I think you’ll find it interesting reading.

Recap: SEVEN Principles of Agile Architecture

Those following the agile architecture series will probably note that the principles and labels have morphed over time. I’ve been collaborating with Ryan Martens, Rally’s founder and CTO, and Mauricio Zamora, Executive Director at CSG Systems, in writing a whitepaper to be published on this topic. In the process, we’ve also had some comments from Grady Booch and Philippe Kruchten and the content has been evolving as a result. The article is nearly finished and I’ll post it here just as soon as it’s available.

In the meantime, here’s the (hopefully final) set of principles the article espouses:

Principle #1 ─ The teams that code the system design the system.

Principle #2 ─ Build the simplest architecture that can possibly work.

Principle #3 ─ When in doubt, code it out.

Principle #4 ─ They build it, they test it.

Principle #5 ─ The bigger the system, the longer the runway.

Principle #6 ─ System architecture is a role collaboration.

Principle #7 ─ There is no monopoly on innovation.

Agile Architecture Principle #7 – There is no monopoly on innovation

Note: this is one in a series of posts under the category of “agile architecture”. In an earlier post, (Six Principles of Agile Architecture) we identified six (ok, now seven) principles that we can apply to help us reason about the challenge of architecting systems of scale in an agile enterprise.

“Inertia is the residue of past innovation efforts.
Left unmanaged it consumes the resources required to fund next-generation innovation.”
—Geoffrey Moore

In an earlier principle, the bigger the system, the longer the runway, we described the need for teams to have sufficient architectural runway to be able to reliably “land” near term iterations and releases. In a sense, this is the upside of inertia enough is known from prior experience and development to allow the team to provide reliable and consistent value delivery. Indeed, with agile, we have strong technical and project management mechanisms (and some architectural runway) in place to help us stay focused to this sole purpose.

In other words, agile practices provide a disciplined, production-like ability to reliably meet commitments and to rapidly evolve a system to meet existing customer requirements. We treasure our new-found reliability as a very good thing indeed.

But there is a downside as well. If we are not careful, the “tyranny of the urgent” will cause us to keep our heads down and focused solely on near term deliverables. So where does the innovation come from in such a model? Simply, mature agilists put processes in place to assure that innovation is not solely incremental and near term.

Some of our innovation practice comes from empowering the role of the system architects as part of our advanced guard, to be constantly exploring new technologies, patterns and techniques that can help us innovate. But ours is a team-centric model, so we clearly will not rely on architects as the sole source of such innovation. In fact, the team-centric model can foster innovation at an even greater rate than that generally seen in traditional software organizations. This is because true innovators innovate at all stages of their career (entry level, junior and senior) and the team-centric model enables these folks to flourish and contribute beyond what their level of experience may otherwise imply.

One way to foster iteration at the team level is by judicious backlog management that includes spikes for refactoring, design and exploration of new ideas. This can work quite well, but even more explicit models have been put into use. For example, at Rally Software Development, where they have been building their SaaS Agile Product management solution in a highly agile fashion for four years (with rarely a missed or delayed release commitment), they have evolved to an advanced development cadence as illustrated in the figure below.

An iteration cadence that fosters innovation

Figure – An iteration and release cadence with one innovation “hackthon” per release

This figure illustrates a standard release cycle, where

i” is a standard development iteration, providing new functionality for an upcoming release

h” is a one week hardening iteration, to eliminate technical debt and assure quality requirements meet the release to manufacturing criteria

k” is a “hackathon”.

The hackathon is designed to foster innovation at the team level. The rules of the hackathon are simple: any team member can explore any technology area in any way they want, so long as there is some correlation to the company’s mission. This gives the team some mental down timeto reflect, think and experimentoutside of the everyday rigor and pressures of the iteration and release cycle.

With a model such as this, innovation is expected and programmatic, and there can be no ambiguity to the point to this (and our last!) Principle # 7 There is no monopoly on innovation.