An integration is not just a connection

When people talk about integrations, the conversation often starts with a simple question:

Can system A connect with system B?

It is a useful question, but it is rarely enough.

A technical connection is only one part of an integration. The real work is understanding what needs to move, why it needs to move, when it needs to move, and what happens when the flow does not work as expected.

Two systems can be technically connected and still create problems if the integration logic is unclear.

The data may exist, but not in the right format.
The API may be available, but not expose the right object.
The sync may work, but not at the right frequency.
The source of truth may be unclear.
The business process may depend on exceptions that were not discussed.
The support team may not know who owns the issue when something fails.

This is why I try to avoid treating integrations as a simple yes or no topic.

The better question is not only:

Can these systems connect?

It is:

What should this connection make possible, and what needs to be true for it to work reliably?

Start with the business flow

Before discussing endpoints, fields, or middleware, it helps to understand the business flow.

What is the user trying to do?
What action triggers the integration?
What should happen automatically?
What still needs human validation?
What is the expected result for the user, the business team, and the technical team?

Without this context, it is easy to design a connection that moves data correctly but does not actually support the real workflow.

A good integration is not only technically valid. It supports a business process that people can understand and operate.

Clarify the source of truth

Many integration problems come from unclear ownership of data.

If two systems store similar information, which one is authoritative?

For example:

Which system owns the customer record?
Which system owns the user status?
Which system owns permissions?
Which system owns transaction history?
Which system owns reporting data?

This matters because integrations often expose disagreements that already exist inside the organization.

If ownership is unclear, the integration may become the place where business ambiguity turns into technical complexity.

Understand timing and frequency

Not every integration needs to be real time.

Some data flows need to happen immediately. Others can be synchronized every few minutes, once per hour, once per day, or only after a manual validation step.

The important thing is to make timing explicit.

A team may say they need “automatic synchronization”, but that can mean different things to different people.

For one stakeholder, it means instant update.
For another, it means no manual export.
For another, it means the data is available before a weekly report.

These are not the same requirement.

Clarifying timing early avoids disappointment later.

Plan for failure

Every integration can fail.

An API can be unavailable.
A field can be missing.
A user can be duplicated.
A format can change.
A rule can be misunderstood.
A third-party system can behave differently than expected.

The question is not whether failure can be avoided completely.

The question is:

What happens when something fails?

Who is notified?
Where can the error be seen?
Can the process be retried?
Is there a fallback?
Who decides whether the issue is business, technical, or operational?

This is where integration design becomes operational design.

Make ownership visible

An integration usually sits between teams.

Business teams care about the outcome.
Product teams care about the user experience.
IT teams care about security, reliability, and maintainability.
External vendors care about what their product or API can support.

If ownership is not clear, the integration may work at launch but become difficult to maintain.

Someone needs to understand the flow, monitor it, explain it, and make decisions when the business changes.

This does not mean every integration needs a heavy governance model.

But it does mean that ownership should be visible before the integration becomes critical.

The real integration question

A connection between systems is only the beginning.

The real integration question is not only whether two platforms can exchange data.

It is whether the data flow supports the right workflow, with clear ownership, realistic timing, understandable failure handling, and a sustainable operating model.

That is why an integration is not just a connection.

It is a design decision about how work moves across systems and teams.