Integration
The chain is the easy end.
Connecting one to the systems a business already runs means joining two things with different ideas of when something has happened, different notions of undo, and different owners. Almost all of the difficulty lives in that seam rather than at either end of it.
The seam
Two systems, two definitions of true.
Enterprise systems and chains were designed under opposite assumptions. Every integration problem below is a consequence of one of these mismatches rather than a bug in either side.
One can roll back, the other cannot
A database transaction either happened or did not, and can be reversed by an administrator. A chain entry is a fact that stands, and the only correction is another entry. A design that assumes both can be undone together is a design that will eventually need a manual correction nobody planned.
One is instant, the other settles
A write to a record system is done when it returns. A chain write is provisional for a while. Bridging the two means the business process has to tolerate a state that is neither pending nor complete, and that state needs a name and a screen it appears on.
One has an administrator, the other does not
When an entry is wrong in a conventional system, someone with the right permission fixes it. On a chain nobody has that power, deliberately. Anything that depended on a quiet correction has to be redesigned as a compensating action recorded in the open.
One is private by default, the other is not
Internal systems assume their contents stay internal. Chains assume readers. What crosses the seam is decided explicitly, because the default of forwarding what is convenient publishes more than intended.
What it connects to
The systems actually on the other side.
In practice, four of them come up in nearly every engagement.
Resource planning and finance
Where the transaction already has a record, a document number and an owner. The chain entry has to be traceable to that record and back, or finance ends up maintaining a second view of the same events by hand.
Identity and access
People act through corporate accounts, not addresses. Mapping an employee to the authority under which a transaction was signed — and removing it when they leave — is identity work, and it is where most access mistakes are made.
Payments and settlement
An on-chain event and a bank movement are two records of one intention, and they fail independently. Which is the source of truth for the business, and what happens when only one occurs, is decided before either is wired up.
Reporting and audit
Auditors and regulators ask questions in the shape of a ledger, not a block explorer. The integration is not finished when data moves; it is finished when someone can answer a question about a transaction without being taught what a hash is.
How it is built
Patterns that survive the second year.
None of these are specific to blockchain. They are ordinary integration engineering, applied to a system that punishes shortcuts more than most.
A translation layer, deliberately
Chain concepts do not leak into the business system and business concepts do not leak onto the chain. One component owns the vocabulary in between, which is also the only place that has to change when either side does.
Intent is recorded before it is sent
The decision to submit is written down in your own system first, then submitted, then confirmed. That ordering is what makes the process recoverable when something fails between the two, because the record of what was meant survives.
Everything is idempotent
Retries are normal and a retry must never produce a second transaction. Each intent carries an identifier used all the way through, and a repeat of the same identifier is recognised rather than re-executed.
Events flow one way at a time
Two systems writing to each other in both directions produces loops nobody can trace. Each direction is a separate, explicit flow, with a stated rule for what to do when both change the same thing.
The queue is not optional
The chain will be slow or unreachable sometimes. Work is queued and retried with backoff rather than attempted inline, because an integration that fails when the network is busy will fail when it matters.
What goes wrong
The failures worth designing for.
These are the ones that happen, not the theoretical ones. Each has an answer decided in advance rather than discovered during an incident.
One side succeeded, the other did not
The most common failure in the seam. Either the business record exists with no chain entry, or the reverse. Both are detected by reconciliation rather than by someone noticing, and both have a defined correction.
The same thing was sent twice
Usually a retry after a timeout where the first attempt actually succeeded. Prevented by identifiers carried end to end, and caught by reconciliation when prevention fails.
The record drifted
Two systems that agreed at launch diverge quietly over months, usually through a manual correction on one side. This is why reconciliation runs on a schedule rather than only after an error.
Nobody can explain a transaction
A year later, finance asks why an entry exists and the only answer available is a hash. Traceability from business record to chain entry and back is part of the build, not a reporting request afterwards.
An integration is finished when someone in finance can answer a question about a transaction without calling engineering.
Reconciliation
The part that is never a phase.
Two systems holding a view of the same events will disagree eventually. Reconciliation is not a migration task; it is a permanent feature of the integration.
It runs on a schedule, not on suspicion
Comparing both sides regularly and reporting differences is what turns a silent drift into a ticket. The value is in the runs that find nothing.
A difference is a workflow, not an alert
Someone is named, a queue exists, and there is a defined way to resolve each category of mismatch. An alert with nowhere to go is ignored within a month.
Corrections are recorded as corrections
Not as edits. The original entry, the compensating action and the reason all remain visible, because that is what an auditor is asking to see.
It is tested by breaking things on purpose
Failures are injected into each side and the reconciliation is checked for whether it actually catches them. Reconciliation that has never found a real difference has not been shown to work.
Questions
The ones worth asking first.
Do we have to replace our existing systems?
No, and proposals that start there are usually solving the supplier’s problem rather than yours. The resource planning system stays the system of record for the business. The chain holds what genuinely benefits from being shared and provable, which is normally a small part of what the business system holds.
Which system is the source of truth?
That is a decision, not a discovery, and it has to be made per data type rather than once for everything. For most integrations the business system remains authoritative for commercial detail while the chain is authoritative for what was agreed and when. Leaving it unstated is what produces two years of quiet drift.
What happens when the chain is slow or unavailable?
The business process continues and the chain work queues. Anything that stops a warehouse or a finance close because a network is congested has been designed with the dependency in the wrong direction. Which operations may proceed unconfirmed is agreed explicitly.
How do we correct a mistake that is already on the chain?
With a compensating entry, recorded openly, referencing the original. There is no quiet edit, and designing as though there might be is the most common source of unpleasant surprises. The correction path is designed before go-live, because mistakes are certain.
Is this the same as system integration generally?
The engineering discipline is the same — translation layers, idempotency, queues, reconciliation. What differs is that one side is unforgiving: no administrator, no rollback, and a public record of every error. That removes the escape routes ordinary integrations rely on.
Who operates this afterwards?
The integration is a running system with a queue, a retry policy, a reconciliation schedule and a failure workflow. Treating it as a project that finishes at go-live is how it becomes the thing nobody understands two years later. We would rather agree who operates it as part of the engagement.
Tell us what has to stay in step.
Describe the systems on both sides and which of them the business treats as authoritative. If the answer is that nothing needs to reach a chain, you will hear that instead of a proposal.
info@eorbitt.com · We reply within one business day.