Is Brexit the worst ever EA project?

Lessons for Enterprise Architecture from Brexit

As I live in the UK it’s not surprising that Brexit is a hot and controversial topic. Last night Elaine and I were recounting everything that we felt had gone wrong during the Brexit process (it was a long conversation), and I started thinking about Brexit as if it were an Enterprise Architecture project.

Bear with me… because it’s not as far fetched as it might seem – Brexit could be seen as changing the architecture of Europe.

Here are my initial thoughts on this comparison:

  • The UK called a referendum about membership of the European Union in 2016. In effect this was a response to the concerns of some UK citizens (stakeholders). Ideally the enterprise architecture team would have done some research into these various concerns to get a clear overview of the problems, issues or constraints inherent in the current system-of-interest (i.e. the European Union).
  • ISO 42010 Conceptual Model

    ISO 42010 Conceptual Model

    Following the conceptual model of the ISO 42010 standard the architects would have identified the stakeholders, documented their concerns, and listed the necessary architecture viewpoints and views.

  • Then they would examine the architecture of the system-of-interest to produce an architecture description which covered the relevant components and their configuration – in other words, what was it about the current architecture that led to the concerns.

What went wrong: instead of really understanding stakeholder concerns, the Brexit architects rushed in with a black-white yes-no question. In effect, the architecture team asked “Do you like the current architecture – YES or NO?” Not surprisingly, when a debate is based on emotions and feelings, or when the future options are reduced to choosing “this” or “that” it indicates little or no understanding of the architecture.

If Brexit was an EA project it would need to start with clarity about the concerns, and clarity on how the current architecture contributed to those concerns.

It would also need to provide clarity about the possible target architecture, including alternative target options, and it may need to provide details of any transition states. This would be presented in the form of a roadmap that clearly showed the strategic themes and vectors. For such a mammoth change, stakeholders would expect to see a long term architecture vision. Each architectural state could be summarised as an architecture pattern, which would need to include the relevant criteria to aid decision-making (such as costs, risks, benefits, etc.).

What went wrong: instead of providing the necessary details that would allow stakeholders to make informed decisions, the Brexit “architects” started by asking all stakeholders to vote for their personal preferences (which had already been distilled into the Yes/No options). There was little effort to provide useful artifacts, roadmaps, alternative options, or criteria to aid decision making. Some might say that the architects (deliberately?) gave false and conflicting information to stakeholders!

The final point I want to make is that the European Union can be considered a “system”, but there are also separate “systems” for each of the member countries. When Britain leaves the EU it will be leaving the EU system, but this will require changes to the British system, So there isn’t a one-to-one mapping of architecture to system – there are several different (although overlapping and related) architectures that need to change, and the relationship between these architectures is not simple. [For example, see this Wikipedia article for a discussion of the relationships between political groups of the European Parliament]

To complicate the picture further – the EU is just one of many systems that each country belongs to. The common market can be considered another system, as can NATO, the Commonwealth, the G7 – and in this complex world that we live in there are many other economic, social, political, and environmental organisations.

There are two key points to this:

  1. Firstly, every country is a member of countless trade, governing, or regulating bodies – so unpacking the dependencies and inter-connections between systems is tricky;
  2. And secondly, while the differences at the systems level are enormous and can be hugely difficult to decipher, the architectural level of understanding often reveals the common principles, similar types of components, and repeating templates or patterns.
Levels of Understanding

Levels of Understanding

The architectural and systems levels of understanding are both necessary for a resolution of the concerns. It is no good analysing at the systems level without balancing this with an architectural understanding.

What went wrong: with Brexit there doesn’t appear to be any serious attempt at analysis at either the systems or the architectural level! For example, there is widespread ignorance at the systems level on the difference between the EU and the free trade area, customs union and single market. Discussions have focused on Britain leaving the EU, but there are widespread repercussions for other related “systems” such as NATO. And don’t even get me started on the total lack of architectural thinking (this link is to my free course on this subject). Awareness of the levels of understanding and in particular the relationship between systems and architectural thinking would have made a big difference to the Brexit debate.

Although I’ve used Brexit as an example, the failings of Brexit as an EA project are also common failings in genuine examples of EA projects. So… here are three key learning points:

  1. Really get to understand the concerns of your stakeholders. I’ve come across so many EA projects where knowledge of concerns is flimsy at best.
  2. Provide plenty of useful charts, diagrams and other criteria to help and guide decision makers. Many EA teams forget this vital role of decision facilitator.
  3. Understand and leverage the differences in understanding wicked problems at both the systems and architectural levels. Most EA teams apply EA as if systems and architecture are synonymous, or as if there is a one-to-one relationship between the two.


Related links: