An integration landscape becomes risky one reasonable shortcut at a time. A CRM needs billing data, so somebody builds a direct connection. Marketing needs the same record, so another appears. Acquisitions add platforms, suppliers change APIs and manual reconciliations become ordinary work. Eventually, a diagram resembles spaghetti and nobody can explain the consequence of one critical system going offline.
Complexity may reflect a complex business, though much of the risk comes from ownership and delivery choices. Buying an API gateway or event platform cannot correct unclear data authority, unmanaged change or missing error handling. New infrastructure can house the same disorder more expensively.
Simplification begins by making the present service observable, then reducing risk incrementally.
Map what exists in reality
Do not rely on the architecture diagram from the last transformation. Build an inventory from several forms of evidence:
- application and supplier records;
- source repositories, integration platforms and scheduled jobs;
- network, API and monitoring information;
- data exports and automated file transfers;
- identity and access configuration;
- interviews with people who reconcile or re-key information;
- incident, support and change records;
- contracts, service accounts and renewal dates.
For each connection, record the systems, data, direction, trigger, frequency, volume, authentication, owner, support route, dependency, monitoring, recovery method and business process served. Include spreadsheets, inbox rules and desktop tools. A manual handoff may be more critical than a formally managed API.
Validate the map with operational teams. The people handling month-end, onboarding or reporting often know about dependencies absent from technology records. Record confidence and unknowns rather than turning assumptions into facts.
Identify critical flows and failure consequences
Treating every integration as equal creates a long remediation list with no decision logic. Rank flows by service consequence, data sensitivity, recovery difficulty, change frequency and failure history.
Trace a few important journeys end to end. For client onboarding, for example, follow identity, conflict or eligibility checks, account creation, document access, billing and communication. Ask where the process stops, degrades or creates incorrect records if each connection fails.
Examine cascading failure. Retry behaviour that looks sensible in isolation can overwhelm a recovering upstream service. A delayed record may arrive out of order. A partial update can make two systems disagree. Identify which controls contain the failure and which spread it.
This risk-weighted view tells the board what simplification protects: revenue movement, client service, accurate reporting, resilience, compliance and colleague capacity.
Decide who owns each meaning
“Single source of truth” is useful only when it refers to a defined data concept. One system may author a client’s legal identity while another owns communication preferences and a third calculates current balance. Declaring the CRM authoritative for “client data” is too broad.
Create ownership at field or domain level where consequence requires it. Define:
- who is accountable for the meaning and quality of the data;
- where it is created and corrected;
- which systems may update it;
- how conflicts are resolved;
- retention and access rules;
- the effective date or version semantics.
This is partly a governance question because system owners may have competing operational needs. Resolve the business meaning before asking engineers to automate the disagreement.
Use explicit contracts
An integration contract should state the data structure, validation, authentication, version, service expectation and failure behaviour at the boundary. This does not require every connection to become a public API. Files, events and point-to-point interfaces can be well governed when their contracts are visible and tested.
Design for ordinary failure conditions:
- missing, duplicate, late or malformed records;
- loss of authentication or network access;
- upstream unavailability and rate limits;
- unexpected volume;
- partial processing;
- schema or vendor-version change;
- replay after recovery;
- safe manual intervention.
Retries need limits, backoff and idempotency where appropriate. Failed messages need a visible destination and an accountable response. Alerts should reach somebody able to act, with enough context to distinguish a transient issue from corrupted data.
The aim is graceful degradation. A failure should be detected, contained and recoverable without relying on a client to discover a wrong invoice.
Improve data before moving it faster
A reliable interface can propagate bad data with impressive efficiency. Profile the fields required for each high-value flow and determine whether completeness, consistency, timeliness and validity are adequate for the intended decision.
Correct causes as well as records. If mandatory information is omitted because the source workflow is impractical, a cleansing exercise will decay. If two teams use the same field to mean different things, validation alone will not resolve it.
Avoid making “perfect data” a prerequisite for all progress. Establish the quality required for a specific flow, contain exceptions and improve the source process. This links integration work to usable outcomes rather than an indefinite data programme.
Choose architecture by need
A managed integration layer can reduce duplicated connections, centralise policy and improve observability. It also introduces a platform, operating skill and potential concentration risk. A well-documented direct connection may remain the better answer for a simple, stable and low-consequence exchange.
Assess options against current and expected scale, change rate, delivery capability, security, latency, vendor constraints, support and total ownership cost. Avoid using the combinatorial maximum of possible connections as proof that every system will actually need to talk to every other system.
The target state should be pragmatic. Show which flows will move to shared services, which will be repaired in place, which will retire and which risks are consciously accepted. Architecture is a set of decisions and constraints, not an aspirational diagram.
Migrate with rollback and reconciliation
Start where risk reduction and learning justify the effort, rather than automatically choosing the easiest or most visible integration. Sometimes a lower-risk flow is the right proving ground. Sometimes leaving a critical unsupported connection untouched is the larger danger.
For each change:
- establish baseline volume, quality and failure evidence;
- build automated contract, edge-case and security tests;
- rehearse deployment, recovery and vendor dependency failure;
- run controlled parallel or shadow processing where feasible;
- reconcile outputs and explain differences;
- define rollback conditions and decision authority;
- remove the old path only after verified stability;
- update the operating map and ownership record.
Monitor business outcomes as well as technical health. A successful message count means little if finance still spends days correcting payment terms.
Make the commercial case visible
Measure manual reconciliation, incident effort, delayed work, inaccurate reporting, supplier cost and constrained change. Use observed time and ranges. Do not assume every saved hour becomes revenue.
Frame investment around the service it protects and the options it creates. Faster onboarding, dependable billing, traceable client data and lower change risk are more useful than “modernising the integration architecture”.
The integration health checklist available below helps map connections, ownership, failure handling and high-risk dependencies. Its output can support a technical plan and a finance conversation, provided unknowns remain visible.
Most estates do not need a big-bang replacement. They need an accurate map, clear data decisions, interfaces that fail visibly and a sequence that removes the most consequential risk without creating a new one.
