Enterprise and software architecture: the value of a plan that is not code

Architecture is the list of decisions that are expensive to change later. Which is why they are worth writing down while they are still cheap — before anything is built.

Most companies already have an architecture. Nobody wrote it: it emerged from dozens of small decisions that each made sense at the time. The problem only shows when one system has to be replaced and it turns out four others indirectly hang off it.

Two levels that get confused

Enterprise architecture answers how the business runs and which systems support which process. It speaks the language of the business: order, return, stock.

Software architecture answers how one particular solution is built — of what parts, how they talk and where the boundaries are. It speaks the language of technology.

Without the first, you get software that solves the wrong problem very well. Without the second, you get a solution that cannot be extended a year later without a rewrite.

What architecture actually decides

• Where the boundaries are. What belongs in which system and what must never spread across them. A boundary that is not written down blurs within a year.
• Who owns which field. The same decision that keeps integrations sane — but made once for the whole company rather than separately at every connection.
• What may change without agreement. The inside of a component, yes; the contract between components, no. Without that line every change becomes a meeting.
• What survives a change of supplier. This is the question that reveals whether an architecture exists or was only drawn for the proposal.

TOGAF and ArchiMate — and why they matter

TOGAF is a method describing the procedure: how to map the current state, how to describe the target one and how to plan the route between them. ArchiMate is a notation — an agreed way of drawing it so that it means the same thing to everyone.

We document architecture in line with TOGAF and model it in ArchiMate. The reason is practical rather than formal: output in an agreed notation can be read by another supplier, and by your own team three years from now. A private drawing style is legible exactly as long as its author still works there.

That does not mean every project needs a full formal model. For a small solution, a few pages and one diagram is the proportionate output. The method tells you what not to forget — not how much paper to produce.

When architecture is worth it

Not always. For the first version of a product still looking for its shape, detailed architecture is a brake — the decisions rest on assumptions that will be proven wrong within a month.

It pays off when at least one of these is true:

• There are more than a couple of systems and they hand data to each other.
• Something the business runs on is about to be replaced or migrated.
• More than one team or more than one supplier will work on it.
• The decision is hard to reverse — a platform, a data model, a way of integrating.

How we do it

We start with the current state, not the target. We map what runs, who uses it and where data flows — including what is handled manually and appears in no official documentation. Only then is it worth talking about the destination.

The gap between today and the target becomes a sequence of steps ordered by impact and risk, so you can start with what pays back most and breaks least. Decisions with consequences are recorded together with the options we rejected and why — that is precisely the part somebody undoes in good faith a year later if it is not written down.

If you are weighing a larger change and want an independent view of it first, get in touch. We can do an architecture review without doing the delivery that follows — more on our services page.