Platforms & integration
The integration decisions that make modern platforms dependable
Plan system ownership, interface contracts, failure handling and reconciliation before connecting CRM, ERP, data platforms and AI workflows.
At a glance
- Agree which system owns each business fact.
- Design retries, exceptions and reconciliation together.
- Test the whole business journey before handing it over.
A new platform rarely operates alone. It inherits customer identifiers, stock records, financial rules and service commitments from systems around it. Integration is where those assumptions meet. Treating it as a connection task at the end of a project leaves the business to discover the missing decisions in production.
The working method
- 01
Contract
Define identity, meaning, access and timing.
- 02
Prove
Exercise failures as well as successful calls.
- 03
Operate
Assign monitoring, recovery and support.
Part 01
Agree where each fact is authoritative
Identify which system owns each business entity and who can change it. A customer account may appear in CRM, billing and a service platform, but they may represent different relationships. Agree the identifiers, matching rules and ownership of disputed records before synchronizing them.
Separate an operational source from an analytical copy. A data warehouse may combine information for reporting without becoming the place where an address change is approved. Document the direction of updates and how corrections return to the authoritative record.
Part 02
Define the interface contract
Specify the fields, meaning, validation, access permissions and expected timing. Decide how the receiving system distinguishes a new event from a retry. Include versioning and the process for communicating a source change. An interface contract is an operational agreement as much as a technical specification.
Choose synchronous calls, events or batch transfers according to the business need. A user waiting for an immediate answer has different requirements from a nightly management report. Do not add real-time complexity to work that can tolerate a simpler refresh pattern.
| Contract area | Question to settle | Proof to retain |
|---|---|---|
| Identity | How is the same entity recognized? | Sample matches and disputed-record handling |
| Timing | How current must the information be? | Agreed latency and stale-data behavior |
| Retries | What happens when the same request arrives twice? | Duplicate and recovery test cases |
| Change | Who approves a revised payload? | Versioning and compatibility decisions |
Swipe the table to view all columns →
Part 03
Design what happens when the connection fails
Test timeouts, partial completion, invalid records and unavailable downstream systems. Decide whether to retry, queue, stop or ask for review. A retry that creates another order is not a recovery mechanism. Keep business reconciliation separate from the claim that a message was delivered.
Give support teams a traceable reference and a clear owner for the exception. Logs should help locate the failure without exposing unnecessary sensitive content. Agree how a person can correct the state and resume work safely.
Part 04
Test the complete business journey
Prove the journey across every relevant system using representative cases. Check that a permitted change reaches the right destination, the user sees the correct status and the totals reconcile. Include restricted access and the withdrawal or correction of an earlier action.
For an AI-enabled workflow, apply the same discipline to the action boundary. A generated answer and an executed transaction are different outcomes. Record what the agent may read, prepare or change, and the approvals required before an irreversible step.
Part 05
Hand over a service, not just an endpoint
Agree monitoring, support hours, escalation routes, runbooks and the owner of each credential. Include capacity and cost at the expected traffic pattern. Make sure someone can explain the status of a business transaction without depending on the person who originally built the connection.
Review interface dependencies when planning future releases. A platform can be technically current while its integrations remain fragile. Dependable modernization includes the work needed to operate, change and recover the whole connected service.
- An agreed source of truth and identity rules.
- A documented interface contract and change process.
- Tested failure, retry and reconciliation paths.
- Named operational ownership and a usable support runbook.
