Introduction to SAP Integration Suite: Purpose, Architecture, and Tenant Model
Understand why SAP Integration Suite exists, how it fits into the BTP landscape, and how its tenant, subaccount, and capability model is structured before any configuration work begins.
Explanation
SAP Integration Suite is SAP's cloud-native integration platform, delivered on SAP BTP, that consolidates integration capabilities previously spread across separate tools such as SAP Process Orchestration (on-premise), SAP Cloud Platform Integration, and various API management offerings. Its purpose is to let consultants and developers build, run, monitor, and govern integrations between SAP systems (ECC, S/4HANA, SuccessFactors, Ariba, etc.) and non-SAP systems, using a single strategic platform rather than maintaining multiple middleware stacks. Architecturally, Integration Suite lives inside a BTP global account, under one or more subaccounts. A global account represents the commercial contract with SAP; subaccounts are the operational and technical boundaries where services, entitlements, and quotas are assigned. Within a subaccount you provision the Integration Suite service, which then requires you to 'onboard' or activate the specific capabilities you need: Cloud Integration (for message-based and orchestration-style integration flows, often called iFlows), API Management (for exposing, securing, and monitoring APIs), Integration Advisor (for B2B/EDI mapping guidance), Open Connectors, Trading Partner Management, and Migration Assessment tooling. Each capability is technically backed by its own runtime, but they share a common entry point in the Integration Suite launchpad and a common security and connectivity foundation. A critical concept for beginners is the distinction between the subaccount (a design-time and administrative container) and the actual runtime tenant of a capability, such as the Cloud Integration tenant. When you activate Cloud Integration, SAP provisions a dedicated runtime node associated with your subaccount; this is where integration flows are deployed and executed, separate from where you design and store them (the Design perspective, often backed by a Git-enabled workspace or the classic package model). Security in Integration Suite is anchored in the BTP identity model. Every subaccount is tied to an identity provider (SAP's default IdP or a customer's corporate IdP via trust configuration), and role collections control who can design, deploy, monitor, or administer content. This differs fundamentally from ECC/on-premise PI/PO, where authorizations were managed through classic ABAP roles and transaction-based access; in BTP, access is API- and role-collection driven, and understanding this shift is essential before touching any integration flow. Another foundational point: Integration Suite can run on Cloud Foundry as the primary runtime environment for most capabilities, while some newer or containerized scenarios may leverage Kyma (Kubernetes-based) environments within BTP. For most classical Cloud Integration and API Management scenarios, Cloud Foundry remains the typical runtime; Kyma is more relevant for custom extension scenarios or specific microservice-based integration patterns. Consultants should not assume Kyma is required or default — the choice depends on the entitlement and scenario architecture agreed for the project. Finally, because Integration Suite is a subscription-based cloud service, capacity (message processing units, API calls, etc.) is consumption-metered rather than sized via on-premise hardware sizing exercises. This has direct implications for cost governance and for how architects plan integration volume, which will be explored in later lessons of this topic.
Real project scenario
A retail company migrating from SAP PI/PO on ECC to S/4HANA Cloud engages a consultant to stand up SAP Integration Suite as the new middleware. Before any iFlow is built, the consultant must first explain to the customer's Basis and security teams that BTP works differently: they need a global account, a subaccount, entitlements for Cloud Integration and API Management, and role collections mapped to the corporate identity provider before design work can start. Misunderstanding this at kickoff typically delays the project by one to two sprints because procurement and security approvals for BTP entitlements were not initiated early enough.
Common mistakes
• Assuming Integration Suite is a single monolithic tool rather than a set of separately activated capabilities with distinct runtimes. • Confusing the BTP subaccount (administrative/design container) with the Cloud Integration runtime tenant, leading to wrong assumptions about where iFlows execute. • Treating BTP role collections as equivalent to classic ABAP authorization roles without adapting the security design process. • Assuming Kyma runtime is mandatory for all Integration Suite scenarios when Cloud Foundry is the typical runtime for most classical use cases. • Underestimating procurement/entitlement lead time because the project team is unfamiliar with BTP's subscription and quota model.
Best practices
• Confirm which Integration Suite capabilities are actually entitled and required for the project scope before starting design work. • Document the subaccount-to-capability-tenant mapping early so support teams understand where runtime issues must be investigated. • Align identity provider trust configuration with corporate IT before onboarding developers, to avoid last-minute access delays. • Clarify with the customer whether Cloud Foundry or Kyma (or both) will be used, based on actual scenario needs, not assumptions. • Establish a naming convention for subaccounts and capability tenants across dev/test/prod early in the project.
Interview angle
Interviewers commonly ask candidates to explain the difference between SAP Integration Suite and legacy SAP PI/PO, and to describe the relationship between global account, subaccount, and capability tenants. Being able to clearly separate design-time concepts (subaccount, packages) from runtime concepts (Cloud Integration tenant, deployed iFlows) signals real hands-on exposure rather than surface-level familiarity with marketing terminology.