Start from ownership, not technology
Before any middleware is drawn, one question decides most of the architecture: for each piece of data, which system owns it? Where ownership is ambiguous, integrations multiply the ambiguity — every connected system inherits the contradiction and shares it faithfully with the others.
A written ownership map, agreed by the people who run the processes, is unglamorous and indispensable. It turns ‘which system is right?’ arguments into design decisions made once, in advance.
Design the failure modes on purpose
Interfaces fail: networks partition, APIs change, messages arrive twice or not at all. Integrations that ignore this fail quietly and corrupt data politely. Every interface we design answers, in writing: what happens when the other side is down, what guarantees ordering, and how duplicates are detected.
Idempotency, retries with backoff, dead-letter handling and reconciliation reports are not gold-plating. They are the difference between an integration you can trust and one you merely hope with.
Migrate like you expect to be audited
Data migration deserves the same discipline as financial reconciliation: mapping documents, dry runs on production-scale copies, counts reconciled between source and target, and a rollback that has actually been rehearsed — not just written.
Phasing matters as much as tooling. Moving one bounded domain at a time, with a stability window after each, keeps the organisation operational and the risk legible.
Prefer boring interfaces
The most maintainable integration is usually the dullest one: a documented API with versioned contracts, or a well-defined file exchange with a schema and a schedule. Clever real-time plumbing earns its complexity only when the business genuinely needs seconds — most do not.
This is the standard we apply in enterprise systems and integration work: structured, tested, owned — and deliberately unromantic.