Author: Richmond Stevenson

In 2001, the Agile Alliance was formed. A group of leading software engineers, architects, and software project managers created the Agile Manifesto: a collection of 12 key principles that described a new way to deliver technology solutions for business. Their efforts grew out of a dissatisfaction with the traditional way in which systems development and delivery projects were run, and out of a recognition that the clear majority of systems delivery efforts were failing to meet the expectations of the business stakeholders that chartered them. The Agile Manifesto’s principles intended to solve this problem by encouraging business stakeholders and technology delivery teams to work side-by-side, in non-hierarchical and self-managing teams, focusing on using small and manageable periods of work, frequent prototyping and releasing of code, and eschewing documentation and design efforts for working and self-documenting code. To many, this seems at odds with the EA discipline, which focuses on top-down and long-term planning, governance, and the development of architecture models as a form of documentation of the as-is and to-be environments.

Agile methodologies are fast becoming the standard approach for delivering technology solutions. EA must adapt to coexist with agile delivery teams. To do so, EA needs to rethink the way it engages with the agile delivery teams. It must consider how the EA function can accelerate the time-to-value of agile teams, and how to keep agile teams aligned with the long-term plans of the organization. One approach is to focus less on traditional governance and standards enforcement. Instead, EA may provide architectural decisions, implementable architectural patterns and reference architectures that incorporate standards into their design. Another is to help frame the scope of the agile delivery team before it begins work by aligning the agile solution to a set of capability requirements. In this way, EA becomes a surrogate or additional sponsor for eliciting business requirements. EA can help define the duration of the agile team’s delivery increments based on its long-term planning role. EA may be responsible for managing technical debt for one or more agile projects and advocating for new projects or user stories to reduce it. Finally, EA may be part of the delivery team performing research or technical design work as in an architectural “spike” in the language of eXtreme Programming. A relatively recent agile method – the Scaled Agile Framework – explicitly identifies a role for EA in coordination across two or more delivery teams, focusing on these potential collaborations.

EA can also learn to adopt agile methods in its work to address some of the criticism it often receives that EA takes too long to return value or that its products are out of date nearly as soon as they are delivered. EA could use the agile backlog concept to manage its work, and prune and refine a backlog of business needs to validate it is working on the highest priority item at any time. EA teams may focus on iteration as a technique to develop architectural artifacts, using a “just-in-time” or “minimum viable product” approach to producing representations of the environment to a sufficient level of detail enough for making decisions and not further. Finally, EA may wish to reduce its time-horizon for strategic planning, with a focus on frequent incremental refreshes on nearer-term states rather than exhaustive long-term planning as is typically done; out years may be less well defined, with a plan to improve them as they approach. In this way, the goal of EA is not to provide a rigid roadmap achievable by an artificially constrained end date. Instead, EA may produce an ever-extending and changing plan, constantly adapting and refreshing as required by the business and technology landscape demands.

Both disciplines have proven strengths and weaknesses, but EA and agile delivery are not often used in concert because of the perceived contradiction in their purpose. Given the relative strengths of each, and the ability for one practice to mitigate weakness in the other, a better approach is to think of them as complementary disciplines. Using emerging techniques to incorporate the two, organizations can derive the benefits of long-term strategic planning from the practice of enterprise architecture with the advantages of rapid delivery that is a hallmark of agile.

Further Reading

1. The TOGAF Standard, Version 9.2 – Applying Iteration to the ADM. (2018)
2. Scaled Agile Framework – SAFe for Lean Enterprises. (2010-2018)
3. Manifesto for Agile Software Development. (2001)