Designing Hybrid Integration Architecture for Clean Core S/4HANA Landscapes
Explains how to design a hybrid integration architecture that combines synchronous and event-driven integration on BTP while keeping the S/4HANA core clean, addressing NFRs, security, and governance.
Explanation
Hybrid integration architecture refers to landscapes that combine multiple integration styles, synchronous APIs, asynchronous messaging, event-driven flows, and batch data movement, orchestrated deliberately rather than accumulated by accident. This is the reality of most S/4HANA programs pursuing clean core principles, because no single integration style satisfies every scenario: real-time order status checks need synchronous APIs, high-volume master data replication benefits from asynchronous batch or event patterns, and cross-application business processes often need event-driven choreography to avoid tight coupling. A well-designed hybrid architecture typically layers around SAP Integration Suite on BTP as the central nervous system, using its Cloud Integration capability for message-based flows, API Management for governed synchronous access, and, where the landscape includes event-driven processes, the SAP Event Mesh or equivalent event broker for publish-subscribe patterns. The S/4HANA core exposes released APIs and business events rather than allowing direct table or RFC-level access from external systems, which is the technical expression of the clean core principle: business logic and data access stay inside the ERP's supported interface layer, while orchestration, transformation, and custom extension logic live in the integration or side-by-side extension layer. Event-driven integration deserves particular attention at the advanced level because it changes failure semantics compared to synchronous point-to-point calls. When a sales order event is published, multiple subscribers, such as a warehouse system, a customer notification service, and an analytics platform, can consume it independently. This improves scalability and decouples release cycles, but it introduces eventual consistency: subscribers may process the event at different times, and the architecture must define what happens if a subscriber is down when the event fires. Options include event replay capability, dead-letter queues, and idempotent consumer design so that reprocessing a duplicate event does not corrupt data. These are not optional details; they are core NFRs that must be designed before go-live, because retrofitting idempotency into a production event consumer under pressure is far riskier than designing it up front. Security in a hybrid architecture must be layered rather than assumed to be handled once at the network boundary. Synchronous APIs need OAuth-based authentication and authorization scoped to the minimum required access, ideally managed centrally through API Management policies rather than duplicated per interface. Event brokers need topic-level access control so that a compromised or misconfigured consumer cannot subscribe to sensitive business events. Data in transit needs TLS everywhere, including internal BTP-to-on-premise connections typically routed through SAP Cloud Connector, which itself requires careful configuration of exposed on-premise system resources to avoid over-broad access. Governance is what keeps a hybrid architecture from degrading into the same sprawl problem it was designed to prevent. This means a documented interface catalog, naming and versioning standards, a review gate before new interfaces go live, and clear ownership for each integration artifact including who monitors it and who is paged when it fails. Without this governance layer, teams tend to build ad hoc point-to-point workarounds when the sanctioned integration path feels slow, quietly reintroducing the coupling problem the hybrid architecture was meant to solve. Migration and rollback considerations differ from ECC-era integration: because public cloud S/4HANA restricts direct access, migrating existing point-to-point interfaces often requires rebuilding them against released APIs, which is a genuine re-architecture effort, not a lift-and-shift. Rollback planning for a hybrid integration cutover should include the ability to run old and new interfaces in parallel during a transition window, with reconciliation checks confirming that message counts and business outcomes match before decommissioning the legacy path.
Real project scenario
A manufacturing company building a private cloud S/4HANA landscape with side-by-side extensions on BTP needed to replicate material master changes to a legacy warehouse management system and simultaneously notify a customer portal of stock changes in near real time. The architecture team used SAP Integration Suite for governed API access to the warehouse system and an event-driven flow through a business event for the portal notification, with a dead-letter queue and scheduled replay job to handle portal downtime. During cutover, both the old direct database replication job and the new event-driven flow ran in parallel for three weeks with daily reconciliation reports before the legacy job was decommissioned.
Common mistakes
• Treating event-driven integration as fire-and-forget without designing for duplicate delivery, out-of-order events, or subscriber downtime • Centralizing security policy enforcement inconsistently, leaving some interfaces authenticated through API Management and others bypassing it • Skipping an interface governance catalog, resulting in duplicate or conflicting interfaces built by different teams • Underestimating the re-architecture effort required to move legacy point-to-point interfaces to released APIs during a public cloud migration • Decommissioning legacy integration paths before reconciliation confirms the new hybrid flow produces equivalent business outcomes
Best practices
• Define idempotent consumer logic and dead-letter handling before any event-driven interface goes live, not after the first production incident • Route all synchronous external access through centrally governed API Management policies rather than ad hoc authentication per interface • Maintain a living interface catalog documenting ownership, versioning, and monitoring responsibility for every integration artifact • Plan parallel-run and reconciliation periods for any migration replacing legacy point-to-point interfaces with hybrid API or event-driven flows • Configure Cloud Connector exposure narrowly, granting only the specific on-premise resources each cloud consumer actually requires
Interview angle
Architect-level interviews often probe how a candidate handles eventual consistency and failure recovery in event-driven flows, not just whether they can name the tools involved. Be prepared to describe a concrete idempotency or replay mechanism you designed, and how you decided which interfaces needed synchronous versus event-driven treatment.