Capability · System Integration
System Integration
APIs, events, middleware and adapters that connect critical systems without creating a new layer of fragility.
Integration is where system boundaries become visible.
Most critical processes cross more than one system. The customer record, the asset record, the financial transaction and the operational schedule rarely live in the same place. Integration makes those boundaries work together.
Point-to-point connections are easy to build and expensive to own. Each new system multiplies the number of connections, each connection hides its own assumptions, and a change in one application becomes an unbounded testing problem across the estate.
A durable integration architecture makes contracts explicit: what is exchanged, in which direction, at what frequency, with what failure behaviour and who owns the meaning. It also makes the integration observable, because a failed message that nobody can see is a business outage waiting to happen.
A complete capability, not a single workstream.
The scope is shaped around the outcome. These are the components we commonly combine; the emphasis changes with the problem.
Integration strategy
A target model for how systems, partners and data will connect, including ownership and governance.
API design and implementation
Versioned, documented APIs with clear contracts, authentication, rate limits and error semantics.
Event-driven architecture
Event schemas, topics, delivery guarantees, idempotency and replay designed for the business process.
Middleware and orchestration
Routing, transformation and process orchestration where the complexity is genuinely required.
Legacy adapters
Controlled interfaces to older systems that cannot be changed, with monitoring and a plan for eventual retirement.
Integration observability
Tracing, correlation, alerting and operational dashboards for message flow and failure handling.
A path that makes the difficult parts visible.
The sequence is adapted to the System Integration context; each stage still produces an artefact the next stage can rely on.
Map the process
We start with the business process and the systems it crosses, not with the technology catalogue.
Define the contracts
Each exchange gets an explicit contract: payload, semantics, frequency, ownership, error behaviour and versioning.
Choose the interaction style
Synchronous APIs, asynchronous events, files or batch each have a cost. We choose based on the process, not fashion.
Build the failure path
Retries, dead-letter handling, idempotency and reconciliation are designed before go-live.
Operate and evolve
We instrument the integration and define how contract changes are governed over time.
Decisions that determine the outcome.
Synchronous or asynchronous
Synchronous calls are simpler to reason about but create coupling and failure propagation. Events decouple systems but introduce eventual consistency. The business process should decide.
Canonical model or local translation
A canonical model reduces point-to-point mapping but can become a bottleneck. Local translation keeps ownership close to the system but risks inconsistent meaning.
Who owns the contract
Every API or event needs an owner accountable for its meaning and change. Without ownership, versioning becomes a negotiation after the break.
How to retire a legacy interface
Legacy adapters should have a stated retirement path. Otherwise they become permanent architecture with no owner.
What working together looks like.
Integration engagements begin with an integration assessment: systems, interfaces, traffic, failure history, ownership and the business processes at risk. The output is a target architecture and a sequenced remediation plan.
Delivery can be organised around a specific integration, a partner onboarding, a platform build or a broader remediation programme. Each increment is tested against normal, degraded and failure conditions.
What we need from you
- An interface inventory and system owners
- Representative test data and environments
- A business process owner for acceptance
- Security review for authentication and data handling
What you receive
A written scope, an architecture and delivery plan, regular demonstrations, decision records and a handover pack. The exact artefacts are agreed before work begins so that “done” is not a matter of opinion.
What good looks like in practice.
Indicative outcome ranges from comparable engagements. The measures are agreed at the start of each engagement and reported against a baseline.
The questions worth asking before you commit.
Can you integrate with a legacy system we cannot change?
Yes. We build an adapter around the legacy interface, document its constraints and isolate it so the rest of the architecture is not coupled to its limitations.
Do we need an API gateway?
Not automatically. A gateway is useful when there is a genuine need for central policy, routing, authentication or observability. It is not a substitute for good API design.
How do you test integrations?
With contract tests, representative data, failure injection and end-to-end process tests. Testing only the happy path leaves the most expensive behaviour unverified.
What happens when a partner changes their API?
The contract and versioning approach should make the change visible before it breaks. We include monitoring, change notification and a tested fallback where the risk justifies it.
Most problems cross more than one discipline.
If the boundary is unclear, start with a conversation. We will help define the smallest useful engagement.
What an integration inventory should contain.
An integration inventory is the foundation of any remediation programme. Without it, every change is assessed against an incomplete picture and every incident is investigated from scratch.
- The systems, owners and business capabilities at each end of the exchange.
- The direction, frequency, payload and data classification of each flow.
- The contract, versioning approach and known consumers.
- The failure behaviour, retry policy, alerting and reconciliation path.
- The operational runbook and the person accountable when the flow fails.
The inventory does not need to be a large platform. A maintained register with named owners is more useful than a diagram that is already out of date. The first outcome is a shared view of what exists; the second is a decision about what to retire, replace or leave alone.
Ready to define the next step?
Tell us about the system, the constraint and the outcome. We will respond with a practical view of scope and fit.