XPLUS, uw strategische partner bij digitale transformatie.

XPLUS, votre partenaire stratégique dans la transformation digitale.

XPLUS, apporte la connaissance des TIC aux dirigeants d’entreprises

XPLUS, brengt ICT-kennis naar de board

XPLUS Consulting: de omgekeerde pyramide werkt!

Enterprise Architecture & Agile –

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

As enterprise architects, we are so often confronted with this question:
How can we embed an agile way of working into our practice? Or even in a waterfall/agile hybrid?

We’re not here to write another article about roles and responsibilities – these are defined by the different methodologies. We’re not here for a high-level vision, either.  We’re here to share our pragmatic observations and thoughts about the role of an Enterprise Architect 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….

Figure 1 – Feeling lost in a desert city full of straight shooters – the squad masters – with one esoteric sheriff, the tribe lead….”

Hence we have classified our observations into three categories:


the good (dos): the bad (don’t): the ugly (really don’t ):
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.      Be in control of the big picture

1.      Write monolithic architecture documents that nobody reads

2.      Focus too much on the target

1.      Become the blocking factor

2.      Ignore the daily life of the squad

We do not pretend to be exhaustive, and welcome any observations to enrichen the debate.

The good – The dos

Do #1 – Manage your Architecture Backlog

Adding, adjusting, grooming, and prioritizing architectural work items on an architecture backlog has been elaborated by Eltjo Poort [1] and Gerben Wierda [2] . In essence it’s about considering architectural decisions as deliverables in themselves.



Figure 2 – Gerben Wierda’s Enterprise Chess style of managing Architecture Backlog and Solution Backlog [2]

For these decisions we should be able to build a decision plan: Without this decision, at that time, we’ll start getting into trouble…

Do #2 – Deliver value incrementally

Architects must follow and contribute to the increment, whilst also being able to position this increment in the overall vision. Hence we need to excel in delivering the narrative about the relation between the current increment and the overall delivery scope.


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

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

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

Figure 4 – checking for course deviations

Do #4 – Distinguish Design Authority from the Architecture board

Enterprise architecture is a relatively young discipline with tangible variations across organizations. 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 or frustration at the squad master level. The right decision, at the right place.

Figure 5 – Distinguishing between architecture and design

Do #5 – 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 made, 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 also at the level of enterprise architecture we will make failures.

Figure 6 – Fail fast, iterate and pivot [4]

Do #6 – 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 written in stone. We must remain pragmatic and adapt to new situations.

Figure 7 – Roles are defined in context of other roles

Do #7 – Be in control of the big picture

EA is not dead – yet it needs more focus on business architecture and more focus on customer journeys.  The enterprise architects of tomorrow must be more and more capable of talking with business.

Execution is gaining autonomy. Instead of fighting to preserve any prerogative, we should adapt and be in control of the big picture more than ever.

Figure 8 – sensemaking and storytelling as key qualities

The bad – The Don’t

Don’t #1 – Write monolithic architecture document that nobody reads

Very detailed RFPs, documents of 50 or more pages 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.

Figure 9 – 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].

Don’t #2 – 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 to turn it into a cathedral step by step (I can’t remember whose sentence this, but he or she deserves the credit 😉

Don’t #3 – Try to control everything

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

Don’t #4 – 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.


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

The ugly – The really don’t

Really don’t #1 – become the blocking factor

Accept to work with identified risks and assumptions and measure the deviations over the time.  Work with the limitations.

We have seen enterprise architects becoming the unique point of reference when it comes to integration, communication… In the beginning, such a role is rewarding but it turns into hell 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 everybody understands the rationale.

Really don’t #2 – 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