Side-by-Side vs On-Stack: Die richtige Erweiterungsarchitektur wählen

Die Entscheidung zwischen Side-by-Side und On-Stack Erweiterungen gehört zu den wichtigsten Architekturentscheidungen in SAP-Projekten. Beide Ansätze haben ihre Berechtigung – die Kunst liegt darin, für jeden Anwendungsfall die richtige Wahl zu treffen.

Dieser Artikel analysiert beide Erweiterungsmodelle, ihre Stärken und Schwächen, und gibt praktische Entscheidungshilfen für Architekten und Entwicklungsteams.

Das Erweiterungsdilemma verstehen

SAP-Systeme erfordern regelmäßig Anpassungen an spezifische Geschäftsanforderungen. Die traditionelle Herangehensweise – direkte Modifikationen am System – hat sich als problematisch erwiesen: Upgrades werden erschwert, die Wartbarkeit leidet, und der Code entfernt sich immer weiter vom Standard.

SAP hat als Antwort zwei komplementäre Erweiterungsstrategien etabliert: On-Stack Erweiterungen, die direkt im S/4HANA-System laufen, und Side-by-Side Erweiterungen, die auf der SAP Business Technology Platform (BTP) außerhalb des Kernsystems implementiert werden.

On-Stack Erweiterungen im Detail

Definition und Konzept

On-Stack Erweiterungen werden direkt im S/4HANA-System entwickelt und ausgeführt. Sie nutzen freigegebene APIs und Erweiterungspunkte wie BAdIs, um SAP-Standardprozesse zu erweitern, ohne den Standard zu modifizieren. Bei S/4HANA Cloud Public Edition ist On-Stack die einzige Möglichkeit für Codebasierte Erweiterungen innerhalb des Systems.

Technische Grundlage

Die technische Basis bildet ABAP Cloud – eine eingeschränkte Version von ABAP, die nur freigegebene, stabile APIs zulässt. RAP (RESTful ABAP Programming) ist das bevorzugte Framework für die Entwicklung von Geschäftsobjekten, während CDS Views die Datenzugriffsschicht bilden.

On-Stack Erweiterungen teilen sich die Infrastruktur mit dem SAP-Standardsystem. Sie laufen in derselben Datenbankinstanz, nutzen dieselbe ABAP-Runtime und werden über dasselbe Transportwesen verwaltet.

Typische Anwendungsfälle

On-Stack eignet sich besonders für Szenarien, die enge Integration mit SAP-Standardprozessen erfordern. Validierungen bei der Dateneingabe, die in Echtzeit gegen bestehende Daten prüfen müssen, sind ein klassisches Beispiel. Auch Berechnungen, die im Kontext von Standardtransaktionen ausgeführt werden, oder Feldwertvorgaben basierend auf komplexer Logik gehören hierher.

Ein weiterer typischer Anwendungsfall sind Custom Fields – zusätzliche Felder auf Standardentitäten, die nahtlos in die Standardoberfläche integriert werden sollen. Die Key User Extensibility in S/4HANA Cloud ermöglicht dies sogar ohne ABAP-Entwicklung.

Side-by-Side Erweiterungen im Detail

Definition und Konzept

Side-by-Side Erweiterungen werden auf der SAP BTP entwickelt und betrieben, getrennt vom S/4HANA-Kernsystem. Sie kommunizieren mit S/4HANA über definierte APIs – typischerweise OData oder SOAP Services. Diese Architektur schafft eine klare Trennung zwischen dem ERP-Kern und der Erweiterungslogik.

Technische Grundlage

Die technische Vielfalt ist bei Side-by-Side größer. Das SAP Cloud Application Programming Model (CAP) mit Node.js oder Java ist die von SAP empfohlene Technologie, aber auch andere Sprachen und Frameworks sind möglich. Die Anwendungen werden in Cloud Foundry oder Kyma deployed und skalieren unabhängig vom S/4HANA-System.

Die Kommunikation erfolgt über APIs. Für den Zugriff auf S/4HANA-Daten kommen die im SAP API Business Hub dokumentierten Services zum Einsatz. Für Echtzeit-Events bietet SAP den Event Mesh als Message-Broker.

Typische Anwendungsfälle

Side-by-Side brilliert bei eigenständigen Anwendungen, die zwar SAP-Daten nutzen, aber ihre eigene Benutzeroberfläche und Geschäftslogik mitbringen. Spezialisierte Planungstools, Analytics-Dashboards oder Kundenportale sind klassische Beispiele.

Auch Szenarien mit hohen Skalierungsanforderungen oder spezifischen Technologieanforderungen – etwa Machine Learning Modelle – sind prädestiniert für Side-by-Side. Die BTP bietet Zugang zu Services, die im S/4HANA-Stack nicht verfügbar sind.

Entscheidungskriterien

