Stabiler Kern, bewegliche Ränder: Was das für SAP-Governance bedeutet
· aktualisiert · 6 Min. Lesezeit · Daniel Ostner
Zwei SAP-Meldungen, die auf den ersten Blick nichts miteinander zu tun haben, beschreiben dasselbe Architekturprinzip: Trenne, was stabil bleiben muss, von dem, was sich bewegen soll. Für Enterprise-Architekten und IT-Leiter im DACH-Raum ist das kein akademisches Konzept, sondern eine operative Entscheidung mit direkten Governance-Folgen.
Zwei Meldungen, ein Muster
ERP Today berichtete diese Woche über zwei SAP-Ankündigungen, die innerhalb eines Tages erschienen. Die erste beschreibt eine Partnerschaft zwischen SAP Commerce Cloud und Vercel, dem Front-End-Cloud-Anbieter hinter Next.js. Die zweite schildert, wie Tirlán, Irlands führende Agrargenossenschaft, nach der Trennung von Glanbia in neun Monaten eine eigenständige SAP-Landschaft aufgebaut hat. Storefront-Architektur auf der einen Seite, Unternehmensabspaltung in einer verderblichen Lieferkette auf der anderen – scheinbar ohne Berührungspunkte.
Der gemeinsame Nenner ist struktureller Natur: In beiden Fällen entstand der Wert daraus, dass klar entschieden wurde, was unveränderlich bleiben muss, was sich verändern darf und wie Veränderungen geprobt werden, bevor sie die Produktion erreichen. Dieses Muster – stabiler Kern, bewegliche Ränder – läuft dem entgegen, wie viele SAP-Programme im DACH-Raum heute noch zugeschnitten werden.
Was das Architekturprinzip konkret bedeutet
Die SAP-Vercel-Partnerschaft teilt Verantwortlichkeiten sauber auf: SAP Commerce Cloud übernimmt Katalog, Pricing, Checkout und Transaktionslogik – also den System-of-Record-Teil. Vercel verantwortet das Rendering, die Seitenperformance und das Deployment der Storefront. Die Schnittstelle ist definiert, die Zyklen sind entkoppelt. Das Front-End kann täglich deployt werden, ohne dass das ERP-Backend angefasst wird.
Tirlán zeigt die gleiche Logik auf Unternehmensebene: Ein Carve-out, der in neun Monaten abgeschlossen ist, gelingt nicht durch Vollständigkeit, sondern durch Priorisierung. Was muss am Tag eins laufen – Lohnbuchhaltung, Lieferkette, Compliance –, und was kann in Wellen folgen? Die Fähigkeit, diese Frage präzise zu beantworten und die Antwort architektonisch umzusetzen, ist der eigentliche Erfolgsfaktor.
Beide Fälle zeigen: Die Entscheidung, was zum stabilen Kern gehört, ist keine technische, sondern eine Governance-Entscheidung. Sie muss von Architekten und Business-Stakeholdern gemeinsam getroffen werden, bevor irgendein Projekt-Scope festgelegt wird.
Nicht jede Komponente verdient dieselbe Änderungsfrequenz. Wer das nicht explizit entscheidet, entscheidet es implizit – meistens falsch.
Warum DACH-Unternehmen dieses Muster systematisch unterschätzen
In vielen deutschen, österreichischen und schweizerischen Unternehmen wird SAP als monolithische Einheit behandelt – nicht weil das technisch notwendig wäre, sondern weil Governance-Strukturen, Budgetzyklen und Projektverantwortung so aufgebaut sind, dass Entkopplung organisatorisch aufwendiger erscheint als Integration. Der Wunsch nach einem 'vollständigen' System schlägt das Bedürfnis nach einem beherrschbaren System.
Das Ergebnis sind SAP-Landschaften, in denen Customizing und Standardfunktionen so eng verwoben sind, dass jede Änderung am Rand das Zentrum gefährdet. Releases werden seltener, Testaufwände wachsen, und die Fähigkeit, auf Marktveränderungen zu reagieren, sinkt – obwohl die ursprüngliche Investition in SAP genau diese Agilität ermöglichen sollte.
Hinzu kommt ein Compliance-Reflex: Im regulierten Umfeld – etwa in der Lebensmittelbranche wie bei Tirlán, im Finanzsektor oder in der Pharmaindustrie – wird Stabilität oft mit Unveränderlichkeit gleichgesetzt. Das ist ein Kategorienfehler. Stabilität bedeutet Zuverlässigkeit des Kerns, nicht Immobilität des Gesamtsystems.
Budgetzyklen fördern Vollständigkeit statt Modularität
Fehlende Schnittstellendefinitionen machen Entkopplung nachträglich teuer
Compliance-Anforderungen werden als Argument gegen Modularisierung missbraucht
Organisatorische Silos spiegeln sich in monolithischen Systemlandschaften
Governance-Konsequenzen: Wer entscheidet was – und wann
Das Stable-Core-Prinzip verlangt eine Governance-Entscheidung, die vor der Architekturentscheidung liegt: Welche Daten, Prozesse und Systeme sind geschäftskritisch genug, um mit hohen Änderungskosten geschützt zu werden? Und welche Bereiche sollen schnell iterierbar bleiben, weil sich Marktanforderungen dort häufig ändern?
Diese Unterscheidung muss dokumentiert, versioniert und periodisch überprüft werden – nicht einmalig im Projektstart-Workshop. Für Compliance-Verantwortliche bedeutet das: Die Klassifizierung von Systemkomponenten nach Änderungsfrequenz und Risiko ist kein IT-Thema, sondern Teil des Risikoregisters. Wer diese Klassifizierung nicht explizit vornimmt, hat keine belastbare Grundlage für Change-Management-Entscheidungen.
Für IT-Leiter ergibt sich daraus eine konkrete Forderung an Architekten: Jede neue SAP-Initiative sollte mit einer expliziten Core-Edge-Karte starten. Was ist Kern? Was ist Rand? Wo ist die Schnittstelle, und wer verantwortet sie? Diese drei Fragen zu beantworten, bevor ein Projekt-Scope definiert wird, reduziert Nacharbeitskosten und schafft Klarheit über Teststrategien und Release-Zyklen.
Die Klassifizierung von Systemkomponenten nach Änderungsfrequenz und Risiko gehört ins Risikoregister – nicht nur ins Architektur-Wiki.
Konkrete nächste Schritte für Architekten und IT-Leiter
Das Muster aus den SAP-Meldungen ist kein Zukunftsentwurf. Es ist eine operative Methode, die heute angewendet werden kann – unabhängig davon, ob ein Unternehmen gerade einen Carve-out plant oder seine Commerce-Plattform modernisiert.
Core-Edge-Inventar erstellen: Bestehende SAP-Komponenten nach Änderungsfrequenz, Risiko und Business-Kritikalität klassifizieren – als Grundlage für alle weiteren Architekturentscheidungen.
Schnittstellenverträge definieren: Für jede Grenze zwischen Kern und Rand einen expliziten API-Vertrag festlegen, der unabhängig von Release-Zyklen beider Seiten gilt.
Änderungsfrequenz in Governance verankern: Unterschiedliche Change-Advisory-Board-Prozesse für Kern- und Randkomponenten einführen – nicht alles braucht denselben Freigabeprozess.
Carve-out-Szenarien proben: Auch ohne geplante Unternehmenstrennung regelmäßig prüfen, ob kritische Systeme in einem definierten Zeitfenster isoliert betrieben werden könnten – das deckt versteckte Abhängigkeiten auf.
Compliance-Klassifizierung aktualisieren: Prüfen, ob bestehende Compliance-Anforderungen tatsächlich Unveränderlichkeit fordern oder nur Nachvollziehbarkeit – und Governance-Prozesse entsprechend anpassen.
Pilotprojekt mit entkoppeltem Front-End: Für eine Commerce- oder Self-Service-Anwendung einen Vercel- oder vergleichbaren Deployment-Zyklus vom SAP-Backend trennen und Erkenntnisse auf andere Randsysteme übertragen.
Wer heute nicht weiß, was sein stabiler Kern ist, wird morgen nicht wissen, was er schützen muss – und was er loslassen kann.
Quellen
Dieser Entwurf wurde KI-gestützt aus folgenden Meldungen erstellt und ist vor der Veröffentlichung redaktionell zu prüfen.
Stable Core, Movable Edges: What SAP’s Vercel Partnership and Tirlán’s Nine-Month Carve-Out Have in Common – ERP Today (https://erp.today/stable-core-movable-edges-what-saps-vercel-partnership-and-tirlans-nine-month-carve-out-have-in-common/)
In die Praxis bringen
Readiness, Use Cases, Governance und Roadmap in einem strukturierten Pfad durcharbeiten.
Kostenlos starten
Daniel Ostner
Autor des Enterprise-AI-Leitfadens
KI-unterstützt entworfen, redaktionell geprüft am 05. September 2026.
Daniel Ostner bringt 20+ Jahre Erfahrung aus SAP-Landschaften und Enterprise-IT mit — als Chief Architect einer S/4-Greenfield-Transformation im globalen Chemiehandel und rund 7 Jahre als IT-Leiter eines SAP-Beratungshauses. Zertifiziert u.a. im IESE Executive Program Data & AI.