Enterprise API Strategy: Integration Architecture That Outlives Its Systems

The Spaghetti Tax

Every organisation over about ten systems pays it. Each new tool gets wired directly to three others; five years later there are 60 undocumented point-to-point links, and every change becomes an archaeology project. The symptom is always the same sentence: "we can't touch that — we're not sure what depends on it."

The cure isn't a heroic replatforming. It's deciding that integration is a product with an owner, contracts and standards — then applying that standard to everything new, and to the old stuff only as you touch it.

Contract-First or Chaos

• Design the interface before the implementation. An OpenAPI (or AsyncAPI) spec, reviewed like code, is the contract. Consumers build against the contract, not against whatever the endpoint happens to return this week.
• Version like you mean it. Additive changes are free; breaking changes get a new major version, a deprecation window with usage telemetry, and a migration note. The rule that keeps estates healthy: you may not break a consumer you cannot name.
• Standardise the boring parts. Auth (OAuth2 client-credentials for services), pagination, error shapes, idempotency keys, correlation IDs. Twenty APIs that behave identically are worth more than forty that are each clever.
• Publish a catalogue. If developers can't find an API, they'll rebuild it. A searchable portal with specs, examples and owners is the highest-leverage documentation your platform team will ever write.

APIs for Questions, Events for Facts

The most common integration design error is using request/response for everything. Split by intent:

• Synchronous APIs when the caller needs an answer now: "what's this customer's balance?"
• Events when something true just happened and multiple systems care: order.placed, customer.updated, payment.settled. Publishers don't know their consumers; consumers subscribe. Adding the tenth subscriber costs nothing — that's the property point-to-point can never give you.

Most estates need both, with events carrying the business facts and APIs serving the lookups. (For when this graduates into full streaming infrastructure, see our Kafka and Kinesis guide.)

Point-to-point integration is technical debt with a smile. It's fastest for the first connection, breakeven by the fifth, and by the twentieth it owns you.

The iPaaS Question, Answered Honestly

Do you need MuleSoft, Boomi or Workato? Sometimes. An iPaaS earns its licence when you have many SaaS-to-SaaS flows, a team that configures rather than codes, and connectors that genuinely match your estate. It becomes an expensive regret when it turns into a place where business logic goes to hide — unversioned, untested, and owned by whoever left last year. Our rule: orchestration and transport can live in an iPaaS; business rules and state belong in services you own, under version control, with tests. Several of our largest clients run exactly this hybrid: an integration platform doing stateless orchestration, with domain services holding the logic.

Securing the Layer

The integration layer is your biggest internal attack surface: every credential, every data flow crosses it. Minimum bar: no shared service accounts, secrets in a vault with rotation, mutual TLS or signed tokens between services, per-consumer rate limits, and audit logs that can answer "which system read this customer's data last Tuesday?" If that question takes more than a query, fix that before adding anything new.

Where to Start

Not with a two-year platform programme. Pick the next integration you were going to build anyway; build it contract-first on the standards above; stand up the catalogue with one entry. Every subsequent integration lands on the pattern, and the estate improves at the speed you were already moving. In our fixed-price engagements we typically stand up the standards, the gateway/eventing spine, and the first three production integrations in 6-8 weeks — and leave your team with a paved road, not a dependency on us.