Patrice Kerremans, Stéphane Campo, Jan Casteels, Jean François Declercq, Kristof Dierckxsens, Bart Du Bois

Enterprise Architecture & Agile:
The Good, the Bad, and the Ugly

As enterprise architects, we’re often confronted with the question: how can we embed an agile way of working in our practice? Or even in a waterfall and agile hybrid? We’re not here to write another article about roles and responsibilities – these are defined by the different methodologies. And we’re not here for a high-level vision, either. We’re here to share our pragmatic thoughts and observations about the Enterprise Architect role within an agile context.


Admittedly, we sometimes feel lost in a desert city full of straight shooters – the squad masters – with one esoteric sheriff, the tribe lead… We have therefore classified our observations into three categories: the Good, the Bad, and the Ugly. We do not pretend to be exhaustive and welcome any observations to enrich the debate.

The Good (do’s):
  1. Manage your architecture backlog
  2. Deliver value incrementally
  3. Be clear about Definition of Done
  4. Distinguish Design Authority from Architecture board
  5. Deliver architectural decisions continuously
  6. Be clear about confusing role names
  7. Stay in control of the big picture
The Bad (don’ts):
  1. Write monolithic architecture documents that nobody reads
  2. Focus too much on the target
The Ugly (really don’ts):
  1. Become the blocking factor
  2. Ignore the daily life of the squad

The Good – The Do’s

1. Do – Manage your Architecture Backlog

Adding, adjusting, grooming and prioritising architectural work items in an architecture backlog has been elaborated upon by Eltjo Poort [1] and Gerben Wierda [2] . In essence it’s about considering architectural decisions as deliverables in themselves. We should be able to build a decision plan for these decisions: without this decision, at that time, we’ll start getting into trouble…


Gerben Wierda’s Enterprise Chess style of managing Architecture Backlog and Solution Backlog


2. Do – Deliver value incrementally

Architects must follow and contribute to the increment, while also being able to position this increment in the overall vision. We therefore need to excel in delivering the narrative about the relationship between the current increment and the overall delivery scope.


Incremental value delivery – from Henrik Kniberg’s article [3]

3. Do – Be clear about the Definition of Done.

Endless deliveries are difficult to follow. In agile, it’s tempting but dangerous to end up with an unclear definition of done and therefore have everlasting architecture tracks. Architecture governance should contribute to measuring and visualising potential deviations at key points in the delivery process.


Checking for course deviations


4. Do – Distinguish Design Authority from the Architecture board

Enterprise architecture is a relatively young discipline with tangible variations across organisations. We often confuse the level of granularity, mistaking architectural decisions as design decisions or vice versa. By clearly separating the design authority function from the architectural decision, we enforce the right level of decision to the appropriate audience/board, avoiding useless meetings for a tribe lead and frustration at squad master level. The right decision, at the right place.


Distinguishing between architecture and design


5. Do – Deliver architectural decisions continuously

How do we present a complete vision when we want to be iterative? At first glance it seems schizophrenic. It’s not. A vision must be formed, with acceptable levels of risk and assumptions. Clarify iterations and validate or invalidate these assumptions. Experienced architects will limit failed iterations but, by definition, we should be realistic and accept that we will also make mistakes at enterprise architecture level.


Fail fast, iterate and pivot [4]

6. Do – Be clear about confusing role names

We need to share terminology, also on roles and responsibilities. Be clear about confusing terms such as solution architect and feature architect, even if it’s not 100% backed by a strong theoretical background. We are not in avionics or core science. IT is one of the youngest and fastest changing industries, so nothing is set in stone. We must remain pragmatic and adapt to new situations.


Roles are defined in context of other roles


7. Do – Stay in control of the big picture

EA is not dead – but it needs more focus on business architecture and customer journeys. The enterprise architects of tomorrow must be increasingly able to talk with business. Execution is gaining autonomy. Instead of fighting to preserve any prerogative, we should adapt and stay in control of the big picture more than ever.


Sense-making and storytelling as key qualities


The Bad – The Don’ts

1. Don’t – Write monolithic architecture documents that nobody reads

Detailed RFPs, documents of 50 pages or more, or long lists of cryptic principles are a thing of the past. Instead, we have to try to work with one-pagers and references cards that are printable, readable, actionable and pragmatic for a broad audience. When a document is used, understood, shared and endorsed, it’s a win.


Margaret Hamilton, lead software engineer of the Apollo Project, stands next to a huge stack of code written by her and her team, in 1969 [5].

2. Don’t – Focus too much on the target

Having a target is important. It’s a starting point. But the focus must be on stable intermediate steps. It’s typically far more difficult to achieve than we initially assumed. The beauty of an architecture in IT is not to build a cathedral, but rather to build a tent and turn it into a cathedral step by step (I can’t remember whose sentence this, but he or she deserves the credit.


3. Don’t – Try to control everything

Again, it’s impossible. Learn to control and mitigate risks instead.


4. Don’t – Throw stuff over the wall without face-to-face interactions.

Value is delivered through interactions between people. The same applies to delivering architecture value. A good collaboration model between enterprise architects and solution architects is essential. This should include face-to-face sessions where architecturally significant observations can be introduced and/or bubble up.


Two forms of the Architect as the navigator: (i) the cartographer mapping/guiding; and (ii) the scout exploring. A good collaborative model between them is essential. [6]

The Ugly – The Really Don’ts

1. Really don’t – Become the blocking factor

Accept to work with identified risks and assumptions and measure the deviations over the time. Work within the limitations. We have seen enterprise architects become the unique point of reference when it comes to integration, communication, etc. In the beginning, such a role is rewarding but it turns hellish over time. Try to explain the principles, the concepts and the big picture to ALL members. Their autonomy will save your life. A good enterprise architect distributes the information and makes sure everyone understands the rationale.

2. Really don’t – Ignore the daily life of the squad

Attend the different ceremonies and participate. The ivory tower must be destroyed, now more than ever.


  1. Just enough anticipation, Architect your time dimension, Eltjo Poort, 2016
  2. Agile & Architecture, Gerben Wierda, 2017
  3. Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable, Henrik Kniberg, 2016
  4. Fail fast, iterate and pivot, Kyle Galbraith, 2017
  5. What to know about the scientist who invented the term “software engineering”, Lori Cameron, IEEE Software Magazine, 2018
  6. The perceived lack of business value of visual models, Charles Edwards, 2014

Related articles