Start with a business case, not a connector catalogue
Trace one real case from creation to completion. Record who creates it, where its identifier originates, which information changes and what a person must see at the end. Then mark the systems through which it passes. This journey reveals which connections matter and where information currently disappears. A list of available APIs alone cannot explain why the customer sees a different status from the operator. Include manual exports, batch jobs and corrections in the map; they may be just as important to operations as automated interfaces. Observe exceptional cases, because an integration that works only for the usual path is incomplete.
Every field needs an owner of its meaning. CRM may hold the commercial contact, accounting the amount due and the operations application the fulfilment state. If a value is written in several places, name the authoritative source and the rule for changing it. Otherwise the integration layer merely spreads disagreement faster. Define how fresh each piece of information must be: some facts need confirmation before work continues, while others can arrive minutes later. That requirement determines the communication style and a measurable promise to the user. Record who resolves a mismatch when sources conflict.
Choose direct calls and messages according to the cost of waiting
A synchronous API fits when the user needs an immediate result and the other system can answer within an agreed time. The caller also inherits the dependency on that system's availability. A long chain of direct calls can stall the entire process because one link is slow. Specify timeouts, retries and an understandable response during an outage. Not every retry is safe: repeating the creation of a payment differs from reading a status again. Make the decision for each operation rather than applying one rule to every endpoint. Show the user a pending state when a final result cannot yet be confirmed.
An asynchronous message fits when the recipient can process work later and the sender need not wait. Microsoft explains that a broker can retain a message through a communication failure and redeliver it. Design consumers for duplicates and ordering. Sent does not mean processed. Users should be able to see acceptance, progress and failure, with a path to correction. An event describes something that happened; a command asks for an action. Confusing those meanings makes ownership and error handling harder. Decide which system can reject a command and how that rejection will return to the person who initiated the case.
Make the data contract survive change on either side
For each interface, define the case identifier, required fields, time and amount formats, state meanings, error responses and compatible changes. Examples of real messages uncover ambiguity better than a general architecture picture. State the currency and rounding rule for money, and the time zone and source for timestamps. Version an interface when its meaning changes, not for every internal refactor. Consumers need to know which fields they may ignore and which new state value requires action. A contract also includes a contact for resolving disputed data and a process for announcing changes before a release.
Test both sides of the boundary. The producer checks that it emits the agreed structure and meaning; the consumer checks that it handles allowed variations and absent optional fields. When the data model changes, provide a transition period and announce the retirement of an old version. Samples must not contain sensitive production data without authorization. Passing schema validation is still insufficient: two systems can use a field with the same name but different business meaning. A process owner, rather than only the development team, has to settle that disagreement. Capture the decision in the contract so future teams do not repeat it.
Treat duplicate and stranded messages as ordinary conditions
When a failure occurs between sending and acknowledgement, the sender cannot always tell whether the recipient performed the operation. The design therefore allows retries. Give each modifying operation a stable identifier with which the recipient recognizes repeated delivery. Microsoft includes an idempotent consumer among its reliability patterns for systems that may deliver a message more than once. For payments or reservations, checking whether the last HTTP request is in memory is insufficient; evidence must survive a restart and connect to the business operation. Retry rules also differ between a transient fault and invalid input data.
Move messages that cannot be processed to a safe investigation path with the reason for failure and a link to the original case. Do not repeat indefinitely an error only a person can repair. After correction, processing should restart without creating another obligation or losing the audit trail. If a flow changes several systems, define a compensating action for a later failure. Compensation is not always deletion: financial or audit records may require an opposite, traceable operation. Test these paths before release with a disconnected destination, an expired credential and a duplicate delivery.
Observe the case across system boundaries
A single service log cannot explain the whole process. Use a case identifier and a correlation identifier that travel through calls and messages. OpenTelemetry describes context propagation between processes as a basis for connected traces. Record start, finish, waiting time and a safely redacted error reason for each step. Monitoring should answer practical questions: where did the case stop, was a duplicate created and who owns the next action? Do not place sensitive records into diagnostics simply because they appear in a payload. Make access to operational details proportionate to the support role.
Alongside technical metrics, track cases finished on time, manual corrections, messages waiting longer than their limit and differences in control totals. Assign an owner and an action when a threshold is crossed. Daily reconciliation can compare expected and actual states, including cases that left the normal path. The operational view should let a team open a specific problem, repair it safely and record what changed. Without that loop, even a technically correct integration can produce invisible losses. Use the measurements to decide whether the next part of the process is ready to move.
Introduce boundaries gradually and account for their operating cost
A first delivery should cover one valuable flow, its data contract, failure scenarios and operational view. The test environment should simulate an unavailable counterpart, delayed response, duplicate and changed order. Production rollout can be divided by case type or user group. Before expansion, compare throughput, errors and manual work with the old process. If both paths run at once, clearly identify which one may write. Otherwise a pilot creates data that cannot be reconciled unambiguously. Keep a return plan for the period when the two paths coexist and verify it in a rehearsal.
EXCOIN can deliver an integration map, data contracts, one implemented flow and a monitoring plan. Availability or savings cannot be promised without knowing the connected systems and their operational limits. More boundaries bring more versions, permissions and failure states that someone must maintain. Choose the smallest architecture that meets the reliability need: sometimes a direct API, sometimes a queue or events, often a combination. The measure of success is a traceable case and fewer manual corrections, not the number of connectors. Agree who will operate each boundary after the initial delivery.