Bespoke systems · JNAGA perspective
What should be decided before connecting two business systems?
Connecting tools is not just moving data. It is deciding what each system is allowed to know and change.
Published 25 September 2026
Imagine a sales system sends customer details to a billing tool. A customer updates an address in one place after an invoice draft has been created in the other.
Before building the connection, decide which record is authoritative at each stage, whether changes flow in both directions and who resolves a mismatch. Silent overwriting is not a dependable integration strategy.
Name the source of each fact
List the important fields and their business meaning. Which system creates them, who can correct them and when does another system need a copy? Two tools may use the same label for different meanings. Agreeing the definitions is part of the integration design.
Avoid making every field bidirectional by default. A clear source and direction of travel reduces conflicting updates and makes errors easier to diagnose.
Design for delays and failures
A transfer may fail, arrive twice or succeed on one side only. Decide what the user will see, what will be retried and which action must wait until confirmation. The integration should leave enough trace for an operator to understand what happened without exposing unnecessary personal information.
A technical alert is not a resolution process. Name the person or team that will reconcile exceptions and the business consequence of leaving them unresolved.
Test the boundary with real cases
Use ordinary changes, corrections and awkward timing cases in a controlled test. Confirm that each system still serves its own purpose after the connection is made. An integration is successful when the work becomes more reliable, not when data merely moves.