Alle ingenieurs werken aan duurzame oplossingen. Dat zit in hun DNA

Een omgekeerde piramide voor elke onderneming

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

XPLUS Community: How to send your legacy applications on a well-deserved retirement? Ep. 1

How to send your legacy applications on a well-deserved retirement?

In this series, several of our consultants will give their advises on one of the hottest market  topic of the moment. How to manage legacy applications decommissioning?

When you are working as an IT consultant within established businesses / industries (as in my case, banking), you will have probably encountered a lot of legacy landscapes.

As a consultant we help the banks to enrol large transformation programs to be ready to serve the customer in a new Digital way.

The implementation of these programs is most of the time well organised (everyone in IT likes to work on challenging projects which make use of cutting edge technologies). However, one task is often forgotten, to get rid of the obsolete applications.

Nevertheless it is important that the Banks Business strategy and its evolution towards Digital is reflected in its application portfolio. And here the problem starts, the application portfolio of banks is often the result of decades of history with solutions to punctual problems, technology brought in to solve an immediate challenge, incomplete consolidation after M&A or corporate restructuring, change of legislation.

Management attention is set on new functionality which makes decommissioning a “deferrable” expense.

In order to (partially) solve this issue, we should make the projects / programs which deliver new solutions also accountable for the obsolete applications. These teams should take specific actions (i.e. lifecycle management update, reengineering, decommissioning, …) in order to put the legacy applications that they are replacing in retirement.

In order to obtain a good obsolescence rate, it also seems important that this work is done by a different team than the team that maintains the legacy.

A fresh view on the existing business / IT problem is often welcome. Nevertheless, it has taken IT decades to reach its current state, so we can assume that we will not be able to remedy all of this in a portfolio overnight.

The decommissioning exercise is a serious transformation initiative on its own.

Frederic Crabbe

XPLUS Talks: meet Rudy Wouters, ING chief architect

Last week I spent a few hours talking with the Chief Architect Rudy Wouters ( ING Tech Chief architect for Market Leaders ).

Rudy answered a series of questions regarding Digital transformation and enterprise architecture.

We are happy to share his experience with you !

In one sentence, how would you describe what is a ‘digital transformation’?

[Wouters, R. (Rudy)]  Digital transformation is happening to the daily life of everyone, i.e. activities like shopping, socialising, gaming, gambling, managing finances are now done online.

How would you describe your role as chief architect?

[Wouters, R. (Rudy)] As a chief architect, my mission is : “ To develop, advise on and execute the architecture policy, standards and strategy, in order to position adequate IT capabilities for realizing and enabling changing business needs and moving towards a globally scalable and secure banking platform.”

As part of this mission, we create an environment to continuously foster the professionalism of the architects. After all, stable and secure solutions are delivered by good professionals.

What are your daily difficulties?

[Wouters, R. (Rudy)] Finding the right balance and priorities. Dividing the attention between Horizon 1, 2 and 3 work, between planning and operational support, between less and more detail to deliver to the squads, between first time right and iterative improvements, between global and local solutions.

How do you see architects’ responsibilities evolving?

[Wouters, R. (Rudy)] ING is implementing globally a new and agile way of working. Predominantly this means that accountability and autonomy is given to multi-disciplinary squads. To get the full potential out of the squads, they need to be fed with sufficient context and boundaries, not with details. This means that although the purpose of the architects still remains the same, the service is delivered in a different way. In addition, architects will have to spend more time in structuring the portfolio well in advance and provide a view of how business outcomes can be realised across the different assets and thus teams. The latter requires a mature collaboration, between architects and tribe leads. Overall, communication competencies become more important than deep technical knowledge in specific technologies.

What  is – from your point of view – the next innovation that will impact your activity?

[Wouters, R. (Rudy)] As the digital transformation advances, also within the bank, the business processes are moving towards full digitisation. E.g. some of the least expected ones a few years ago, are now picked up by robots. This means that, whatever happened within and often also outside the company, is available in exploitable data. Still today, humans interpret these data to take business decisions. More and more of these feedback loops will become automated, meaning that commercial and operational aspects of the business will adapt themselves to the reality created by the customers. This means that software engineers will focus more on smart algorithms and artificial intelligence to keep up with the required agility. Stand-ups will be more organised around screens showing how systems are currently running the business, trying to understand why this is happening and consequently maybe steer the responses in a different direction.

What  is the current digitalization challenge of your company today?

[Wouters, R. (Rudy)] We still have difficulties to benefit from our size, i.e. it is a challenge to work towards globalized solutions, that are being used many times. Mainly this is coming from the different speeds of the business in different parts of the world and leads to differences in priority. Eventually, the speed of change is limited by the amount of engineers that can be put to work in an effective manner.

Which transformation project is the most risky from your point of view?

[Wouters, R. (Rudy)] To be really competitive in a digitalised world, also the core systems of the bank must be adapted to more real-time and data driven processing. As this happens in flight, it is risky for many reasons: because they are part of nearly all business flows, there is a real danger of jeopardising stability and continuity of the business, at the same time, there is only in the long run additional value visible, which increases the risk of losing focus leading inevitably to failure to deliver.

Which transformation project will bring you the most value?

[Wouters, R. (Rudy)] In terms of potential, it will most probably be situated around the core systems upgrade, in terms of immediate value it will be related to how we change our means for integration in to the ecosystem.

Explain the risk of omission of EA, in other words, what happens when it is not present?

[Wouters, R. (Rudy)] Every company with a sizable change portfolio has had this experience already several times. Without the structuring capabilities of EA, it is very difficult for executives to have sufficient overview to determine a strategy that is not disconnected from reality. Defining a target view may still be easy enough, but when sufficient structured information down to the operational level is missing, it is impossible to define executable steps that lead to that target or even understand that the target cannot be achieved, inevitably not leading to the desired outcomes.