Integrationsdichte

Das wichtigste Kriterium ist die erforderliche Integrationsdichte mit SAP-Standardprozessen. Wenn die Erweiterung tief in Standardtransaktionen eingebettet sein muss – etwa Validierungen während der Dateneingabe oder Felderweiterungen – ist On-Stack die richtige Wahl. Die Laufzeitintegration ermöglicht synchrones Verhalten ohne Netzwerklatenz.

Für lose gekoppelte Szenarien, bei denen die Erweiterung eigenständig agiert und nur punktuell Daten aus SAP benötigt, bietet Side-by-Side mehr Flexibilität und klare Grenzen.

Technologieanforderungen

ABAP Cloud ist mächtig, aber begrenzt. Wenn spezifische Technologien benötigt werden – moderne JavaScript-Frameworks, Python für Data Science, Microservice-Architekturen – führt kein Weg an Side-by-Side vorbei. Die BTP ermöglicht den Einsatz praktisch jeder Cloud-fähigen Technologie.

Andererseits: Wenn das Team stark in ABAP verwurzelt ist und die Anforderungen mit ABAP Cloud erfüllbar sind, kann On-Stack effizienter sein als der Aufbau neuer Technologiekompetenz.

Skalierung und Performance

On-Stack Erweiterungen teilen Ressourcen mit dem S/4HANA-System. Bei ressourcenintensiven Verarbeitungen kann dies problematisch werden. Side-by-Side ermöglicht unabhängige Skalierung – Erweiterungen können bei Lastspitzen hochfahren, ohne das ERP zu belasten.

Umgekehrt verursacht Side-by-Side Netzwerklatenz bei jedem API-Aufruf. Für Szenarien mit vielen kleinen, synchronen Zugriffen auf S/4HANA-Daten kann diese Latenz zum Problem werden.

Entwicklungs- und Betriebsmodell

Die Deployment-Modelle unterscheiden sich grundlegend. On-Stack folgt dem bewährten SAP-Transportwesen mit seinen Qualitätssicherungsprozessen. Side-by-Side ermöglicht moderne CI/CD-Pipelines mit automatisierten Tests und schnellen Release-Zyklen.

Auch im Betrieb gibt es Unterschiede: On-Stack wird mit dem S/4HANA-System gewartet, Side-by-Side erfordert separates Monitoring und Lifecycle Management.

Hybride Architekturen

In der Praxis ist oft eine Kombination beider Ansätze optimal. Eine typische hybride Architektur nutzt On-Stack für Erweiterungen, die tief in Standardprozesse integriert sind, und Side-by-Side für eigenständige Anwendungen und spezialisierte Funktionen.

Die Kommunikation zwischen beiden Welten erfolgt über Events und APIs. Ein Kundenportal auf BTP kann beispielsweise bei einer Bestelländerung durch den Kunden ein Event an S/4HANA senden, wo On-Stack Logik die Validierung und Verarbeitung übernimmt.

Migrationspfade

Bestehende Erweiterungen müssen nicht zwingend migriert werden, aber die Entscheidung sollte bewusst getroffen werden. Klassische On-Premise-Erweiterungen können oft zu On-Stack ABAP Cloud migriert werden, wenn sie auf freigegebene APIs umgestellt werden.

Für die Migration nach Side-by-Side muss die Funktionalität meist neu implementiert werden, da sich Technologie und Architektur grundlegend unterscheiden. Dies kann eine Gelegenheit zur Modernisierung sein, erfordert aber entsprechenden Aufwand.

Governance und Standards

Unabhängig von der gewählten Architektur sind klare Governance-Regeln wichtig. Entscheidungsbäume helfen Teams, für neue Anforderungen schnell das richtige Modell zu wählen. Dokumentierte Standards für Schnittstellen, Namenskonventionen und Qualitätskriterien sichern die langfristige Wartbarkeit.

Ein Erweiterungskatalog dokumentiert alle existierenden Erweiterungen mit ihrem Typ, Zweck und Abhängigkeiten. Dies verhindert Doppelentwicklungen und erleichtert die Auswirkungsanalyse bei Änderungen.

Fazit

Weder Side-by-Side noch On-Stack ist generell überlegen – beide haben ihren Platz in einer modernen SAP-Architektur. Die Entscheidung sollte auf Basis objektiver Kriterien getroffen werden: Integrationsdichte, Technologieanforderungen, Skalierungsbedarf und Betriebsmodell.

In der Praxis bewährt sich ein pragmatischer Ansatz: On-Stack für alles, was eng mit dem ERP-Kern verwoben ist, Side-by-Side für eigenständige Anwendungen und moderne Technologien. Mit klarer Governance und konsistenten Entscheidungsprozessen können beide Modelle harmonisch koexistieren und gemeinsam die Geschäftsanforderungen erfüllen.