Integration Architecture Is a Contract Before It Is a Tool

A field manual for choosing the obligation, pattern and operating boundary before the SAP service

Altivate | Published 3 May 2026 | Updated 26 July 2026

1. Product catalogues do not define an integration architecture

There is a great deal of written material about SAP Integration Suite. Very little of it names its sources, and some of it repeats figures that SAP’s own documentation contradicts.

That matters more than it used to, because a reference document is now read by two audiences. An integration architect reads it to make a decision. A retrieval system reads it to answer somebody else’s question – and it cannot tell a checked number from an unchecked one. Publishing a wrong number today means propagating it.

The problem is not merely factual hygiene. A product count encourages teams to map one service to one interface. Architecture begins one level higher: the business obligation, its failure semantics, ownership, latency and change path. The checked reference below is useful because it keeps the tools accurate. The field manual matters because it prevents those tools from becoming the design.

2. The corrections

Each row is a claim in general circulation, checked against SAP’s own documentation. Sources are in full at the end.

Confirmed on checking – previously resting on third-party reporting, now traced to SAP:

• PI/PO maintenance to 2027, extended to 2030. Previously partner-blog-only. Now anchored to SAP’s own statements (§7).
• The BTP Neo environment sunsets 31 December 2028. Previously SAPinsider only. Now in SAP’s own documentation (§7).
• Trading Partner Management’s scope – confirmed and, it turns out, broader than usually described (§8).
• The BTP region footprint for the Gulf and India – confirmed across three separate SAP documents, and narrower than the source most people reach for (§9).
• Cloud Foundry / Kyma “SLA parity” – true, but not in the way it is usually meant. SAP’s SLA sets one commitment for the whole Cloud Service and never separates the environments, so there is no comparison to make. A plan-gated difference in high availability survives underneath it (§6).
• Advanced Event Mesh’s limits – confirmed, and materially more tiered than the flat figures in circulation (§5).

The content library is material, but the unit matters. SAP’s current commercial page describes more than 3,400 prebuilt integrations and more than 200 connectors. Those are different assets, not interchangeable measures. Use the prebuilt content only after confirming that it fits the required system version, message standard, country process and operating model.

3. What SAP Integration Suite is

SAP Integration Suite is SAP’s vendor-managed, multi-cloud integration platform on SAP Business Technology Platform. Its capability set, as SAP itself lists it, is:

Two things follow that most summaries omit.

The count is ten as SAP structures it, eleven if you count products. SAP groups Cloud Integration and API Management as a single entry. We quote SAP’s own structure rather than re-cutting it, but if you are matching this against a product list, expect the off-by-one.

Do not assume you have all of them. SAP’s documentation states plainly that “the availability of capabilities for activation is dependent on your SAP Integration Suite service plan.” Two of the last three entries in that table – Integration Assessment and Migration Assessment – are precisely the ones an organisation planning a PI/PO migration would want, and precisely the ones most likely to prompt a service-plan conversation. Check your plan against the list before you design around a capability.

Platform overview: SAP Business Technology Platform.

4. Choosing a pattern before choosing a tool

The most useful framework we found is not a capability table at all. SAP PRESS – an independent publisher covering SAP, not SAP itself – published a decision framework in May 2026 built on five questions asked before any tool is selected: trigger type, volume and frequency, latency requirement, deployment model, and target-system ownership. Its central observation is worth quoting directly, because it matches what integration projects actually fail on:

Mapping those five questions onto the capability set gives the following. Read the last column first – the failure mode is the part that costs money.

The inverse mistake is equally expensive and less discussed: using a bulk data-replication tool for a transactional process introduces latency and breaks auditability. The failure is symmetric. Both directions come from the same root cause – choosing the tool before characterising the pattern.

Two further failure modes deserve an architecture-record test: overlapping integration runtimes without clear ownership, and distributed workflows without compensation or replay logic. The test is operational rather than rhetorical: name the runtime of record, the recovery owner, the replay boundary and the evidence retained after a partial failure.

Related: bridging the integration gap and end-to-end integration in CPG.

5. Event Mesh: the numbers to design against

This is where an unchecked figure does real damage, because capacity planning is arithmetic.

SAP’s own Event Mesh scope documentation gives these limits:

The commonly circulated storage figure is 10 GB. SAP’s documentation says 2 GB. If you have sized a backlog window against 10 GB, that window is five times shorter than you think – and a spool ceiling is the limit you discover during an incident, when a consumer has been down and messages have been accumulating.

SAP Integration Suite, Advanced Event Mesh is a different product, built on Solace PubSub+, and is one SAP-portfolio option when the standard limits do not fit: enterprise protocols including JMS, larger messages, far larger spool, and on-premise support. It is not an automatic answer. Compare the contracted AEM tier with a third-party broker, workload redesign and data-replication patterns before adding a second messaging plane.

Its limits are usually quoted as a flat “30 MB messages, 1 TB spool.” Both figures are real, and both are more conditional than that. SAP does not publish them; they come from Solace’s own service-class documentation, Solace being the platform SAP resells under this name. Read there, they are tiered:

