A product can be elegant in isolation and still fail inside the operation. If it cannot receive trustworthy data, respect existing responsibilities or return a usable result to the right place, its internal quality will not rescue it.
This is why integration belongs in product discovery. It changes what the system should do, which states it needs to represent and how users experience success and failure.
Map the system of record
Complex organisations rarely have one source of truth. They have sources of truth for particular facts: an asset register, identity provider, case-management platform, maintenance system, data warehouse and a collection of local tools that fill the gaps.
The useful question is not “what data can the API return?” It is “which system is authoritative for this decision, at this point in the workflow?” Without that answer, teams create silent duplication and make reconciliation someone else’s problem.
Every interface creates a promise about meaning, timing and ownership.
Design the contract, not just the connection
A technical connection moves bytes. An operational contract defines what those bytes mean. It covers identifiers, required fields, valid states, update frequency, versioning, permissions and what happens when either side is unavailable.
Good contracts are narrow enough to understand and strong enough to monitor. They make failure visible. They also create room for systems on either side to change without turning every release into a coordinated emergency.
Exceptions are part of the interface
Real integrations encounter delayed events, duplicates, partial records, expired credentials, schema changes and decisions that cannot be automated. These are not edge cases in the colloquial sense. At scale, they are normal operating conditions.
The product needs an exception experience: a place to see what failed, enough context to understand why, and a safe way to retry, correct or escalate. Hiding exceptions in logs transfers product work to operations teams.
Five things to make explicit
- Which system owns each important fact?
- What timing and consistency does the workflow require?
- How are identity and permission preserved?
- Who sees and resolves an exception?
- How will a breaking change be detected before it reaches users?
Make ownership visible
Integration problems often persist because ownership is divided. One team owns the source, another owns the platform, a vendor owns the connector and nobody owns the end-to-end outcome. A working product needs a named owner for the operational path, supported by observability that crosses system boundaries.
This includes business-level signals, not only uptime. Are records arriving in time? Are required fields deteriorating? Are exceptions accumulating? Is the result being consumed by the intended workflow?
Treat the boundary as product surface
Integration deserves the same care as a user-facing screen because it shapes what users can trust. A well-engineered boundary makes the product feel coherent with the operation. A weak one makes every interaction feel provisional.
The result is not merely connected software. It is a capability that participates in the wider system of work.