An integration platform as a service provides hosted tooling for connecting applications and data — prebuilt connectors, transformation, orchestration, API management, event handling, and monitoring — without building and operating that infrastructure yourself.

When should integrations be event-driven rather than API calls?

Use events when multiple consumers need to react to a state change, when systems must remain decoupled, or when the producer should not wait for consumers. Use synchronous APIs when the caller needs an immediate answer to continue, such as a price or availability check.

How do you prevent integration sprawl?

Maintain a catalogue of integrations with named owners, define canonical data models for shared entities, require review before new point-to-point connections are built, and set standards for error handling, retries, and monitoring that every integration must meet.

Integration Platform Strategy: iPaaS Selection & Governance

Ask why a straightforward business change takes four months and the answer is usually integration. Point-to-point connections built over a decade, each with its own error handling, credentials, and undocumented assumptions, form a web where every change requires archaeology first.

An integration platform can fix this. Bought without governance, it accelerates the same problem — now with a subscription fee.

Decide what the platform is for

Integration platforms serve three quite different jobs, and vendors are rarely equally good at all three: system-to-system data movement and transformation, API management and externalisation, and event distribution across many consumers. Rank these by your actual need before evaluating, because a platform excellent at batch data movement may be weak at high-volume event streaming and vice versa.

Choose patterns deliberately

Pattern	Use when	Watch for
Synchronous API	Caller needs an immediate answer to proceed	Latency coupling and cascading failure
Event / publish-subscribe	Multiple consumers react to a state change	Ordering, duplicate delivery, schema evolution
Batch / scheduled	High volume, tolerance for delay, reconciliation	Silent partial failures
Change data capture	Replicating state without touching the source application	Coupling to internal database schemas

Most enterprises need all four. What they cannot afford is choosing per project by developer preference, which is exactly how estates become unmaintainable.

Canonical models where it matters

Full enterprise-wide canonical data modelling is a multi-year effort that rarely finishes. Do it narrowly instead: define a shared model for the three to five entities that genuinely cross domains — customer, product, order, employee, asset — and let everything else use local shapes.

For each shared entity, name the system of record per field. Contested field ownership is the leading cause of integration incidents, because two systems both believe they are authoritative and overwrite each other in a loop.

Evaluation criteria that predict satisfaction

Connector depth, not count. Verify the connectors you actually need against real API versions and edge cases; connector counts in marketing material are meaningless.
Error handling and replay. Can a failed message be inspected, corrected, and replayed without engineering intervention?
Observability. End-to-end tracing across a multi-step flow, not per-step logs.
Deployment model. Source-controlled, promotable artefacts across environments — drag-and-drop-only tools that cannot be versioned become production risks.
Runtime placement. Ability to run near on-premise systems where data residency or latency requires it.
Pricing model. Volume-based pricing can grow unpredictably; model three years against realistic growth.

Governance, including citizen integrators

Low-code integration is genuinely valuable and genuinely dangerous. Business users building their own flows relieves the central backlog and simultaneously creates unmonitored dependencies on personal credentials.

Handle it with tiering: a sandbox tier where anyone can build for personal or team use with no production dependency; a supported tier where flows serving a business process must meet standards for ownership, error handling, and monitoring; and a core tier where revenue-critical or regulated integrations are built and operated by the platform team. Publish the criteria and enforce them at promotion between tiers.

Operate it as a product

Maintain a catalogue of every integration with owner, systems connected, data classification, and criticality. Instrument for failure visibility — most integration incidents are discovered by business users noticing missing data, which is unacceptable for critical flows. Set service levels for latency and error rate per criticality tier, and review the top failure sources monthly.

Then measure the outcome that justified the investment: time to deliver a new integration, and the proportion of the estate meeting your standards. If those are not improving, you bought tooling rather than capability.

Frequently asked questions

What is an iPaaS?

A hosted platform providing connectors, transformation, orchestration, API management, event handling, and monitoring for connecting applications and data without operating that infrastructure yourself.

Events or APIs?

Events when several consumers must react to a state change or systems must stay decoupled; synchronous APIs when the caller needs an immediate answer to continue.

How do we prevent sprawl?

A catalogue with named owners, canonical models for genuinely shared entities, review before new point-to-point connections, and enforced standards for error handling and monitoring.

Do we still need canonical data models?

For the few entities that cross domains, yes. Attempting enterprise-wide canonical modelling rarely completes and delays value.

Integration Platform Strategy: Choosing and Governing an iPaaS