• The 30 MB message ceiling applies from the Enterprise 5K tier upward. Entry tiers cap at 10 MB.
• 1 TB is the Enterprise 100K tier’s default spool, not a ceiling. It is expandable to 6 TB, and smaller tiers default as low as 25 GB.

That distinction matters at sizing time. An architect on an entry tier reading “1 TB” will plan against roughly forty times the spool they will actually be given. Confirmed against Solace, not against SAP – a real limitation on the sourcing, and one worth stating, but a different thing from unverifiable.

The practical rule: if your design approaches 1 MB per message or 2 GB of spool, evaluate Advanced Event Mesh as an option rather than assuming it is required. Compare the workload, operating model, alternatives and contracted tier; limits and availability can vary by service plan and contract, so the relevant limit is the one written into the proposed service.

6. Cloud Foundry, Kyma and ABAP sit inside a contractual hierarchy

The three BTP environments, and what each is for:

• ABAP environment – extending ABAP-based products such as S/4HANA, in-app or side-by-side. If your extension is ABAP, this is the answer and the decision is over.
• Cloud Foundry environment – polyglot cloud applications on an open PaaS, with the simplest operational model of the three.
• Kyma environment – Kubernetes-native workloads: microservices and serverless functions needing Kubernetes primitives, a service mesh, or custom containers.

Do not compare Cloud Foundry and Kyma by repeating a generic “SLA parity” claim. SAP’s current global Cloud Services SLA sets a 99.7% default System Availability SLA, while product-specific supplements, service descriptions and the order form can override it. Those contractual documents do not establish three environment-level commitments that can be compared side by side. The signed service and order documents remain the authority.

Resilience is not entirely uniform below the SLA line. SAP’s availability-zone documentation describes Cloud Foundry as multi-AZ without qualification – “Multiple AZs exist in one region and are connected with each other through a low-latency network” – while Kyma’s three-AZ high availability is scoped: “By operating on a three-availability-zone architecture, Kyma offers the high availability feature within the following enterprise plans.” One contractual SLA; a plan-gated HA feature on one side and not the other. If resilience is a stated requirement, confirm what your specific plan includes rather than reasoning from the SLA alone.

The decision is therefore architectural and contractual. Match the runtime to the workload, then verify the availability and resilience terms of the specific subscribed service and plan.

In more depth: a comprehensive guide to SAP BTP environments.

7. Two retirement clocks, both now confirmed against SAP

These create the budget urgency, and both were previously resting on third-party reporting. Both now trace to SAP.

PI/PO – mainstream maintenance to end of 2027, extended to end of 2030

SAP’s maintained NetWeaver 7.5 maintenance page names SAP Process Integration and SAP Process Orchestration release 7.5 directly: mainstream maintenance to the end of 2027 and extended maintenance to the end of 2030. SAP Knowledge Base and Community material corroborate those dates. Confirm the terms that apply to you against your contract, since extended maintenance is a paid option rather than an automatic entitlement.

Why this clock matters more than the other one: it applies to the large installed base of ECC-era customers running PI/PO, which is a far larger population than the one affected below. Note also that Migration Assessment, one of the ten capabilities in §3, exists specifically to evaluate a PI/PO estate for this move – and its availability depends on your service plan.

BTP Neo environment – sunsets 31 December 2028

SAP’s own documentation states it plainly: “SAP Business Technology Platform, Neo environment will sunset on December 31, 2028, subject to terms of customer or partner contracts.” An SAP employee’s Community post from June 2023 gives the same date with no extension mentioned.

Note the conditional – subject to terms of customer or partner contracts – which means your contract is the authority, not the blog post you read. Anything still running on Neo must move to Cloud Foundry, Kyma or the ABAP environment. Neo remains a documented, distinct environment in SAP’s current documentation with active migration content; it has not been quietly folded away.

8. Trading Partner Management – broader than usually described

Confirmed against SAP’s documentation, and the confirmed scope is wider than most summaries give:

• Partner profiles and agreements – “Create and maintain trading partner profiles with their B2B requirements.”
• Communication protocols – AS2, SFTP, FTP.
• Type systems – ASC X12 and UN/EDIFACT, and also SOAP and IDoc, which are routinely omitted from third-party descriptions. SAP’s documentation is explicit that “selecting the type determines the B2B standard based on which the B2B transaction takes place.”

The IDoc inclusion is the practically significant one for an SAP-centric landscape: it means partner exchange and IDoc-based backend integration sit inside the same managed capability rather than requiring a separate bridge.

9. Gulf and India: BTP regions are not the data-centre list

This section addresses a specific, easy and consequential category error.

SAP publishes a document called Location of Data Centers utilized for SAP Cloud Services, current edition v.1-2025. For Saudi Arabia, the UAE and India it lists a generous set of cities: Riyadh and Dammam; Abu Dhabi and Dubai; Chennai, Delhi, Hyderabad, Mumbai and Pune.

