SAP Integration Suite Architecture: Components, Runtimes, and Integration Patterns

Enterprise integration architecture keeps getting harder for a reason that has nothing to do with integration technology. Organisations rarely operate one technology environment. A typical manufacturing, logistics, retail or utilities estate holds SAP S/4HANA or SAP ECC, cloud applications and SaaS, an MES on the shop floor, warehouse and transport systems, a CRM, partner networks, APIs of varying quality, legacy applications nobody wants to touch, and infrastructure split across private and public cloud.

SAP Integration Suite provides integration capabilities across that kind of landscape. What it does not provide is the architecture. The platform's value depends almost entirely on which capabilities are selected for which requirement, where integration workloads are placed, and how the result is secured, monitored and owned.

This guide covers SAP Integration Suite architecture from that angle. Not a product catalogue and not a configuration tutorial, but the architectural decisions that determine whether the platform ends up as a governed integration layer or as a cloud-hosted copy of the estate it replaced.

What is SAP Integration Suite architecture?

SAP Integration Suite architecture combines cloud-based integration capabilities for application integration, APIs, events, B2B scenarios and integration governance with connectivity and runtime options spanning cloud and hybrid landscapes. Enterprises use these capabilities together to connect SAP and non-SAP applications while managing security, runtime placement, monitoring and integration standards.

Where does SAP Integration Suite sit in the enterprise architecture?

Between systems and the business processes that span them. Systems of record hold the business truth. SaaS platforms, partner networks, digital applications and external consumers all need to interact with that truth without each building its own path to it. An integration layer exists to make those interactions governable.

One qualification matters before going further. Integration Suite is not the only integration technology in most enterprise landscapes, and SAP's own architecture methodology does not assume it should be. ISA-M explicitly recognises that organisations may combine several integration technologies depending on integration domain and style. An architecture that routes every requirement through one platform because the platform exists is a decision, and usually not a considered one.

Platform context is covered in what is SAP BTP, and the capability set itself in what is SAP Integration Suite.

The main building blocks of SAP Integration Suite architecture

Described by architectural responsibility rather than by feature list:

Two things in that table are easy to misread. Cloud Connector sits under SAP BTP Connectivity rather than being an Integration Suite capability, which matters more than it sounds and is covered further down. And Edge Integration Cell is a runtime rather than a capability, which is a different kind of entry in the same list. Additional capabilities including OData Provisioning, API Composition within API Management, and Data Space Integration apply in more specific scenarios. Check the current capability set in SAP's Integration Suite documentation, since the catalogue continues to evolve.

The layered view above is our own conceptual framework rather than an SAP-defined reference architecture. It is useful because it separates concerns that get conflated in practice. Systems and endpoints. Connectivity. Integration capabilities. Runtime placement. Governance and operations. Most architecture discussions collapse the middle three, which is where avoidable mistakes originate.

Design and management versus runtime: the control plane distinction

This is arguably the most useful single concept in Integration Suite architecture, and it is the one most often missing from capability overviews.

SAP describes its hybrid model as a distributed architecture. Centralised cloud services provide design, configuration and monitoring. Integration workloads execute either on the SAP-managed cloud runtime or, where requirements justify it, on an optional customer-managed Edge Integration Cell runtime.

Separating those two ideas answers questions that otherwise get muddled. Where an integration flow is designed and where it executes are different decisions. Monitoring can remain centralised while processing happens inside a private landscape. Choosing a hybrid runtime does not mean giving up unified design tooling or accepting a second management surface.

Architects who hold this distinction tend to ask better questions. Not "should we go hybrid" as a binary, but "which specific workloads have a data residency, latency or connectivity requirement that argues for private execution", which is answerable per interface.

Cloud Integration as the process-integration runtime

Cloud Integration is the capability for designing, deploying and operating end-to-end process integration flows. Architecturally it covers application-to-application scenarios, B2B and B2G process integration, transformation, routing, adapter-based connectivity and orchestration, across both cloud and hybrid connectivity.

It is the capability people usually mean when they say CPI, and the one most likely to absorb requirements that belong somewhere else. The architectural point is not how integration flows are built, which belongs to a dedicated Cloud Integration discussion. The point is that Cloud Integration answers one question well, how systems exchange and transform information, and answering a different question with it produces the anti-pattern covered later in this article.

Where API Management fits in the architecture

API Management addresses a different architectural problem from Cloud Integration, and the cleanest way to hold the distinction is as two questions.

