Doing the Right Things — with Enterprise Architecture

When we want to sell something to a customer, a handful of things have to be true at the same time. The product has to do what the customer actually wants. It has to be good enough. The price must not exceed the value the customer gets from it. It has to be available quickly enough to matter. And there should be no comparable product that beats ours on any of these points.

Almost everything a company does is, in the end, in service of getting offers like that to market. So here is a fair question: how can Enterprise Architecture help make sure all of those conditions hold?

To answer it, I want to avoid the trap Enterprise Architects usually fall into. We love to talk in pictures. We ride the elevator between the top floor and the machine room. We are the city planners, while domain architects plan the districts and solution architects design the individual buildings. These images are nice, and because they are so abstract they are always a little bit true — which is exactly why they are useless when someone asks what we concretely do on a Tuesday morning. So let me walk through the concrete work instead.

Enterprise Architecture is not a role — it is the structure of the company

First, a definition that changes how you read everything below. Enterprise Architecture is not a person with “architect” in their title. It is the structure of the company: how business capabilities, processes, data, applications and technology fit together to pursue the company’s goals. That structure exists whether or not anyone tends to it. It is realised through many roles — product people, engineers, governance, security, and yes, sometimes a dedicated Enterprise Architect.

That means shaping the architecture is a shared task. The Enterprise Architect’s job is to take on the parts of that task that no other role is currently covering — connecting the goals at the top with the work in the machine room, so the two tell the same story.

The real problem: too many possible things to do

Here is where most initiatives quietly go wrong. It is rarely that a company has nothing to do. It is that it has far too much it could do, and no shared, explicit basis for choosing. Every department has a backlog. Every leader has a conviction. The list of possible activities is effectively infinite, and the budget is not.

So the job breaks down into four questions:

1. What are the company’s actual goals?
2. Out of everything we could do, which initiatives genuinely pay into those goals?
3. Which of those are feasible with what we have?
4. How do we implement the chosen few and know whether they worked?

A structured way to move through those questions already exists. In TOGAF it is called the Architecture Development Method, the ADM. I don’t apply it as a rigid ritual — a framework followed to the letter becomes a bottleneck, and the goal disappears behind the method. I use it as a checklist for thinking, and I keep an elevator pitch ready at every step for why the current work pays into the company’s goals.

Walking the cycle, with the goal always in sight

Imagine a company that has decided it wants to grow by wrapping a digital service around a product it already sells physically. That is the strategic intent. Now what?

Set the vision. We start by getting the mandate clear — who is sponsoring this, to what end — and by describing the target in a single picture leadership can recognise as theirs. If we cannot say in two sentences how this initiative supports a company goal, we stop here. That is a feature, not a delay.

Understand the business first. Before anyone talks about systems, we map the business capabilities the new service needs, and how they connect to the value the company delivers to its customers. This is where you find out that the exciting idea depends on a capability the company doesn’t actually have yet — much cheaper to learn now than after the build.

Then the information and application layer. What data has to flow, from where to where, and in what time? Which applications produce and consume it? Here we deliberately look for the smallest coherent slices — data products and services that teams can own — rather than one grand model everyone has to agree on before anything ships.

Then technology. Only now do we look at the technical foundation: platforms, infrastructure, the constraints that are real versus the ones that are merely habit.

Find the options and choose. With the gap between today and the target visible, we identify concrete initiatives to close it, and we prioritise them against each other — by contribution to the goal, by feasibility, by what unlocks what. The output is not a wish list; it is a sequenced set of the few things worth doing first.

Plan the migration, then govern the build. We turn the chosen initiatives into a roadmap and, crucially, stay involved while it is built — not as the people who overrule teams, but as enablers who keep the delivered thing pointed at the vision. An Enterprise Architect can be a requester, an enabler, or an overruler; enabler is the one that works.

Measure, and adapt. Finally we make the effect visible: did the initiative move the goal it promised to move? What we learn feeds straight back into the next turn of the cycle.

Why this is worth the effort

The payoff is simple, and it is the reason I do this work at all. When a company knows its goals and chooses its initiatives against them, it stops pouring time and money into directions that don’t matter. And it gets from an idea to a relevant offer in the market faster, because the energy isn’t spread across everything — it is focused on the things that count.

That is the whole point, and it is easy to state without any architecture vocabulary at all: figure out what is important, and make sure it happens.