That document does not provide BTP region availability. It is a catalogue covering many SAP cloud services, and the cities above appear against other named products. A city in the catalogue is therefore not evidence that the required BTP environment or service is available there.

So a city appearing in that document is not evidence of BTP availability there. The BTP environment documentation is the only valid source for a BTP region claim, and it describes a narrower footprint. Confirmed consistently across three separate SAP documents – the Cloud Foundry, Kyma and ABAP environment region pages:

Not Riyadh. Not Abu Dhabi. Not Chennai, Delhi, Hyderabad or Pune. Those cities host SAP cloud services – just not BTP.

For a buyer with a data-residency obligation this is the difference between a compliant design and a finding. If a proposal cites the data-centre list as evidence of in-country BTP hosting, the document does not support that claim, and the region pages are where to look instead.

10. The open items belong in the architecture record

Advanced Event Mesh limits are sourced to Solace; UAE availability for the ABAP environment is unestablished; and service-plan gating is not mapped capability by capability here. The published content and connector counts are useful discovery signals, not proof that a specific asset fits. RISE entitlement and BTPEA consumption must come from the signed contract.

Do not hide those items in meeting notes. Put them in the architecture decision record with an owner, evidence standard and date. An unresolved fact is manageable. An unrecorded assumption is how integration debt begins.

11. The executive agenda

1. Inventory interfaces by business obligation, owner, failure consequence and change frequency.
2. Select the contract – API, message, event or partner document – before selecting the runtime.
3. Treat PI/PO end-2027 and Neo end-2028 as programme clocks, not platform trivia.
4. Verify service-plan entitlement and regional availability against the proposed contract.
5. Fund observability, replay, certificate rotation and recovery as part of every integration.

Altivate provides SAP advisory and implementation services and therefore has a commercial interest in this market. The useful assessment is not “which Integration Suite services do we own?” It is “which business obligations are currently depending on an accidental design?”

Review SAP BTPEA entitlement, or return to White Papers.

Sources and verification status

Checked 26 July 2026. Links below point to the decision-bearing primary documents.

SAP primary – all [read]

• Capabilities of SAP Integration Suite
• the ten-entry capability list (§3).
• Activating and Managing Capabilities
• service-plan dependency of capability availability (§3).
• Connectivity Options for SAP Integration Suite – the current “more than 170 non-SAP cloud applications” statement (§2, §3).
• SAP Integration Suite pricing and packaging – the current “more than 3,400 prebuilt integrations” and “more than 200 connectors” statements, with commercial context (§2).
• Event Mesh Scope
• all limits in §5, including the corrected 2 GB spool and 1 MB message size.
• Understanding the Basic Concepts
• Trading Partner Management protocols and type systems, including SOAP and IDoc (§8).
• Availability Zones in the Cloud Foundry Environment and Available Plans in the Kyma Environment
• Cloud Foundry’s multi-AZ posture and Kyma’s plan-qualified high availability (§6).
• Service Level Agreement for Cloud Services and SAP BTP Service Description Guide
• the current contractual hierarchy and 99.7% default, subject to service-specific terms (§6).
• SAP Community topic page, SAP NetWeaver 7.5 Maintenance Strategy – a maintained reference page, not a dated post; names SAP Process Integration and SAP Process Orchestration release 7.5 with mainstream maintenance to end 2027 and extended to end 2030 (§7). This is the lead source for that date.
• Regions and API Endpoints for Cloud Foundry, Regions for Kyma and Regions and API Endpoints for ABAP
• the environment-specific region evidence behind §9.
• Neo Environment: Troubleshooting
• SAP’s current 31 December 2028 sunset notice (§7).
• Location of Data Centers utilized for SAP Cloud Services, v.1-2025 – confirmed as the current edition from its own title; searched in full and found to contain no BTP entry (§9).
• SAP Knowledge Base Article 3463462 – NetWeaver 7.50 Application Server Java maintenance to end 2027, extended to end 2030 (§7). Preview text only; full article is login-gated.
• SAP Community, Process Integration (PI): Way Forward and Recommended Actions (3 August 2020), “Technology Blog Posts by SAP”, SAP-authored – PI 7.5 named explicitly with the 2027/2030 dates (§7). Six years old; flagged as such in the text.
• SAP Community, Neo environment sunset Q&A (June 2023), SAP-authored – corroborates the 2028 date.

Independent publisher

• SAP PRESS, How to Choose an SAP Integration Pattern: A Decision Framework (May 2026): [read] the five-question framework and the pattern-to-tool mapping underlying §4. SAP PRESS publishes about SAP; it is not SAP.

Platform vendor – [read]

• Solace, Service Class Options and Configuring Message Spool Sizes
• the tiered Advanced Event Mesh limits in §5: a 30 MB message ceiling from the Enterprise 5K tier upward, 10 MB below it, and per-tier default spool from 25 GB to 1 TB, expandable to 6 TB. Solace is the platform SAP resells as Advanced Event Mesh. Confirmed against Solace, not against SAP – stated as such in §5 and §11.