Cloud Integration asks: how do systems exchange and transform information?

API Management asks: how do we expose, secure, govern, control and monitor reusable APIs?

SAP positions API Management around API design, security, traffic management, lifecycle governance, consumption, composition and insights. Architecturally its job is abstraction and control. It puts a governed, versioned, policy-enforced surface in front of a backend capability so that consumers depend on a contract rather than on an implementation. Detail belongs in a dedicated API Management discussion.

Cloud Integration and API Management together

A common composition runs backend system, then Cloud Integration for connectivity and transformation, then API Management for governed exposure, then the consumer.

That is one valid pattern rather than a rule. Not every API requires an integration flow behind it, since a well-designed backend service may need only exposure and policy. Not every integration flow requires API Management, since a scheduled file-based interface with one consumer has no API to govern. Architecture follows the requirement, and applying the full chain everywhere adds hops and latency for no architectural gain.

Where Event Mesh fits in the architecture

Event Mesh supports asynchronous, event-driven integration. A publisher announces that something happened. Subscribers react. Neither needs to know about the other's availability at the moment of publication.

SAP's architecture guidance positions event-driven architecture around responsive systems, asynchronous communication and looser coupling, and connects it to Clean Core goals. The architectural payoff is decoupling, and it is easiest to see in the failure case. A synchronous call means the caller waits and fails if the target is unavailable. With queued asynchronous messaging, the producer does not need the consumer to be available at publication time, because the broker can retain guaranteed messages until a consumer is available.

Note what that does and does not remove. It removes the producer's dependency on the consumer. It does not remove a dependency on the messaging infrastructure itself, and the delivery guarantees depend on the acknowledgement and retention model in use. Decoupling is a shift in where the dependency sits rather than its elimination. In an estate where a plant system going offline currently stalls an order process, that shift is a design decision with operational consequences rather than a stylistic preference.

Event Mesh and SAP Integration Suite, advanced event mesh

These are distinct offerings serving different scales, not two versions of the same thing.

Event Mesh suits event requirements within Integration Suite scenarios, including organisations beginning with event-driven patterns. SAP Integration Suite, advanced event mesh is a broader event streaming and event management platform for more demanding enterprise event-driven architecture requirements. SAP describes a start-small-and-expand path from one toward the other as event requirements grow.

B2B architecture: Integration Advisor and Trading Partner Management

B2B architecture is best understood as a design-time and runtime split rather than as a single chain, and getting that distinction right avoids a common misreading.

At design time, Integration Advisor provides interface and mapping definitions while Trading Partner Management manages partner profiles and agreements. At runtime, Cloud Integration processes messages using the generated partner-specific configuration, and the result lands in the ERP.

The point worth holding is that runtime message processing does not pass through Integration Advisor. Integration Advisor is where the definitions are produced. Trading Partner Management consumes those artefacts and generates the runtime configuration that Cloud Integration then executes against.

Architecturally the value is that partner-specific configuration lives in a partner management layer rather than being hard-coded into individual integration flows. An estate that handles each partner as a bespoke flow accumulates a maintenance problem that scales with partner count.

How SAP Integration Suite connects to on-premise systems

The common architecture runs from Integration Suite through SAP BTP Connectivity, through Cloud Connector, into the private network, and to the SAP or non-SAP system.

SAP describes Cloud Connector as a reverse-invoke proxy providing controlled access from SAP BTP to specifically exposed private-system resources without exposing the wider internal landscape. Two architectural properties follow from that. The connection is established outward from inside the private network, which avoids inbound firewall exposure. And only explicitly configured systems and resources are reachable, so the default posture is deny rather than allow.

What Cloud Connector is not is an integration or orchestration engine. It does not transform messages, route them, or execute integration logic. Treating it as middleware is a recurring architectural error and it appears in the anti-pattern section for that reason. Deeper coverage belongs in a dedicated Cloud Connector discussion.

Cloud Connector vs Edge Integration Cell

The distinction in one line: Cloud Connector connects the cloud runtime to private systems, while Edge Integration Cell allows supported integration workloads to execute inside a private environment.

Connectivity versus execution. Path versus processing.

Neither necessarily replaces the other, and framing the choice as either-or is a misreading. A hybrid architecture may well use both, since a workload executing on an Edge Integration Cell runtime may still need controlled access to systems it does not sit alongside.

