Systems Change.The ContractHas To Hold.
Two systems that both work can still be wrong together. Ronexer engineers the boundary between them — what may be sent, what it means, what counts as received — so data, commands and events stay understandable when vendors and conditions change.
Next Step / Technical Discovery
- Versioned, and owned by a named side
- Traceable from sent to accepted
- Isolated behind a boundary we own
- Reconciled, never assumed
Why integrations fail after the demo works
The demo is the easy half: one message, one path, both systems healthy. These four are the second year, and none appears in a proof of concept.
- 01
The call that succeeded twice
The first attempt timed out, so it was sent again — and the receiver had already processed it. Two refunds exist and neither side can tell. A message carrying its own identity is applied once however often it arrives.
- 02
Both systems believe they are right
The CRM says active, billing says cancelled, and something told each of them so. Declare one side the owner of that fact and disagreement becomes a detectable condition rather than an argument.
- 03
A vendor shipped a change nobody negotiated
A field became optional, an enum gained a value, an endpoint began paginating. A version and a compatibility window turn that into a scheduled change rather than a Monday outage.
- 04
The failure was recorded and nobody read it
The exchange failed, a log said so, and the systems drifted for six weeks until finance noticed. Failures that matter surface as state somebody owns, not as lines nobody searches.
What Ronexer takes responsibility for
Six responsibilities, each with the artefact it produces. An integration whose only artefact is working code cannot be changed once its authors leave.
- 01
Contract and schema design
The shape, meaning and compatibility rule of each exchange, agreed before either side builds against it. Produces a versioned contract, not a sample payload in a ticket.
- 02
API and event boundaries
Where a request and its answer are right and where an event is — decided on who needs to know, not on what a vendor exposes. Produces an interface inventory with an owner.
- 03
Identity and permission propagation
The caller's identity travels with the call, so the receiver applies its own rules rather than trusting a service account permitted to do anything. Produces an authorisation model that survives audit.
- 04
Delivery guarantees
Message identity, deduplication and acknowledgement, so a retry is safe and a timeout is not an unknown. Produces a stated guarantee per exchange, not an assumption held by one team.
- 05
Reconciliation and recovery
The scheduled comparison that finds divergence, and the way back: replay, correction, or a case for a person. Produces a reconciliation design and an error taxonomy.
- 06
Observability and operational ownership
What was sent, received, accepted and where it stopped, with a runbook naming who acts. Produces an operational model that is handed over, not retained.
What a contract has to say
A payload that validates can still be wrong. The schema states what may be sent; it does not state who owns the fact, what the receiver promised by accepting it, what the second attempt should do, or which side may change first. Those are the parts that decide whether an integration survives.
Meaning
What a status actually denotes, in both parties' terms. Two systems can pass a valid field for a year while quietly disagreeing about what it says.
Ownership
For every fact, one system may change it. The others hold a copy with a known staleness — and, more importantly, know that they hold a copy.
Version
Which version is in force, what may be added without breaking anyone, and how long the previous one is honoured. Compatibility is a promise with a date.
Ordering
Whether the receiver may rely on sequence, and what it does when a later fact arrives first. Most assume; few write it down, and fewer test it.
Acknowledgement
Accepted, queued, processed and committed are four different promises, and a 200 response distinguishes none of them. The contract says which was made.
Timeout
A call that does not answer has not failed — it is unknown. The contract says what the sender may do next, and what the receiver guarantees if it did arrive.
What happens when it fails
Every integration fails eventually: a dependency is down, a message is malformed, a network forgets. That is not the problem. The problem is two systems disagreeing afterwards and nobody finding out until a customer does.
- The same message arriving twice produces one effect, because identity travels with it and the receiver remembers what it applied.
- A later fact arriving first is held or discarded on a stated rule, rather than applied over something newer.
- An unanswered call becomes a case with a resolution path, not an assumption that it failed.
- The caller degrades along a declared path rather than retrying until it becomes the second outage.
- What cannot be processed leaves the queue for somewhere a person looks, with enough context to decide.
- Scheduled comparison finds what drifted, and replay or correction brings it back, with a record of both.
Connecting the estate you already have
No estate was designed. It accumulated: an ERP older than most of its users, a CRM a department chose, a payment provider whose contract renews in March. Integration work starts by accepting that and deciding where the boundary goes.
Usually that boundary is an adapter we own rather than a shared model everyone must adopt — worth its cost when several systems share a domain, an expensive detour when two do not. What matters more is that a vendor's shape stops at our edge, so replacing them is work in one place.
What changes operationally
- Sending the same instruction twice produces one business effect, so recovering after an outage is a re-run, not an investigation.
- A change to what a system sends arrives as a dated notice with a compatibility window, not as an incident the morning it ships.
- When two systems drift apart, something scheduled notices before a customer does, and the way back is designed, not improvised.
- Their shape stops at a boundary we own, so changing provider is work in one adapter rather than in every consumer.
Related pages
Bring an integration nobody will touch, a vendor migration that keeps being postponed, or two systems disagreeing since a release nobody can identify.