Choosing Integration Patterns: Point-to-Point, Middleware and API-Led Approaches
Compares core integration patterns available to SAP architects and the trade-offs between direct connections, middleware-brokered flows and API-led design across ECC and S/4HANA landscapes.
Explanation
Integration architecture decisions begin with pattern selection, and the wrong choice early in a program creates technical debt that is expensive to unwind later. Three broad patterns recur across SAP landscapes: point-to-point connections, middleware-brokered integration, and API-led connectivity built around reusable, governed interfaces. Point-to-point integration connects two systems directly, commonly using RFC destinations, direct database links, or simple web service calls. This pattern is fast to build and easy to understand for a single interface, which is why it appears frequently in legacy ECC landscapes accumulated over many years. The problem is combinatorial: as the number of connected systems grows, the number of point-to-point links grows much faster, and each link embeds business logic, error handling, and authentication logic independently. There is no single place to monitor traffic, apply consistent security policy, or version an interface without touching every consumer. In practice, point-to-point integration is acceptable only for a small, stable number of interfaces where the coupling risk is understood and accepted, such as a tightly controlled interface between two systems owned by the same team with no reuse expectation. Middleware-brokered integration introduces a mediating layer, historically SAP Process Integration/Process Orchestration on-premise, and increasingly SAP Integration Suite on BTP for cloud-first landscapes. Middleware centralizes mapping, routing, monitoring, and error handling. It decouples senders and receivers so that an interface change on one side does not necessarily require changes on the other. The cost is added latency, an additional system to operate and patch, and a potential single point of failure if high availability is not designed in. Middleware also introduces governance overhead: someone must own interface design standards, naming conventions, and lifecycle management, or the middleware layer becomes just as tangled as point-to-point sprawl, only centralized. API-led connectivity extends the middleware concept with explicit layering: system APIs expose backend capabilities in a stable, coarse-grained way; process APIs orchestrate business logic across multiple systems; and experience APIs tailor data for specific consumers such as mobile apps or portals. This layering, often implemented using SAP Integration Suite's API Management capabilities alongside OData or REST services exposed from S/4HANA, allows reuse and independent evolution of each layer. It is the recommended direction for clean core-aligned S/4HANA landscapes because it keeps custom logic out of the ERP core and pushes orchestration into the integration layer or side-by-side extensions. A critical intermediate-level skill is recognizing when each pattern is proportionate. Not every interface needs full API-led layering; a simple, stable, low-volume interface between two internal systems may not justify the governance overhead. Conversely, customer-facing or high-change-frequency interfaces benefit strongly from API-led design because they need versioning, throttling, and security policies that ad hoc point-to-point links cannot provide consistently. Architects should document the decision criteria explicitly rather than defaulting to whatever pattern the current team is most familiar with. S/4HANA and cloud differences matter here. On-premise and private cloud editions retain flexibility to expose classic RFC or IDoc-based interfaces alongside modern APIs, but public cloud editions restrict extensibility to released APIs and events, which pushes architecture naturally toward API-led patterns and away from direct RFC or table-level access. This is a deliberate constraint, not a limitation to work around, because it protects upgradability.
Real project scenario
A retail company migrating from ECC to S/4HANA private cloud inherited over forty point-to-point RFC interfaces built over a decade. During the transition program, the architecture team classified each interface by business criticality and change frequency, then migrated the dozen highest-change interfaces to SAP Integration Suite with API-led layering, while leaving stable, low-risk interfaces as direct connections to avoid unnecessary rework. This proportional approach kept the migration budget realistic while addressing the interfaces most likely to cause future maintenance pain.
Common mistakes
• Defaulting to point-to-point for every interface because it is the fastest way to hit a project deadline, without considering long-term maintenance cost • Introducing middleware for all interfaces without a governance model, resulting in a centralized version of the same sprawl problem • Assuming API-led connectivity is always correct regardless of interface volume, criticality, or team maturity • Failing to document pattern-selection criteria, leading to inconsistent architecture decisions across project teams • Ignoring public cloud extensibility restrictions and designing interfaces that assume on-premise-level access
Best practices
• Establish written criteria for pattern selection covering criticality, change frequency, and reuse potential before interfaces are built • Reserve full API-led layering for interfaces that genuinely need versioning, reuse, or external exposure • Track technical debt from legacy point-to-point interfaces and plan gradual migration rather than a disruptive big-bang rebuild • Align integration pattern strategy with the target S/4HANA deployment model's extensibility rules early in the program • Review pattern decisions periodically since interface criticality can change as the business evolves
Interview angle
Interviewers assess whether candidates can justify pattern choices with explicit criteria rather than reciting textbook definitions. Be ready to explain a real decision where you chose point-to-point over middleware, or vice versa, and what business or technical factors drove that choice, including cost, team capability, and expected interface lifespan.