It is also worth resisting the shorthand that Edge Integration Cell is simply Integration Suite on-premise. It is an optional customer-managed runtime for supported Integration Suite workloads in a private landscape, while cloud services continue to provide centralised design and management. The supported scope continues to evolve, so verify it against current SAP documentation for your own scenarios rather than working from a general description.

Standard cloud architecture versus hybrid architecture

Standard cloud architecture

Integration workloads execute on the SAP-managed cloud runtime. Design, deployment and monitoring happen in the cloud. Connectivity reaches cloud and SaaS systems directly and private systems through Cloud Connector where required.

In our view, for many scenarios the SAP-managed cloud runtime is the natural starting point, and hybrid execution should be introduced where a concrete requirement justifies it rather than as a preference.

Hybrid architecture with Edge Integration Cell

Design and management remain centralised in the cloud while supported workloads execute on a customer-managed runtime inside a private landscape. SAP describes Edge Integration Cell as Kubernetes-based and as a central component of Integration Suite's hybrid strategy.

The motivations SAP associates with it are specific: regulatory requirements, data locality, latency, private connectivity, and PI/PO transition scenarios. Each of those is testable against a given interface, which is the right way to scope hybrid rather than adopting it wholesale.

The trade-off is real and worth stating. A customer-managed runtime carries responsibilities the SAP-managed runtime does not. SAP's operating model for Edge Integration Cell assigns the customer provisioning of the Kubernetes resources it runs on, along with parts of change and user management. The precise split is detailed and continues to evolve, so check SAP's current operating model documentation rather than working from a general description.

The architectural consequence is the part that matters at decision time. Hybrid execution is not free, and the effort it adds is justified where a concrete requirement exists and hard to justify where one does not.

How should architects choose between APIs, integration flows, and events?

Starting points rather than rules. Every row below has exceptions driven by non-functional requirements:

SAP's ISA-M methodology advocates technology selection based on integration style, use-case pattern and customer context rather than a fixed mapping, which is the same principle expressed more formally. Pattern selection deserves its own treatment and gets it in SAP integration patterns.

How Integration Assessment and ISA-M support architecture decisions

SAP Integration Solution Advisory Methodology, ISA-M, is SAP's framework for mapping integration domains, styles, use-case patterns, customer context and technology choices into a governed enterprise integration strategy.

Integration Assessment operationalises elements of it. SAP describes it as a structured method for determining which integration technologies fit an organisation's requirements, supporting architects in documenting integration strategy, defining technology mappings, classifying integration requirements, applying policies, evaluating interface requests and obtaining technology recommendations.

Why this belongs in an architecture article rather than a governance one: the question it answers is which technology should handle a given interface. Most integration estates answer that question implicitly, by whichever tool the delivering team already knows. Answering it explicitly, with a documented policy, is what separates an architecture from an accumulation.

Security architecture considerations

At architecture level rather than configuration level, the concerns are authentication, authorisation, certificate and secret management, API policies, network boundaries, private connectivity, least privilege, runtime placement and data residency.

Two of those are specifically architectural rather than operational. Runtime placement determines where data is processed, which is the mechanism by which a data residency requirement is actually satisfied rather than merely documented. And network boundary design determines what is reachable at all, which is where Cloud Connector's properties matter: the reverse-invoke model means no inbound exposure, and only explicitly configured resources are accessible.

Identity propagation across a hybrid estate deserves attention early. How a caller's identity travels from an external consumer, through an API policy layer, through an integration runtime, and into a backend authorisation check is a design question that becomes expensive to answer retrospectively.

Monitoring and operational architecture

Most architecture diagrams stop at connectivity, which is one reason integration estates are frequently harder to operate than to build. In our view an architecture is incomplete until the team knows how the integrations will be run in production.

The operational concerns worth designing rather than inheriting:

• Message, API and event monitoring, and whether they present as one view or three

• Logging, including what is retained and what is deliberately not

• Alerting, and specifically who receives an alert and what they are expected to do

• Retry and replay behaviour, decided per interface rather than platform-wide

• Deployment lifecycle and transport across environments

• Support ownership and incident processes

• Architecture standards, and what stops the estate diverging from them

Retry and replay is the one most often deferred. Whether a failed message should be retried automatically, retried after intervention, or discarded is a business decision with an architectural expression, and it differs between a stock movement and a payment instruction.

SAP Integration Suite architecture for PI/PO modernisation

The architectural shift matters more here than the migration mechanics, which are covered separately in SAP PI/PO migration to SAP Integration Suite.

