Written by Technical Team | Last updated 23.07.2026 | 15 minute read
Most organisations do not set out to create a complicated integration estate. Complexity usually accumulates one practical decision at a time. A finance team needs customer data from a CRM. An operations platform needs stock information from an ERP. A customer portal must display case progress held in a legacy database. A supplier exposes an API, another accepts files over SFTP, and a third sends webhooks with incomplete documentation. Each connection appears manageable in isolation, yet the combined estate can become one of the most fragile and expensive parts of the technology landscape.
The architectural choice is often presented as a simple contest between point-to-point integration, an integration platform as a service, or custom middleware. That framing is too shallow. All three approaches can use APIs, queues, events, scheduled jobs and file transfers. All three can be built well or badly. The important difference is where integration complexity is placed, who owns the runtime and operational model, how consistently engineering standards can be enforced, and how easily the solution can adapt when systems, data and business processes change.
Choosing the right integration architecture therefore requires more than counting applications or comparing licence fees. It requires an understanding of data semantics, transaction boundaries, latency, throughput, regulatory constraints, failure recovery, deployment practices, internal capability and long-term change. The best architecture is not the most fashionable one. It is the one that makes the organisation’s most important integrations dependable, comprehensible and economical throughout their useful life.
An integration is not merely a pipe that moves data from one place to another. It usually performs several distinct jobs: connecting to a source, authenticating, validating input, transforming data, applying routing rules, coordinating a process, handling failures, recording an audit trail and exposing enough telemetry for operators to understand what happened. A connection between two systems may look straightforward on an architecture diagram while concealing difficult questions. Which system owns the customer record? What happens if the destination is unavailable after the source has committed a change? Can the same message be processed twice safely? Must events remain in order? How should a failed transaction be reconciled? Who is alerted when credentials expire? The architecture must answer these questions whether the implementation is visual, configuration-driven or written entirely in code.
It is useful to separate four concerns before selecting technology. Connectivity concerns protocols, network routes, authentication and vendor-specific interfaces. Mediation concerns mapping, validation, enrichment and translation between different data models. Process concerns orchestration, business state, timeouts, compensation and human approval. Operational concerns deployment, observability, support, security, capacity and recovery. Point-to-point integration, iPaaS and custom middleware allocate these responsibilities differently. None removes them. A sound decision begins by identifying which concerns are simple, which are strategically important and which are likely to change.
Point-to-point integration connects one system directly to another. A CRM might call an invoicing API when an opportunity closes, an ecommerce application might query an ERP for stock, or a scheduled script might export records from one database and import them into another. The approach has an obvious appeal: there is little platform overhead, the data path is easy to visualise, and a capable development team can often deliver the first working connection quickly. For a small number of stable, low-risk integrations, that simplicity is real rather than illusory.
Direct integration can also offer excellent performance. Removing an intermediary may reduce network hops and processing overhead, while a purpose-built mapping can be optimised for a specific payload and business case. The solution can use the source and destination systems’ native capabilities without waiting for a platform connector to support them. This makes point-to-point integration a rational choice for tightly bounded scenarios, particularly when both endpoints are under the same team’s control, the interface is well documented, traffic is predictable and the business process does not span multiple systems.
Problems emerge when direct connections multiply or when their responsibilities expand. In a fully connected estate, the potential number of bilateral relationships grows rapidly as systems are added, but the more important issue is not the mathematical connection count. It is the rate of independent change. Every source can alter its schema, authentication method, API version, throughput limit or availability profile. Every destination can introduce different validation rules and data semantics. If translation and business rules are duplicated across several direct integrations, a change to the definition of a customer, product or order can require coordinated updates in many places. What began as a collection of simple links becomes a distributed integration platform with no shared control plane.
Operational weaknesses are often the first visible symptom. A direct HTTP call may work in testing but fail unpredictably in production because a downstream service is slow or unavailable. An aggressive retry policy can amplify an outage, while an unbounded queue can merely postpone failure until recovery creates a traffic surge. If a request times out after the destination has completed the operation, the source may retry and create a duplicate payment, booking or case. Scheduled data synchronisation can silently skip records when timestamps, daylight-saving changes or pagination are mishandled. These are not edge cases; they are normal conditions in distributed systems. Direct integrations therefore need the same resilience disciplines as any other architecture: timeouts, bounded retries with back-off, circuit breakers, idempotency keys, dead-letter handling, reconciliation, correlation identifiers and meaningful alerts.
Governance becomes equally difficult. Point-to-point implementations are often scattered across application repositories, serverless functions, database jobs, low-code automations and scripts known only to one employee. There may be no authoritative catalogue of data flows, no standard way to rotate secrets, no shared logging format and no clear ownership when an incident crosses team boundaries. Security reviews become slower because each connection implements authentication and data handling differently. Testing is complicated because changes must be coordinated across both endpoints, often with limited access to realistic non-production environments. The architecture remains viable only if the organisation deliberately prevents “direct” from becoming “unmanaged”. Every integration should have an owner, an interface contract, automated tests, a support runbook, monitoring and an explicit retirement plan.
The right conclusion is not that point-to-point integration is inherently poor. It is that its low initial ceremony can hide future portfolio costs. It works best when the relationship is genuinely one-to-one, the integration logic is modest, failure has limited business impact, reuse is unlikely and both systems change slowly. It becomes a weak default when the same data is consumed in multiple places, a workflow crosses several systems, enterprise-wide security policies must be enforced, or the organisation cannot easily discover and operate its existing connections. In those conditions, either an iPaaS or custom middleware layer can provide a more coherent architecture.
An integration platform as a service provides a managed environment for building, deploying and operating integrations. Most iPaaS products combine pre-built connectors, visual workflow design, data mapping, scheduling, API management, event or message capabilities, secrets management, monitoring and environment promotion. The platform operator manages much of the underlying infrastructure, allowing teams to focus on integration flows rather than provisioning runtimes, patching servers or assembling every operational component independently. This can dramatically shorten delivery time for common SaaS, database, file and enterprise application integrations.
The strongest iPaaS use cases are repetitive but not trivial. Consider employee onboarding across a human resources system, identity provider, payroll platform, service desk and collaboration tools. The process needs conditional routing, data transformation, error handling and auditability, yet much of the connectivity is standard. An iPaaS can make the workflow visible, reusable and supportable without a large custom engineering effort. It can also enable a controlled form of decentralisation: central architects establish approved connectors, security policies, naming standards and deployment practices, while domain teams build automations within those guardrails.
The platform’s abstraction is both its advantage and its constraint. A pre-built connector removes protocol-level work, but it also defines which operations, authentication options, payload shapes, API versions and rate-limit behaviours are available. When a vendor introduces a new endpoint, deprecates an old field or changes pagination behaviour, the organisation depends on the iPaaS provider’s update cycle unless custom connector development is supported. Visual flows can become difficult to review when they contain extensive branching, nested loops, complex transformations and embedded scripts. Low-code does not eliminate code-like complexity; it represents that complexity in a different artefact, sometimes with weaker diffing, testing and refactoring tools than a conventional software development environment.
Commercial and operational dependencies also deserve careful examination. Subscription pricing may be based on connectors, environments, users, tasks, messages, compute, data volume or API calls. A platform that looks inexpensive for ten workflows can become costly when transaction volumes or business units grow. Data residency, private networking, hybrid deployment, disaster recovery and support response times may vary by service tier. Vendor lock-in is not limited to proprietary connectors: mappings, workflow definitions, operational dashboards and staff skills can all become platform-specific. Exiting may require rebuilding integrations rather than simply redeploying them elsewhere.
An iPaaS evaluation should therefore test more than whether a demonstration flow can connect two applications:
An iPaaS is usually the best fit when speed, standardisation and broad SaaS connectivity matter more than absolute runtime control; when the organisation wants managed infrastructure; and when most integration logic can be expressed cleanly within the platform’s model. It is less attractive for ultra-low-latency paths, highly specialised protocols, computationally intensive transformation, unusual deployment constraints or strategically distinctive processes that demand deep customisation. The key is to treat the iPaaS as an engineering platform, not as a shortcut around engineering. Architecture standards, automated testing, lifecycle management and operational ownership remain essential.
Custom middleware is software built specifically to mediate communication between systems. It might be a compact adapter service around a legacy application, a set of event-driven services, an API façade, a workflow orchestrator, a data synchronisation service or a broader integration platform assembled from frameworks, message brokers, API gateways and observability tools. It does not have to resemble the large, centralised enterprise service buses of the past. Well-designed custom middleware can be modular, independently deployable and aligned with clear domain boundaries.
Its principal advantage is control. Engineers can choose the programming language, runtime, hosting model, security controls, data stores, message broker and deployment topology. They can implement specialised protocols, optimise high-volume processing, place workloads in private or regulated environments and evolve the solution in step with business requirements. Code-first development provides mature support for branching, peer review, unit testing, contract testing, performance testing, static analysis and automated delivery. Open standards and portable components can reduce dependence on a single commercial platform, although cloud services and proprietary libraries can still create lock-in if selected carelessly.
Custom middleware is particularly valuable when integration logic embodies important business knowledge. Suppose an organisation must reconcile cases across several agencies, apply complex eligibility rules, maintain a complete audit history and coordinate activities that can remain open for weeks. Representing that process as a chain of simple connector actions may obscure its domain model and make change risky. A bespoke orchestration service can model states, commands, events, deadlines and compensating actions explicitly. Similarly, an anti-corruption layer can protect a modern application from the confusing schemas and behaviours of a legacy system, translating at a stable boundary rather than allowing legacy concepts to leak into every consumer.
The cost of control is ownership. A custom middleware estate needs a supported runtime, deployment pipelines, vulnerability management, dependency upgrades, capacity planning, backups, disaster recovery, security monitoring and on-call expertise. Teams must implement or select reliable patterns for authentication, routing, transformation, message persistence and error recovery. They must instrument the solution so that an operator can answer not only “is the service running?” but “where is customer order 48372, what data was transformed, which downstream call failed, and is it safe to replay?” Without that operational investment, custom middleware can become a collection of opaque services that reproduces the worst characteristics of point-to-point integration at a higher cost.
There is also a risk of overbuilding. Engineering teams sometimes create an internal framework for connectors, workflow design, schema management, monitoring and deployment until they have effectively built a private iPaaS. Unless those capabilities are strategically necessary, the organisation is spending scarce development capacity on platform features that commercial or open-source products already provide. The opposite error is to create one enormous middleware application that owns every mapping and process. That design centralises failure, couples unrelated release cycles and encourages business logic to accumulate in an integration layer that no domain team fully owns.
A sustainable custom approach keeps the platform thin and the boundaries explicit. Shared capabilities such as identity, messaging, telemetry, schema validation and deployment templates can be standardised, while domain-specific integration logic remains close to the team that understands it. APIs should be described with machine-readable contracts, and event schemas should be versioned with clear compatibility rules. Consumers should be idempotent because at-least-once delivery and replay are normal operational realities. Long-running distributed processes should use explicit state and compensation rather than pretending that a database transaction can span independent systems. Most importantly, middleware should be treated as a product with users, service objectives, a roadmap and accountable ownership.
The most useful decision criteria are not simply “small, medium or large organisation”. A small company may operate a safety-critical integration, while a large enterprise may have dozens of direct links that are entirely appropriate. Evaluate each integration against six dimensions: semantic complexity, change frequency, operational criticality, performance profile, governance requirements and strategic differentiation. Semantic complexity measures how different the systems’ concepts and rules are. Change frequency considers how often endpoints, processes and consumers evolve. Operational criticality covers the cost of delay, duplication, loss or corruption. Performance includes latency, throughput, payload size and traffic shape. Governance includes security, audit, residency and separation of duties. Strategic differentiation asks whether the logic is a commodity workflow or part of what makes the organisation distinctive.
These dimensions often reveal that the correct answer is a portfolio rather than a single enterprise-wide standard. Direct integration may suit a stable transfer between two internal systems. An iPaaS may handle SaaS automations, scheduled synchronisation and standard employee or finance workflows. Custom middleware may support high-volume customer transactions, complex case orchestration, legacy isolation or regulated data exchange. The danger lies not in using multiple approaches but in allowing them to overlap without rules. An architecture policy should define which integration classes belong where, how exceptions are approved and which cross-cutting standards apply to all of them.
A practical selection guide is:
Cost modelling should cover the whole lifecycle rather than the first release. For point-to-point integration, include duplicated engineering, coordinated changes, fragmented monitoring and incident diagnosis. For iPaaS, include platform subscriptions, consumption growth, premium networking, custom connectors, specialist skills and migration costs. For custom middleware, include build effort, cloud infrastructure, platform engineering, security updates, observability, support and technical renewal. The cheapest proof of concept is rarely the cheapest five-year architecture. Conversely, a theoretically elegant platform can be poor value if the organisation only needs a handful of stable connections.
The choice should also be tested against failure, not only the happy path. Run architecture scenarios in which the destination is unavailable for six hours, a webhook is delivered three times, messages arrive out of order, an access token expires, a payload exceeds normal size, a source changes its schema, a deployment must be rolled back, or a transaction must be replayed after an operator corrects bad data. Ask how the team detects the issue, contains it, recovers safely and proves what happened. Architecture becomes tangible when discussed through these operational stories. A solution that is easy to draw but difficult to recover is not simple.
Finally, decide where business truth should live. Integration layers should translate, route and coordinate, but they should not casually become the master of data or the hidden owner of core business policy. When rules belong to a domain system, expose them through a stable interface rather than copying them into every integration. When several consumers need the same capability, create a reusable API or event contract instead of duplicating mappings. When legacy semantics are harmful, isolate them behind an anti-corruption layer. These choices reduce coupling more effectively than any product purchase.
Point-to-point integration, iPaaS and custom middleware are therefore not competing maturity levels in which one is always primitive and another always advanced. They are different allocations of responsibility. Point-to-point places more responsibility in the connected applications and their teams. iPaaS transfers much of the runtime and tooling responsibility to a platform provider while retaining responsibility for flow design and governance. Custom middleware gives the organisation maximum design freedom while making it accountable for engineering and operations. The right architecture is the one whose responsibilities your organisation is prepared to own.
For many estates, the strongest answer will be deliberate hybridity: use direct connections sparingly, use an iPaaS for repeatable commodity integration, and invest in custom middleware where complexity or differentiation justifies it. Support all three with an integration catalogue, explicit owners, versioned contracts, automated tests, common security controls, end-to-end observability and clear service objectives. That combination avoids both extremes: a tangle of unmanaged connections and an oversized central platform imposed on every problem.
Is your team looking for help with software development and integration? Click the button below.
Get in touch