Fragmented information
Teams re-enter, reconcile, or search for the same information across tools because no trusted flow or ownership model is clear.
03 · Technology layer
Data & Integration
Connect information and services through understandable flows, explicit ownership, and planned failure behaviour.
The context
Why this layer deserves deliberate decisions.
An integration is an operational relationship, not only a technical connection. Useful design makes it clear what information moves, who owns it, how access is controlled, and what people or systems should do when one side is delayed or unavailable.
Hidden failure paths
The happy path is connected, but timeouts, duplicates, partial updates, and provider changes leave inconsistent data or require manual recovery.
Unclear authority
Multiple systems can change the same record without an agreed source of truth, synchronisation rule, or audit trail.
Areas of attention
Connect product needs to technical responsibilities.
The appropriate depth depends on the current system, the decision in front of the team, and the consequence of getting it wrong.
01
Data flow and ownership
Map where important information begins, how it changes, which system is authoritative, and who is responsible for quality.
02
Integration contracts
Define payloads, validation, identity, permissions, compatibility, limits, and expected provider behaviour.
03
Reliability and recovery
Plan retries, idempotency, reconciliation, monitoring, and human intervention around realistic failure scenarios.
04
Workflow automation
Automate stable, understood steps while preserving visibility and a route for exceptions that require judgement.
Potential artefacts
Make the technical direction usable by the team.
The exact artefacts follow the question and available evidence. Their purpose is to support implementation, review, and future ownership.
- 01Current and target data-flow maps
- 02System ownership and source-of-truth decisions
- 03Integration contract or API definitions
- 04Failure, recovery, and reconciliation scenarios
- 05Staged implementation and verification plan
Decision framing
Use context and evidence before adding complexity.
A useful direction explains the inputs, how it can be evaluated, and where its boundaries remain.
What we need to understand
- Systems, owners, access options, and provider constraints
- Information being transferred and its sensitivity
- Volumes, timing, consistency, and availability expectations
- Current manual work, exceptions, and recovery practices
Evidence of a useful direction
- Each important data element has a clear source and destination
- Authentication and permission responsibilities are defined
- Duplicate, delayed, invalid, and partial events have expected behaviour
- Operators can see and recover material failures
Important boundary
Automation should not hide unresolved policy or ownership questions. Some exceptions benefit from an explicit human decision rather than increasingly complex rules.
Working path
Move from current reality to an owned direction.
These stages are adapted to the size of the decision. Each should leave the next choice clearer than it was before.
Map the operating flow
Understand the people, systems, information, decisions, and exceptions in the current workflow.
Define the contract
Agree ownership, data shape, identity, permissions, timing, limits, and expected error behaviour.
Build and verify
Implement the connection with representative scenarios, controlled test data, and checks for important failure paths.
Prepare operations
Make monitoring, reconciliation, support responsibility, provider change, and recovery procedures visible.
Technology questions
Useful details to clarify.
Can you integrate with any third-party platform?+
Only where the platform provides suitable and permitted access. We first review its current API, authentication, limits, data model, terms, and operational constraints.
When is workflow automation a good fit?+
It is most useful when a repeated process and its exceptions are understood, the inputs are dependable, and the outcome can be checked.
How do you avoid duplicate updates?+
The design may use stable identifiers, idempotent operations, event records, reconciliation, and explicit retry behaviour depending on the systems involved.
Who owns an integration after launch?+
Operational ownership should be agreed before launch, including monitoring, credentials, provider changes, failure response, and escalation responsibilities.
Start a conversation
Need clarity around the data and integration?
Share the product, current system, constraints, and decision in front of your team. We can help frame a practical next step.