Archives

Two teams build the same feature list and ship completely different systems — because the non-functional requirements, not the features, decide the shape.

I wrote off enterprise architecture as big-company ceremony — until a greenfield rewrite with no governance changed my mind, and not the way vendors would like.

Contract testing lets you decouple deploys by sharing a spec, not a code package — each side proves it honours the contract on its own, without the other running.

You split into services so each could ship alone. Then a shared contracts package quietly stitched the deployments back together — that's deployment coupling.

Deferring a decision isn't dodging it. The last responsible moment is the point past which waiting costs you an option — so decide then, not before, not after.

Taught that duplication is the enemy, we abstract too early. But the wrong abstraction costs more than the duplication it replaced — and is far harder to undo.

An architecture fitness function turns a design rule from a wish into a test that fails the build when it's broken — and the best ones steer, not just forbid.

There's no 'right' architecture to find and lock in — only one that fits the forces on you now. The real job is keeping it able to change when they shift.

The decision is the cheap part; the reasoning behind it is what evaporates. Architecture decision records are a small, deliberate defence against that loss.

An anti-corruption layer is sold as a wall against a vendor's mess. It's really a double-sided socket — the same seam lets you swap either side independently.

Drawing module boundaries where the business already cut them assumes the business decided where. Often it hasn't — and that unmade decision is the architect's job.

The microservices-versus-monolith war is tired. The systems I've actually shipped are usually a bit of both — and on purpose.

Every time you turn a function call into a network call, you start paying a tax. Worth it sometimes — but know the bill before you sign up.

The two ideas from Domain-Driven Design you can actually use on Monday — where to draw your boundaries, and what you can change in one go.

The cheapest insurance against someone else's mess leaking into your codebase — and why changing payment vendors three times didn't hurt.

Not every decision deserves the same agonising. The trick is telling two-way doors — the ones you can walk back through — from one-way doors you can't.

Conway's Law in practice: your system will look like your org chart whether you like it or not — the only question is whether you planned for it.

We obsess over making things easy to add. The systems that age well are the ones where things are easy to remove.

The most honest two words in architecture — why every decision is a trade-off, and the real skill is finishing the sentence.

Why I've finally got round to starting a blog, and what I plan to write about here.