Architektur-Deep Dive: SAP BTP, Integration Suite und der Paradigmenwechsel zum Clean Core

Die Welt der Enterprise-IT und insbesondere der SAP-Architekturen befindet sich in einem tektonischen Wandel. Vorbei sind die Zeiten monolithischer ERP-Giganten, in denen Modifikationen tief im proprietären Quellcode verankert wurden, was unweigerlich zu massiven technischen Schulden und endlosen Update-Zyklen führte. Aus meiner Perspektive als Enterprise-Architekt ist die SAP Business Technology Platform (BTP) nicht einfach nur ein neues Produkt, sondern das technologische Fundament für zukunftssichere, entkoppelte Systemlandschaften. BTP adressiert exakt die gewachsenen Schmerzen verteilter Datensilos und schwerfälliger ERP-Kerne. In dieser detaillierten Architekturanalyse verknüpfen wir historisch gewachsenes Basiswissen mit den aktuellen Entwicklungen rund um die BTP, die SAP Integration Suite und die unvermeidliche Migration von Alt-Systemen wie SAP PI/PO.

Die architektonische Basis: SAP BTP als offenes Multi-Cloud-Fundament

Die SAP BTP operiert als klassische Platform-as-a-Service (PaaS) und fungiert als Brücke zwischen den bestehenden On-Premise-Systemen und modernsten Cloud-Technologien. Um die Abhängigkeit von einem einzigen Provider zu durchbrechen, ist die Plattform als Multi-Cloud-Architektur konzipiert. Sie lässt sich nahtlos auf den Infrastrukturen der großen Hyperscaler wie AWS, Microsoft Azure, Google Cloud und der Alibaba Cloud deployen. Dies bietet uns Architekten die Flexibilität, regulatorische Compliance-Anforderungen oder regionale Gegebenheiten (z. B. Rechenzentren in Frankfurt) exakt auszusteuern.

Struktur und Laufzeitumgebungen (Runtime Environments)

Auf administrativer Ebene stützt sich die BTP auf ein strenges Kontenmodell. Unterhalb eines Master-Vertrags existiert der Global Account, welcher in diverse Sub-Accounts untergliedert wird. Best Practices der Architektur verlangen hier eine strikte Mandantentrennung – sei es nach Entwicklungs-, Test- und Produktivumgebungen (zwei- oder dreistufig) oder nach spezifischen Lines of Business (LoB).

Technologisch bietet die BTP für die Entwicklung eigener Erweiterungen (Side-by-Side Extensibility) drei primäre Laufzeitumgebungen:

• Cloud Foundry Environment: Der de-facto Standard für Polyglot-Microservices. Hier können Anwendungen in Sprachen wie Node.js, Java oder im SAP-spezifischen UI5-Framework betrieben werden.

• Kyma / Kubernetes Environment: Für hochskalierbare, containerisierte Microservices, die die volle Orchestrierungs-Power von Kubernetes benötigen.

• ABAP Environment ("Steampunk"): Eine revolutionäre Neuerung für traditionelle SAP-Entwicklungsteams. Es handelt sich um eine kontrollierte "ABAP Light-Version" direkt in der Cloud, mit der ABAP-basierte Erweiterungen gebaut werden können, ohne den ERP-Kern zu kontaminieren.

Diese Runtimes werden ergänzt durch eine Vielzahl an gemanagten Services, darunter Datenbanken wie die SAP HANA Cloud, Analytics-Lösungen (SAP Analytics Cloud, SAP Datasphere, Business Data Cloud) und IAM-Komponenten (Cloud Identity Services), die nahtlos via Single Sign-On an Corporate-Identity-Provider wie Microsoft Entra ID oder Okta gekoppelt werden. Ein wichtiger Wandel für Entwickler: Die alte SAP Web IDE (Neo-Umgebung), deren Support 2027 abläuft, wird durch das SAP Business Application Studio (BAS) auf Cloud Foundry abgelöst. Alternativ positioniert die SAP das neue SAP Build Code, welches das BAS um mächtige KI-Funktionen für die Code-Generierung anreichert.

Das Clean Core Paradigma: Paradigmenwechsel in der Erweiterbarkeit

Der historische Fehler vieler SAP-Implementierungen war die direkte Modifikation des ERP-Standardcodes (Customizing und User Exits). Dies führte zu extrem hohen Kosten bei Upgrades. Die BTP ist der Enabler der Clean Core Strategie. Jeglicher Custom-Code wandert aus dem digitalen Kern (SAP S/4HANA oder ECC) hinaus auf die BTP.