How do you communicate the value of architecture to your CIO and other Cxo’s?

[Wouters, R. (Rudy)] Talking or reading about it will not do the trick. If that would be true, everyone would be convinced. There is enough lecture on the subject to fill a room. According to me, the difference can be made by the actions of the architects at all layers of the company, from operational to tactical to strategic activities. The architects should always prioritize their activities towards complementing the value of the teams and ensuring stability of the solutions. This added value finds its source in the structured oversight they have and their understanding of how everything relates to the desired outcomes. Architects with this behavior will be communicated about.

Which book recently influenced you ?

[Wouters, R. (Rudy)] There are actually two:

1/ “reinventing organisations” from Frederic Laloux

2/ “Continuous Architecture, sustainable architecture in an agile and cloud-centric world” from Murat Erder and Pierre Pureur

How do you see the challenge of training, keeping your architects?

Given the importance for architects of context and integration with the organisation, there is added value in a stable architecture workforce. How can architects then be convinced to stay with the company while satisfying their desire for new challenges. For this reason, we’re working in a partnership with XPlus on a true architecture training platform. The idea is to allow companies to produce and consume interesting training, dedicated to architects. At the same time, there is an opportunity to bring together architects from non-competing industries, in classical training. When brought together, being presented with similar challenges, they may exchange valuable information with each other but even more, they may ignite new ideas for collaboration across companies. The main idea is to enable companies to create their own architects – you don’t hire an architect, you create one. On the other side, it allows architects to find diversity in their work, without having to switch company.

Verifiable Claims: distributed proof of one or more capabilities

By Patrice Kerremans

What is it?
The official definition from the W3C Credentials Community Group is: A statement made by an entity about a subject; A verifiable claim is a claim that is effectively tamper-proof and whose authorship can be cryptographically verified. Multiple claims may be bundled together into a set of claims.
The (somewhat unspoken) fact is that claims can be distributed and do not require a centralized system, because their verification is a matter of cryptographically verifying them. That is, you don’t need a central server to be up-and-running and accessible at all times for you to be able to verify the claim. This makes the system very sturdy.
Also, the creation of claims is delegated to the issuers, making it even a more distributed system. What is it good for?

Other interesting examples include: proving you’re old enough to (buy a) drink, proving you have the required driver’s license when renting a car.
There’s a complete description of the use cases on the W3C github.
Who are the actors/players?
In order for this to work, you’ll need the following actors:
An entity that creates a verifiable claim, associates it with a particular subject, and transmits it to a holder. This can be -for example-
a bank (certifying account ownership), or
a doctor (certifying that you have a certain ailment), or
a government certifying your identity or your birth certificate
a school certifying you’ve successfully achieved a certain degree
An entity that is in control of one or more verifiable claims. This is typically the subject of the claims. But it can also be a third party that holds on to the claims on behalf of the subject.
A statement made by an entity about a subject and that is tamper-proof and whose authorship can be cryptographically verified. This means that
when someone fiddles with a claim, this can be detected; rendering the claim useless
but also that when someone tries to counterfeit one this is detectable; also rendering the claim useless
Say that you create a claim that you’ve obtained a degree at the University of Ghent (UoG). Since the claim won’t have been signed with the private (& secret) key of the UoG, the claims digital signature will be incorrect and others will detect this.
An entity that receives one or more verifiable claims for processing. Examples of inspector-verifiers include employers, security personnel, car rental services, and websites.
Identifier Registry
Mediates the creation and verification of subject identifiers. Examples of identifier registries include corporate employee databases, government ID databases, and distributed ledgers.
In the next post we’ll go into how to implement this…

Book Review: The Phoenix Project

By Frédéric Crabbe &  Hans Dijckmans

Frédéric Crabbe

This is a novel which tries to explain the underlying story of how an organisation can go into crisis because IT and software development form a bottleneck for the business. What I like about this book is that it looks at an IT transformation via DevOps (or agile, or any other buzzword you prefer) and is gradually showing the relevance of IT in the enterprise and how interconnected everything is that makes the business run. So calling this a DevOps book is an understatement. The book takes a broad view of DevOps and shows how it can be used as a way to integrate IT into the business rather than being an under-performing cost-centre (the way business often looks at IT). The underlying idea is to take the lean methodologies from manufacturing, and bring them to IT. It also shows that by promoting system thinking (over local optimization), feedback loops and a continuous learning culture. Of course, automation and continuous delivery are necessary intermediate steps for most traditional IT organisations on that journey.

Hans Dijckmans

The book tells the story of an IT department manager Bill Palmer, being promoted against his will to Vice-President (VP) of IT Operations within the company Parts Unlimited, a manufacturing and retail company. Parts Unlimited is losing market share quickly and is very much dependent on the successful implementation of a strategic project called the “Phoenix project”. But before critical IT resources within the company can focus on that project, there is a lot of other “IT pain” to be resolved. The book describes Bill’s journey in facing these IT challenges, ultimately giving the IT department a new and positive image within the company. As the book is written in novel style, it offers an entertaining story line and tons of deja-vu moments for most of us. The book is overall relatively realistic in its description of difficulties that IT organisations are facing, but the multitude of problems might be a little more than what you will find in one single IT organisation. Nonetheless, the book is very good in its initial objective, which is to apply the theory of constraints to IT and in showing that IT isn’t that much different from manufacturing. In addition, the added-value of ITIL and DevOps are demonstrated. Organisational anti-patterns that commonly impede business and IT cooperation are nicely described. It outlines you ways to escape the vicious circle by keeping things simple, building trust, making objective observations and trying out new approaches.