Architecture
Which platform, which boundaries, buy or build. The decisions that cost nothing today and a rewrite once software is live.
The decisions you cannot unmake cheaply
Most architecture decisions can be changed later. A handful cannot, or not without rewriting the thing you have just paid for. Where the boundaries between systems fall, what owns which data, whether you buy the thing or build it: those get made early, often in a hurry, and they set what is possible for years afterwards.
We help you make them with the trade-offs in the open. That means saying what each option costs, what it rules out, and what would have to be true for the other one to win. It is usually days of work rather than months, because the job is deciding, not building.
Then we write it down. Not a diagram nobody opens - a short document saying what was chosen, what was rejected and why, so the reasoning outlives the people who were in the room. The team that inherits the system gets the argument, not just the result.
One of our four consultancy limbs. The others are software delivery, business analysis and delivery diagnosis.
Four ways we get brought in
Most of this work starts as one of these. You don't need to know which before you talk to us.
Architecture review
We read the system, ask the awkward questions, and tell you which parts are expensive to change.
Target architecture design
What the system should look like when it is finished, in what order, and what keeps running throughout.
Buy or build assessment
Set against what each really costs over five years: licences, integration, the work you cannot outsource.
Integration and boundary design
Who holds which data, what happens when one side is down, and what the contract between them promises.
What we actually look at
Four questions, asked of every system. The answers are what the document ends up being made of.
- What this has to survive
- The load, the growth and the failure you are designing against, stated as numbers rather than adjectives. "Highly available" means nothing until somebody says how many hours a year the business can lose.
- Who owns which data
- Most integration pain is an ownership question nobody settled. When two systems both think they hold the truth about a customer, the reconciliation work never ends.
- What you already run
- An architecture your team cannot operate is a bad architecture, however good the diagram. What you have licences for, what your engineers know, and who gets the call at 3am all count as constraints.
- What happens if we're wrong
- Every decision gets a cost of reversal. The cheap-to-unmake ones can be made quickly and revisited; the expensive ones get the argument they deserve, in writing, before anything is built on them.
What lands on your desk
- The decisions, written down
- What was chosen, what was rejected, and the reasoning for both, in language your board can read.
- A diagram of the target
- With the boundaries and the data ownership marked.
- An order to build it in
- So the first phase stands on its own rather than needing all of it before anything works.
What it looks like when it works
A call-recording software vendor had won banking business its architecture could not sustain: a monolith that could not be scaled or made resilient enough for contracts already signed. A bigger server was not the answer.
| Item | Result | Notes |
|---|---|---|
| The call | Rebuild | a ground-up rebuild on event sourcing - keeping every change as a record rather than only the latest state - against a bigger server, which was the cheaper-looking option and would not have held |
| Availability designed for | 99.999% | about five minutes of downtime a year: the target the rebuilt platform was architected to, on banking contracts that were already signed |
| Simultaneous calls | Thousands | recording, storage and retrieval separated onto their own paths, so each scales without waiting for the others |
Our own most recent build made the same kind of call earlier and smaller. Putting a clean boundary between the on-truck capture and the operator's systems is what let it go from kick-off to live and load-proven in under four weeks - on a relatively simple installation, at a fixed scope and fixed price.
Common questions
Do you have to build it to advise on it?
No. Most of this work ends in a short document and a conversation, and some of it ends with us saying the answer is not a build at all. If you then want it built we can do that too, but the advice is not a way of selling you the build.
How long does an architecture review take?
Days rather than months. The work is reading, asking and deciding rather than writing code. Designing a target architecture for a system you are replacing takes longer, and how much longer depends mostly on how much of the current one nobody can explain.
We already have a diagram. Isn't that the architecture?
A diagram says what the system is. It rarely says what was rejected and why, which is the part the next team needs. If that reasoning is written down anywhere we will start from it, and if it isn't, writing it down is usually the first useful thing we do.
Buy or build - which do you normally recommend?
Buy, more often than people expect us to say. Building is right when the thing you do is the thing nobody sells you, and expensive when it isn't. We put the trade-off in the open rather than starting from an answer.
Can you review an architecture somebody else designed?
Yes, and that is most of this work. We are not looking for things to criticise. We are looking for the decisions that will be expensive to unmake, and whether the reasoning behind them still holds now that the system is real.