Most of us wouldn’t set off on a long road trip without some idea of where we were going.
We’d probably know the destination, look at the route, check whether there were roadworks, closures or diversions. We might work out where to stop, how long the journey should take and whether the car actually had enough fuel to get us there.
These days of course we outsource a lot of that thinking to Google Maps (or your chosen alternative). But the principle hasn’t changed.
Before we start moving, we want to understand where we are, where we're trying to get to, and what lies between the two.
But so often we attempt significant business change, strategy development, or even just system or process refreshes without a clear picture of any of this. Without a map.
It's the difference between looking out of the windscreen of your car vs only knowing where you are after it appears in your rear view mirror.
Businesses commit significant amounts of money, time and attention to transformation; new platforms, new operating models, new partners, M&A, automation, AI, etc. Lots of movement, but often no reliable map…
An organisation is a system of systems
The larger an organisation becomes, the harder it is to see as a single thing.
What we call “the business” is really a collection of interconnected systems.
People perform processes – Processes depend on technology – Technology creates and consumes information – Teams use information to deliver capabilities – Capabilities depend on people, processes, data and systems – and so on…
The problem is that, as organisations grow, those systems rarely grow neatly in sync with one another.
- A new platform arrives because the old one couldn’t do something.
- A team creates its own process because the central process doesn’t quite work for them.
- An acquisition brings another set of applications and suppliers.
Individually, each decision may have made sense, but the reality and complexity of an organisation isn’t simply a question of how many things it contains; it comes from the relationships between them… And those relationships are very easy to lose sight of.
The problem isn't always complexity. It's invisible complexity.
Most large organisations know quite a lot about themselves. They probably have inventories of technology, know what they’re paying suppliers, how many people they have working on different areas, how successful their products are, etc.
So there’s no shortage of information… But there’s often a shortage of knowledge.
- Knowing where data is stored doesn’t tell you how important that data is, who relies on it or what it impacts if it’s wrong.
- Knowing what a supplier provides doesn’t necessarily tell you what else would be affected if that supplier disappeared tomorrow.
We can know an enormous amount about the individual pieces and still struggle to answer a much simpler question; how does all of this fit together?
Enterprise Architecture is the map
Enterprise Architecture can sometimes sound like something that belongs deep inside the technology function. But I believe pigeon-holing it as a technology sub-concept dramatically underplays what it can do.
At its most useful, Enterprise Architecture gives us a model of the organisation. A digital twin that aids with decision making and development around Strategy, Transformation, Risk, Finance, HR, and your fundamental Operating Model.
Paired with the right tooling to make it easily accessible and visual, it is the way to connect what we are trying to achieve with the capabilities we need, the processes we perform, the information we use, and the technology that enables it.
It helps us understand not just what we have, but why we have it and how it relates to everything else.
This matters, because the value isn’t really in producing the map… The value is in the questions the map allows us to both ask and answer.
- What are we doing?
- How are we doing it?
- Why are we doing it?
- Do we have what we need to achieve our goals?
- Does what we have actually work together in the way we need it to?
- Where are the gaps?
- Where are we duplicating effort?
- What depends on what?
- And can we confidently change any of it?
Those are not architecture questions in the narrow sense. They’re business questions.
Transformation is changing a live system
This all becomes particularly important when we start changing things. Transformation programmes are, by design, interventions in a system.
- Change the technology and you may change a process.
- Acquire a company and suddenly two sets of processes, applications, data, suppliers and organisational structures need to coexist or become rationalised.
- Introduce AI and you quickly discover that the interesting questions aren’t only about the model; they’re about the data feeding it, the processes surrounding it, the controls governing it and the liability around its output.
Pull one thread and something moves elsewhere.
The effort required to create just a basic view of your enterprise architecture can (and more than likely will) pay off multiple times across multiple aspects of your business.
Suddenly you can see the system of systems. You can:
- De-risk change
- Consolidate cost
- De-duplicate processes
- Simplify your architecture
- Answer business continuity and regulatory questions
- Build practical governance, not general policy
- And so much more…
If we’re making significant changes to a complex, interconnected system, wouldn't we want a model of that system before we started?
You wouldn’t deliberately close a major road without understanding where the traffic will go instead… Yet organisations can sometimes replace applications, redesign operating models, or launch major programmes without a sufficiently clear view of the dependencies underneath them.
The map isn't the destination
There is an important trap here –> Enterprise Architecture can become an end in itself… More modelling, more diagrams, more repositories, more documentation… Eventually the organisation may produce a beautifully detailed description of itself that relatively few people use. That isn’t success.
Google Maps is useful because it helps us travel. Enterprise Architecture should do the same. It should:
- Help leadership teams understand the organisation they are running
- Help transformation teams see dependencies before they trip over them
- Help technology teams understand the business context around the systems they manage
- Give everyone involved a common way of understanding the landscape
The real goal is a living model of the enterprise. Something good enough to tell us where we are, how the parts connect, and what is likely to happen when we make a change. Not perfect, but practical and useful.
Organisations will continue to change, new people and technology will arrive, strategies will evolve, companies will acquire other companies, new regulations, products, suppliers and opportunities will appear. We can’t remove that complexity; nor should we necessarily want to. But we can make it more visible.
A useful Enterprise Architecture should help us answer four things
I don’t think the goal should be to model absolutely everything.
The model has to help people make decisions. For me, that means it should help us answer four broad sets of questions:
1. Purpose: What are we actually trying to do?
This gives everything else context. Without that context, we’re effectively mapping roads without knowing the destination.
- What outcomes are we trying to achieve?
- What capabilities do we need to achieve them?
- Why do particular processes, technologies and information assets exist and (how) do they serve the need?
2. Coherence: Does what we have actually work together?
A good map exposes not just the components, but the relationships. That’s usually where the useful conversations begin.
- What systems, processes, information and capabilities do we have today?
- Where are the overlaps?
- Where are the gaps?
- Where have we built the same capability in different ways?
- Where are the key dependencies?
- Where are the blind spots?
3. Readiness: Do we have what we need for where we're going?
This is where architecture moves from modelling the present, to helping us reason about the future.
- Today’s organisation may work perfectly well for today’s needs. That doesn’t mean it’s ready for tomorrow’s.
- If the strategy changes, can the operating model support it?
- Is the information available?
- Can the technology support the change?
- Where will investment actually make a difference?
- Where will inaction become a risk?
4. Change: What happens if we alter the system?
These sound like simple questions, but they rarely are. Modelling them before the change is usually a lot cheaper than discovering the answers afterwards.
- If we replace this platform, what depends on it?
- If we introduce a new partner, where do they plug in?
- If we acquire another business, where are the points of overlap?
- If we automate this process, what happens upstream and downstream?
- If we retire this application, who notices?
So whether you’re about to spend the next few years trying to transform a business, or just the next few months planning how to get the most out of it, perhaps one of the simplest questions we can ask first is this:
How confidently could you draw the map?
If you are planning significant change but cannot clearly see how your capabilities, processes, data and technology connect, we can help you build the view you need to move forward with confidence.
Footnote
One area this is becoming increasingly valuable (and critically important in many cases) is the proliferation of AI deployment across businesses.
I won’t go into the details of the benefits of ontologies and knowledge graphs here – of which there are many and I’m also a huge advocate of for both human and AI context mapping – but I will touch on the the rising discipline of encoding your organisational context.
Two things being learnt rapidly with AI deployment are that 1) humans take organisational context for granted, and 2) organisational context is not consistent or common knowledge across an organisation.
This means that when we deploy AI Agents or GPTs, they often do not have the context required to make what we would consider sensible judgements in the context of the business.
Providing your AI access to your business context (Enterprise Architecture / Ontology / Knowledge Graph for example) has been proven to dramatically increase the contextual accuracy and usefulness of outputs.
Imagine hiring a new intern – super bright, rapid research ability, but with no organisational context of what goes where, who does what and which processes, teams and systems rely on each other – and asking them to trawl through SharePoint and make business transformation recommendations. You decide how you think that will likely go…
Common questions about Enterprise Architecture
What is enterprise architecture?
Enterprise architecture is a model of how an organisation’s capabilities, people, processes, information and technology connect. It helps you understand not only what the organisation has, but why it exists, what depends on it and how the wider business may be affected when something changes.
Why is enterprise architecture important for business transformation?
Business transformation changes a live, interconnected organisation. Enterprise architecture makes the relationships and dependencies within that organisation more visible, helping teams assess the potential consequences of replacing technology, redesigning processes, acquiring another business or changing the operating model before decisions are made.
What should an enterprise architecture help an organisation understand?
A useful enterprise architecture should help an organisation understand four things:
- What it is trying to achieve
- Whether its existing capabilities work together
- Whether it is ready for future needs
- What may happen when part of the organisation changes
Does enterprise architecture need to model everything?
No. The purpose of enterprise architecture is not to create a perfect description of the entire organisation. It should provide enough reliable context to support decisions, expose important dependencies and help people understand how proposed changes could affect other parts of the business.
How can enterprise architecture support AI?
Enterprise architecture can give AI systems more of the organisational context they need to produce relevant and consistent outputs. It shows how business concepts, data, systems, processes, responsibilities and capabilities relate, helping AI interpret information within the context in which the organisation actually operates.
Lawrence Hill
Senior Consultant and Data Strategy Lead, Ortecha
Jump to a section
- Introduction
- An organisation is a system of systems
- The problem isn't always complexity. It's invisible complexity.
- Enterprise Architecture is the map
- Transformation is changing a live system
- The map isn't the destination
- A useful Enterprise Architecture should help us answer four things
- Next steps
