Begin with a shared meaning
“Connect these two systems” sounds like a technical task. The difficult part is often agreeing on what the connection is supposed to mean.
Imagine an order moving from a customer portal into an operations system. Does “submitted” mean the customer clicked a button, the order passed validation, or the business accepted it? Each interpretation leads to different downstream behaviour.
Before discussing endpoints and payloads, write down the business event in plain language. Identify who owns it, what must be true when it happens and which teams depend on the result.
Distinguish a request from an outcome
A request to create an order and confirmation that the order exists represent different moments. Treating them as interchangeable can leave people with an inaccurate picture of the process.
For each step, agree on the expected outcome and how it will be communicated. Include the less convenient paths: validation failures, duplicate requests, delayed responses and requests that are accepted but not yet completed.
These decisions belong in the conversation with the business as well as in the technical design. They affect what a customer sees and what an operations team needs to investigate.
Make ownership visible
When a field changes, who is allowed to change it? If two systems disagree, which team resolves the disagreement? An integration can move data successfully and still leave those questions unanswered.
Define the source of truth for the information that matters. Be explicit about whether a receiving system stores its own authoritative record or a copy used for a particular purpose.
Keep these agreements close to the interface documentation so that a new engineer or business owner can understand the intent without reconstructing it from code.
Design the recovery conversation early
For a fictional shipment update, ask what should happen if the destination system is unavailable. Can the update wait? How will someone know it is waiting? What makes it safe to try again?
A useful design discussion follows one failed item through to resolution. It identifies the evidence an operator needs, the action they can take and how they can confirm that the process is back on track.
The aim is to avoid making recovery depend on one person who remembers how the original implementation works.
Choose technology after the behaviour is clear
Once the business meaning, timing and recovery needs are understood, it is easier to evaluate implementation options. Some interactions need an immediate answer. Others can continue while a downstream step completes later.
The integration should reflect that behaviour. A shared understanding of the process gives architecture decisions a purpose and gives testing something meaningful to verify.
At Condusit, we see integration as part of the business workflow. Moving data is one step; helping people trust what happens next is the outcome.