Ein technisches Beispiel: Statt einen hochkomplexen Kalkulationsalgorithmus tief im S/4HANA zu programmieren, wird dieser als eigenständiger Microservice auf der BTP realisiert. Das S/4HANA ruft diesen Service synchron via OData-API oder asynchron über Events auf. Das ERP-System bleibt komplett im Standard, ist jederzeit upgradefähig und die IT-Landschaft gewinnt massiv an Agilität.

SAP Integration Suite: Das neue Herzstück der Enterprise-Architektur

Historisch gesehen litten viele Unternehmen unter einem massiven "Integrationswildwuchs" – eine unkontrollierbare Menge an Punkt-zu-Punkt-Verbindungen, mangelnde Governance und eine extrem fehleranfällige, heterogene Middleware-Landschaft. Die SAP Integration Suite, eine vollumfängliche Integration Platform as a Service (iPaaS), ist SAPs strategische Antwort auf dieses Chaos. Sie vereint Modulbaukästen, die alle Facetten moderner Integrationstypologien (A2A, B2B, B2G, Ground-to-Cloud) abdecken. Werfen wir einen tiefen Blick auf die Architekturkomponenten:

1. Cloud Integration (ehemals CPI) Der technische Kern der Suite. Hier werden Geschäftsprozesse über Systemgrenzen hinweg mittels sogenannter Integration Flows (iFlows) modelliert. Entwickler nutzen eine grafische Modellierungsumgebung für das Routing, Mapping und die Konvertierung von Payloads. Die Adaptervielfalt ist enorm und reicht von klassischen Protokollen wie HTTP, SFTP und JDBC über etablierte SAP-Formate (IDoc) bis hin zum modernen OData-Standard. Tausende vorgefertigte Integration Packs im SAP API Business Hub reduzieren die Time-to-Market drastisch.

2. SAP API Management Wer Microservices baut, muss APIs verwalten. Das API Management fungiert als zentrales Portal, um existierende SAP- und Non-SAP-Backends sicher als API-Proxies zu exponieren. Der Fokus liegt hier auf Security und Traffic Governance. Entwickler können den API-Lifecycle versionieren und über 40 vordefinierte Policies anwenden, beispielsweise für Autorisierung (OAuth 2.0, SAML), Rate Limiting (Schutz vor DDoS-Spitzen) oder Caching. Sogar die Monetarisierung von API-Aufrufen ist nativ integriert.

3. Event Mesh (Event-Driven Architecture) Dies ist architektonisch vielleicht der spannendste Baustein. Anstatt auf starre, synchrone Punkt-zu-Punkt-Aufrufe zu setzen (die bei Lastspitzen zum Systemversagen führen können), implementiert Event Mesh eine asynchrone Event-Driven Architecture (EDA). Ein SAP S/4HANA publiziert beispielsweise das Event "Auftrag erstellt". Das Event Mesh fungiert als Event-Broker-Netzwerk, puffert die Nachricht und verteilt sie in Echtzeit an abonnierte Drittsysteme (z. B. Salesforce, Data Lakes). Dies entkoppelt Systeme radikal, erhöht die Ausfallsicherheit und fängt Lastspitzen im Millisekundenbereich ab.

4. Integration Advisor & Open Connectors Der Integration Advisor nutzt Machine Learning und die "Schwarmintelligenz" globaler SAP-Projekte (Crowdsourcing), um komplexe B2B-Mappings wie EDIFACT hochgradig zu automatisieren. Die Open Connectors wiederum liefern über 170 vorgefertigte Adapter zu Drittherstellern (ServiceNow, Salesforce, Google Workspace), was die API-Spezifika der Zielsysteme standardisiert abstrahiert und Custom-Code überflüssig macht.

5. Edge Integration Cell Für hybride Szenarien, bei denen aus Compliance-Gründen Ground-to-Ground- oder On-Premise-Integrationen das Firmennetz nicht verlassen dürfen, bietet die Edge Integration Cell eine auf einem lokalen Kubernetes-Cluster laufende Runtime.

Die brennende Plattform: Migration von SAP PI/PO zur Integration Suite

Für alle Basis-Architekten tickt die Uhr: Die klassische Middleware SAP Process Integration / Process Orchestration (PI/PO) fällt 2027 aus der Standardwartung, mit einem optionalen (und teuren) Extended Support bis maximal 2030. Ein reines Aussitzen ist keine Option. Die Migration erfordert strategische Exzellenz und gliedert sich klassischerweise in vier Phasen:

