Doing the Right Things with Enterprise Architecture

When we want to sell something to a customer, several things need to be true at the same time. The product has to do what the customer wants, and it has to be good enough. The price must not be higher than the value the customer gets out of it. The product has to be available quickly enough, and there should be no comparable product which is better in any of these aspects.

Almost everything a company does serves the purpose of bringing such offers to the market. So the question I’d like to answer in this article is: how can Enterprise Architecture help to make sure all these conditions are met?

We Enterprise Architects love to explain our job with 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. I like these pictures, and as they are very abstract, they are always a little bit true. Yet, they don’t help much when someone asks what we do on a normal Tuesday morning. Therefore I will go through the concrete work instead.

Enterprise Architecture Is the Structure of the Company

Let’s start with a definition, as it influences everything which follows. When I talk about Enterprise Architecture, I mean the structure of the company and not a person with “architect” in the job title: how business capabilities, processes, data, applications and technology fit together, so that the company can reach its goals. This structure exists whether someone takes care of it or not, and it is shaped by many roles like product people, engineers, governance, security and, yes, sometimes a dedicated Enterprise Architect.

This means that shaping the architecture is a shared task. The job of the Enterprise Architect is to take on the parts of this task which no other role covers at the moment, and to connect the goals at the top with the work in the machine room, so that both fit together.

Too Many Things You Could Do

Companies rarely have the problem that there’s nothing to do. They have far too many things they could do, and no common and explicit basis for choosing between them. Every department has a backlog and every manager has convictions, so the list of possible activities is more or less endless, while the budget is limited.

So the job can be described by four questions:

What are the goals of the company?
Out of everything we could do, which initiatives support these goals?
Which of them are feasible with what we have?
How do we implement the selected few, and how do we know if they worked?

You can think of this as a funnel:

There is already a structured way to work through these questions. TOGAF calls it the Architecture Development Method (ADM). I don’t follow it to the letter, as a framework which is applied too strictly becomes a bottleneck, and at some stage people care more about the method than about the goal. I use it more as a checklist for my own thinking, and in every phase I try to have a short explanation ready for why the current work supports the goals of the company.

Walking Through the Phases

Let’s say a company sells bicycles online and in local stores, and it wants to become the one-stop shop for cyclists. Therefore it plans to add services around the bike: insurance, its own workshops and a tracker for the bike. This is the strategic intent. What happens next?

Vision

We start by clarifying the mandate (who sponsors this, and for which purpose?) and by describing the target in a single picture which management recognizes as its own. If we aren’t able to say in two sentences how this initiative supports a goal of the company, we stop here. This may feel like a delay, but it’s much better to find this out now than later.

Business

Before anyone talks about systems, we map the business capabilities the new services need, and how they are connected to the value the company delivers to its customers. Quite often you find out at this stage that the exciting idea depends on a capability the company doesn’t have yet.

Let’s have a look at the tracker. The idea is that the company knows how much a bike is used and when it needs a service or new parts, sends a message to the owner by email or in the app, and offers an appointment in the workshop or the right parts, which can be bought online or in the local store. A company which has only been selling bicycles so far is missing several capabilities for this:

It has to receive the data from the trackers and integrate it with its other services.
It needs a view of the customer which combines the tracker data with the service history from the workshops, the bike information from the customer profile and the purchases in the online store.
It has to decide what the best next step for this customer is: which product or which proposal should be offered?

All of this is data and integration architecture which has to be planned for the whole company, security included, as it concerns the online store, the local stores, the workshops and the customer profile at the same time. Learning this now is much cheaper than learning it after the solution has been built.

Information and Applications

Which data has to flow from where to where, and how quickly? Which applications produce and consume it? Here we look for the smallest slices which make sense on their own, e.g. data products and services which can be owned by a team, so that we don’t need one big model everyone has to agree on before anything can go live.

Technology

Only now do we look at the technical foundation: platforms, infrastructure, and the constraints. Some of these constraints are real, while others only exist because things have always been done this way.

Options and Selection

Once we see the gap between today and the target, we identify concrete initiatives which close it, and we prioritize them against each other: by their contribution to the goal, by feasibility, and by which initiative is a precondition for others. The result shouldn’t be a wish list, but a short list of things worth doing first, in a defined order.

Migration Planning and Governance

We turn the selected initiatives into a roadmap and stay involved while they are being implemented. An Enterprise Architect can act as a requester, as an enabler, or as someone who overrules teams. I would say the enabler role is the one which works best, as it helps the teams to keep the solution aligned with the vision without taking the decisions away from them.

Measure and Adapt

Finally we make the effect visible: did the initiative move the goal it promised to move? What we learn here is the input for the next round.

Conclusion

When a company knows its goals and selects its initiatives based on them, it stops spending time and money on things which do not matter. And it gets from an idea to a relevant offer in the market faster, as the energy is focused on fewer things.

You can describe this without any architecture vocabulary, too: figure out what is important, and make sure it happens.