In many PI/PO-centric estates, a large share of application integration is concentrated in one middleware layer, with applications on both sides of it. Such estates often run more than one integration style and sometimes parallel middleware platforms alongside PI/PO, so the concentration is a matter of degree rather than an absolute.

A future-state architecture distributes what used to be one layer across several capabilities. Application and process integration into Cloud Integration. Governed exposure into API Management. Decoupled and asynchronous scenarios into events. Partner traffic into B2B capabilities. Optional Edge Integration Cell runtimes where data locality, latency or transition requirements justify them.

This is the architectural reason a one-to-one migration underdelivers. It preserves a single-style topology on a platform whose value comes from offering several. The estate moves and the architecture does not.

Common SAP Integration Suite architecture mistakes

These are IGT architectural observations rather than SAP-defined rules:

• Treating every requirement as an integration flow. Different integration styles call for different approaches, and familiarity with one tool is not an architectural argument

• Rebuilding point-to-point complexity in the cloud. Relocating technical debt does not reduce it

• Skipping API governance. APIs without lifecycle and security ownership produce a newer form of integration sprawl

• Ignoring events. Not every process needs synchronous request and response, and excessive synchronous coupling shows up as availability problems later

• Confusing connectivity with integration. Cloud Connector is a secure path, not an orchestration engine

• Designing only for development. Production monitoring, support, lifecycle and security belong in the architecture, not in a later phase

• Migrating before defining the target architecture. Particularly costly in PI/PO programmes, because conversion locks in whatever was decided beforehand

• Ignoring existing middleware. Large enterprises may need deliberate coexistence rather than immediate consolidation

The last one is worth dwelling on because it is the least discussed. Coexistence is a legitimate architecture when it is chosen, with a boundary that can be stated in one sentence. Splitting by workload characteristic tends to hold. Splitting by whichever team moved first tends not to, because the resulting rule cannot be explained to the next architect who joins.

A practical architecture decision framework

The following is IGT's simplified architecture approach, informed by established enterprise integration principles and by SAP ISA-M. It is our framework rather than an official SAP methodology.

• 1. Map the integration landscape. Applications, systems, partners and data flows, including the connections nobody documented

• 2. Identify integration domains. Cloud to cloud, cloud to private, internal, partner-facing

• 3. Identify integration styles. Process, API, event, B2B, data

• 4. Define non-functional requirements. Security, latency, volume, availability, compliance

• 5. Select capabilities. Cloud Integration, API Management, Event Mesh and others, including technologies outside Integration Suite where they fit better

• 6. Decide runtime placement. Cloud or private and hybrid, per workload rather than per platform

• 7. Define connectivity. Internet, Cloud Connector, private networking

• 8. Define governance and operations. Monitoring, ownership, security, DevOps, standards

Steps two to four carry most of the weight and attract the least enthusiasm, because they produce documents rather than demos. They are also what makes step five a decision instead of a default.

Our published enterprise SAP integration architecture case study works through this kind of reasoning at scale: one SAP ECC core, five factories, two different MES platforms and 41 integration points, built on a canonical transformation layer with shared integration logic, retry and replay, and a repeatable multi-factory model. That implementation used webMethods rather than SAP Integration Suite, and we reference it as evidence of enterprise integration architecture experience rather than as an Integration Suite example. The architectural decisions it involved, canonical modelling, master data ownership, and behaviour when a plant drops offline, arrive in the same form whichever platform executes them.

Conclusion

SAP Integration Suite architecture is not one diagram and not one runtime. Its shape depends on integration requirements and styles, connectivity, runtime location, security, operational requirements, existing middleware and enterprise governance.

The architectures that hold up tend to use the capabilities selectively and deliberately, rather than routing everything through the same implementation pattern because it is the pattern the team knows. The distinction between connectivity and processing, between design and execution, and between one integration style and another is what turns a platform into an architecture.

Designing a target architecture for SAP Integration Suite, or wanting an independent view of one already in progress? Our consulting team can support integration architecture review and technology selection, and our SAP integration services cover delivery.

See also: What is SAP Integration Suite?  ·  What is SAP BTP?  ·  SAP PI/PO migration

Sources

•      SAP Help Portal: SAP Integration Suite documentation

•      What Is SAP BTP? SAP Business Technology Platform Explained | IGT Systems

•      SAP Architecture Center, PI/PO to Integration Suite transition reference architectures

•      SAP: SAP Integration Suite product page

•      SAP: SAP Business Technology Platform product page