System architecture and integration design

Architecture review

A review is worth doing at three moments: before a business commits budget to a build, when a system has started failing in ways nobody can explain, and when an acquisition or partnership means two estates have to work together.

We read the code, not just the diagram. Documented architecture and actual architecture diverge almost immediately, and the gap between them is usually where the problems live. We look at how data moves, where state lives, what happens when each dependency is unavailable, and which parts of the system everyone is quietly afraid to touch. That last one is the most informative signal on any engagement.

The output is a written assessment: what is sound and should be left alone, what is a genuine risk with an estimate of what it costs to leave it, and what is simply unfashionable but working fine. That third category matters, because review work that recommends replacing everything is not analysis, it is a sales pitch.

Integration design

Most operational pain in an established business is not inside any one system. It is in the gaps. Scheduling, stock, payroll and accounting each hold a fragment of the truth, reconciliation happens by hand, and nobody trusts a number until they have checked it against something else.

Integration design decides which system owns each fact, how the others learn about changes to it, and what happens when one of them is down or wrong. Consider a scheduling system that needs to reflect stock availability: you can query stock on every read and inherit its downtime, cache with a defined staleness window, or have stock publish changes that scheduling consumes. Those are three different failure modes and three different costs, and the right answer depends on how wrong the business can afford to be and for how long. What we will not do is pick one silently.

We also design for the integration failing, because it will. Retries with backoff, a clear position on duplicate delivery, reconciliation that can be run on demand, and enough logging that a disagreement between two systems can be settled from evidence rather than argued about.

Migration planning

Replacing a working system is mostly a sequencing problem. The technology is rarely the hard part; the hard part is getting from here to there without a period where the business cannot operate.

We plan migrations in stages that each leave you in a shippable state. New functionality goes in front of the old system behind a routing layer, traffic moves across a slice at a time, and the old path stays available until the new one has proven itself under real load. Data is migrated with a reconciliation step that proves nothing was lost, not with an assurance that nothing was lost.

Every stage has a way back. A migration that can only go forwards is a migration that turns a bad Tuesday into an outage, and the plan says explicitly what triggers a rollback so that decision is made calmly in advance rather than under pressure at the worst moment.

Trade-offs, written down

Every significant decision is recorded with the options considered, what was chosen, why, and what it will cost you later. This is the part clients tell us they value most, and it costs almost nothing to do at the time.

Two years on, the context has changed and somebody is asking why the system works this way. Without a record, the honest answer is that nobody remembers, and the team either preserves a constraint that expired long ago or removes one that is still load-bearing. Both are expensive. A short written record of the reasoning turns that into a decision instead of a guess.

Engagement shape

Reviews are short and bounded: a defined scope, a written report, and a session working through it with your team. Integration and migration design usually run longer and often continue into delivery, but they do not have to. If the plan is what you need and your own team can build it, that is a perfectly good place for us to stop.