• Assessment & Analyse: Das Verständnis der Bestandslandschaft ist oft die größte Stolperfalle, da historische Schnittstellen häufig schlecht dokumentiert sind (Reverse Engineering notwendig). Der Einsatz des SAP Migration Assessment Tools ist Pflicht, um den Ist-Stand der PI/PO-Landschaft zu scannen und ungenutzte Altlasten auszumustern.

• Architektur-Design & Roadmap: Ein gravierender Fehler ist der Versuch eines 1:1 Lift-and-Shift. Die Migration muss genutzt werden, um alte Pattern in moderne Konzepte (z. B. Event Mesh oder Open Connectors) zu überführen (Redesign). Ein iterativer Parallelbetrieb beider Welten ist essenziell.

• Migration & Refactoring: Obwohl das Cloud Integration Content Migration Tool Mappings und Teile von Flows automatisiert konvertieren kann, ist manuelle Nacharbeit bei hochgradig angepassten Schnittstellen unabdingbar. Insbesondere komplexe Adaptermodule, Java-Mappings oder User Defined Functions (UDFs) aus PO-Zeiten lassen sich oft nicht direkt übertragen und müssen beispielsweise in der BTP mittels Groovy Scripts neu geschrieben werden.

• Testing & Go-Live: Integrationen sind das Nervensystem der IT. Mehrstufige Testzyklen (ggf. automatisiert) und eine initiale Pilotmigration weniger kritischer Schnittstellen sind zwingend erforderlich. Nach dem Go-Live muss eine strikte Hypercare-Phase eingeplant werden.

DevOps, Security & Governance in der Cloud

Die Technologie allein löst keine organisatorischen Probleme. Ohne Governance droht in der BTP derselbe Wildwuchs wie früher On-Premise. Best Practices fordern "Governance First".

• Center of Excellence (CoE): Es ist unerlässlich, ein interdisziplinäres Team aufzubauen, das Architekturrichtlinien, Namenskonventionen (für Services und Spaces) sowie klare Onboarding-Prozesse definiert.

• Security by Design: Fein granulare Rollenkonzepte, strikte Authentifizierung (OAuth 2.0, SAML, Zertifikate) und isolierte Netzwerkzugriffe über den SAP Cloud Connector müssen vor dem ersten Flow-Deployment stehen.

• DevOps & CI/CD: Integrations-Artefakte wie iFlows müssen wie traditioneller Softwarecode behandelt werden. Die BTP liefert hierfür den SAP CI/CD Service und den Cloud Transport Management Service, um Änderungen kontrolliert von der Dev- in die Prod-Umgebung zu deployen. Flankiert wird dies durch ein tiefgehendes Monitoring mittels SAP Cloud ALM.

• FinOps: Da die BTP nach nutzungsbasierten Modellen (Subscription oder Cloud Credits) abgerechnet wird, müssen Budgets und Quotas überwacht werden, um Kostenexplosionen bei der Skalierung zu vermeiden.

Fazit

Die SAP Business Technology Platform und ihr mächtigster Baustein, die SAP Integration Suite, markieren den finalen Schnittpunkt zwischen monolithischer Legacy-IT und moderner, hochflexibler Cloud-Architektur. Das "alte Basiswissen" aus Zeiten von ABAP-Modifikationen und starren PI/PO-Landschaften wird nicht obsolet, sondern muss transferiert werden: von der On-Premise-Denkweise hin zu einem modularen, API- und Event-getriebenen Mindset.

Die Deadline 2027/2030 für PI/PO ist dabei nicht nur eine Bedrohung, sondern der dringend benötigte Katalysator, um die IT-Landschaft radikal aufzuräumen. Wer die BTP nach den Prinzipien von Clean Core, starker Governance und einem agilen DevOps-Ansatz implementiert, gewinnt nicht nur ein hochverfügbares Skalierungs-Fundament. Er stattet sein Unternehmen mit dem Innovationsmotor aus, der notwendig ist, um KI-Services, vorausschauende Datenanalysen und nahtlose B2B/A2A-Prozesse performant, sicher und zukunftsfähig abzubilden. Es ist Zeit, vom Verwalter der Altlasten zum Architekten der Zukunft zu werden. Starten Sie klein, nutzen Sie die Free Tier-Modelle für Pilot-Use-Cases und orchestrieren Sie den Wandel gemeinsam mit Business und IT.