SAP-Architektur erodiert im Betrieb

Stand: Oktober 2026 · David Riederich · Aus dem englischen Original maschinell übersetzt

SAP-Architektur wird häufig als etwas verstanden, das während eines Projekts entworfen wird: ein Zielbild, ein Integrationsmodell, einige Prinzipien, ein paar Diagramme. Diese Artefakte sind wichtig. Aber sie sind nicht der eigentliche Test.

Der eigentliche Test beginnt im Betrieb. Dort formen lokale Änderungen, Schnittstellenanpassungen, Prozessausnahmen und supportgetriebene Workarounds das System schrittweise um. Über die Zeit kann sich die gelebte Architektur weit von der beabsichtigten Architektur entfernen.

Architektur ist nicht das Zielbild

Zielarchitekturen sind nützlich, weil sie Orientierung geben. Sie helfen, Teams, Partner und Management auf ein gemeinsames Verständnis auszurichten, wie sich die SAP-Landschaft entwickeln soll.

Aber eine Zielarchitektur ist nicht die Architektur selbst. Sie ist eine Hypothese. Die tatsächliche Architektur ist das, was nach hunderten operativen Entscheidungen übrig bleibt.

Ein Diagramm kann saubere Integrationsmuster zeigen. Der Betrieb kann trotzdem Punkt-zu-Punkt-Schnittstellen erzeugen. Eine Roadmap kann Standardprozesse definieren. Lokale Änderungen können Varianten einführen. Ein Clean-Core-Prinzip kann auf dem Papier existieren. Tägliche Change Requests können dennoch Logik an Stellen ergänzen, an denen niemand Wachstum beabsichtigt hatte.

Architektur ist nicht das, was das Diagramm sagt. Architektur ist das, was das System wiederholt zulässt.

Wo Architektur-Erosion beginnt

Architektur bricht selten durch eine einzige große Fehlentscheidung zusammen. Sie erodiert durch kleine, nachvollziehbare Entscheidungen, die nicht systemisch bewertet werden.

Typische Ursachen für Architektur-Erosion sind:

• lokale Prozessausnahmen, die zu dauerhaften Varianten werden
• Schnittstellen, die entstehen, weil Prozessharmonisierung zu lange dauern würde
• Custom Fields, die später Prozessverhalten steuern
• Workflow-Anpassungen für eine Abteilung, die Support-Komplexität für alle erzeugen
• temporäre Workarounds, die bleiben, nachdem die ursprüngliche Dringlichkeit verschwunden ist
• Erweiterungen ohne klare operative Verantwortung
• partnerspezifische Implementierungsentscheidungen, die nicht zur Gesamtlandschaft passen

Keine dieser Entscheidungen muss isoliert betrachtet irrational sein. Jede einzelne kann verständlich wirken. Zusammen verändern sie die Architektur.

Drei Arten von Schulden, die SAP-Landschaften ansammeln

Wenn Architektur im Betrieb nicht aktiv gepflegt wird, sammeln sich typischerweise drei Arten von Schulden an.

1. Integrationsschulden

Integrationsschulden entstehen, wenn Schnittstellen fallweise ergänzt werden, ohne einer konsistenten Integrationsstrategie zu folgen. Die Landschaft ist dann zwar verbunden, aber nicht kohärent.

Typische Symptome sind:

• zu viele Punkt-zu-Punkt-Verbindungen
• unklare Verantwortung für Schnittstellen
• inkonsistente Nutzung von APIs, Events, Dateien oder Middleware
• doppelte Datenflüsse
• fragile Abhängigkeiten zwischen Systemen

Integrationsschulden sind besonders gefährlich, weil sie oft unsichtbar bleiben, bis etwas verändert werden muss.

2. Variantenschulden

Variantenschulden entstehen, wenn lokale Prozessunterschiede akzeptiert werden, ohne ihre langfristigen Kosten sauber zu bewerten.

Eine Variante kann gerechtfertigt sein. Unkontrollierte Varianten vervielfachen jedoch Komplexität in Customizing, Tests, Schulung, Reporting, Support und späteren Transformationsvorhaben.

Das Problem ist nicht, dass Varianten existieren. Das Problem ist, dass viele Organisationen nicht wissen, welche Varianten sie haben, warum diese existieren und wem sie gehören.

3. Erweiterungsschulden

Erweiterungsschulden entstehen, wenn Enhancements, Custom Fields, Workflows oder Side-by-Side-Erweiterungen ohne Lifecycle-Denken gebaut werden.

Auch Erweiterungen außerhalb des Core können Schulden erzeugen, wenn Ownership, Integration, Monitoring, Security, Upgrade-Auswirkungen und operative Verantwortung unklar sind.

Eine technisch saubere Erweiterung kann architektonisch trotzdem schwach sein, wenn niemand versteht, wie sie in das größere System passt.

Warum der Betrieb die reale Architektur formt

Projekte erzeugen Aufmerksamkeit. Der Betrieb erzeugt Kontinuität.

Während eines Projekts sind Entscheidungen sichtbar, weil sie Teil von Scope, Zeitplan und Budget sind. Im Betrieb erscheinen viele Entscheidungen als kleine Änderungen: ein Ticket, eine Support-Anfrage, ein Enhancement, eine lokale Anforderung.

Genau deshalb ist der Betrieb so wirkungsvoll. Er entscheidet schrittweise, was die Architektur tatsächlich wird.

Wenn operative Änderungen nur danach bewertet werden, ob sie die unmittelbare Anfrage lösen, driftet die Landschaft. Wenn sie auch nach ihren architektonischen Konsequenzen bewertet werden, kann die Landschaft kohärent bleiben.

Die Architekturfragen, die jede Änderung beantworten sollte

Nicht jede Änderung braucht ein formales Architektur-Review. Aber jede architekturrelevante Änderung sollte vor der Umsetzung einige einfache Fragen beantworten.

1. Erzeugt diese Änderung eine neue Variante?

Wenn ja, sollte die Variante sichtbar, begründet und verantwortet sein. Andernfalls entsteht stille Komplexität.

2. Führt diese Änderung eine neue Abhängigkeit ein?

Abhängigkeiten sind nicht grundsätzlich schlecht. Aber versteckte Abhängigkeiten machen Systeme fragil und schwer veränderbar.

3. Gehört diese Logik in den Core?

Manche Logik gehört nahe an den Standardprozess. Manche gehört außerhalb des Core. Manche sollte gar nicht gebaut werden. Die Entscheidung muss explizit getroffen werden.

4. Wer betreibt und wartet diese Lösung?

Architektur endet nicht mit dem Go-live. Alles, was gebaut wird, muss verantwortet, überwacht, unterstützt und über die Zeit verändert werden.

5. Was passiert, wenn sich der Prozess später ändert?

Eine gute Architekturentscheidung bleibt auch dann nachvollziehbar, wenn sich die Organisation verändert. Wenn eine Lösung nur unter heutigen Annahmen funktioniert, sollte das Risiko sichtbar sein.

Architektur-Review als operative Routine

Architekturarbeit sollte keine einmalige Projektaktivität sein. Sie braucht wiederkehrende Routinen im Betrieb.

Das bedeutet nicht, für jedes Ticket ein großes Architecture Board einzuführen. Es bedeutet einen schlanken Mechanismus für jene wenigen Änderungen, die das System über die Zeit prägen.

Ein pragmatischer operativer Architektur-Review kann sich auf folgende Themen konzentrieren:

• neue oder geänderte Integrationen
• neue Prozessvarianten
• Erweiterungen mit Ownership- oder Lifecycle-Auswirkungen
• Custom Fields, die Prozesslogik beeinflussen
• Workflow-Abweichungen
• Änderungen, die Abteilungsgrenzen überschreiten
• Ausnahmen von Architektur- oder Clean-Core-Prinzipien

Ziel ist nicht, jede Entscheidung zu zentralisieren. Ziel ist, zu verhindern, dass Architektur versehentlich durch den Betrieb umgeschrieben wird.

Ein 90-Tage-Ansatz gegen Architektur-Erosion

Architektur-Erosion zu reduzieren, erfordert kein großes Programm. Ein fokussierter 90-Tage-Ansatz reicht oft aus, um Transparenz zu schaffen und den Entscheidungsrhythmus zu verändern.

Tag 1–15: Die wichtigsten Change-Pfade identifizieren

Erfassen Sie die wichtigsten Wege, über die Änderungen in die SAP-Landschaft gelangen: fachliche Anforderungen, Support-Tickets, Enhancement Requests, Schnittstellenänderungen, Workflow-Anpassungen, Reporting-Änderungen und Partnervorschläge.

Tag 16–30: Architekturrelevante Änderungstypen definieren

Definieren Sie, welche Änderungen architektonische Aufmerksamkeit benötigen. Ziel ist, jene wenigen Änderungen zu erkennen, die langfristige Folgen erzeugen – nicht alles zu prüfen.

Tag 31–45: Ein kurzes Impact Assessment einführen

Nutzen Sie ein einseitiges Assessment für architekturrelevante Änderungen. Es sollte Prozessauswirkungen, Integrationsauswirkungen, operative Verantwortung, Datenfolgen und Fit-to-Standard-Alternativen abdecken.

Tag 46–60: Ein Varianten- und Integrationsregister aufbauen

Starten Sie einfach. Dokumentieren Sie die wichtigsten Varianten und Integrationen: warum sie existieren, wem sie gehören und wann sie überprüft werden sollten.

Tag 61–90: Eine wiederkehrende Review-Routine etablieren

Etablieren Sie einen regelmäßigen Review-Rhythmus für ausgewählte Änderungen. Das kann wöchentlich, zweiwöchentlich oder monatlich sein – je nach Organisation. Entscheidend ist die Kontinuität.

Nach 90 Tagen sollte die Organisation mehr haben als Dokumentation. Sie sollte einen besseren Architekturreflex entwickelt haben.

Häufige Einwände

„Das verlangsamt den Betrieb.“
Das sollte es nicht. Ziel ist nicht, jede Änderung zu prüfen, sondern die wenigen Änderungen zu erkennen, die langfristige Folgen erzeugen. Klare Kriterien reduzieren in der Regel Debatten und Nacharbeit.

„Wir haben bereits einen Change-Prozess.“
Viele Change-Prozesse prüfen Freigabe, Tests und Release-Fähigkeit. Deutlich weniger prüfen, ob eine Änderung architektonisch sinnvoll ist.

„Unser Implementierungspartner prüft das bereits.“
Implementierungspartner prüfen möglicherweise technische Machbarkeit. Das ist nicht dasselbe wie eine unabhängige Bewertung der langfristigen Landschaftsauswirkung.

„Der Fachbereich braucht Flexibilität.“
Flexibilität ist wichtig. Aber ungesteuerte Flexibilität wird zu Komplexität. Architektur sollte Veränderung ermöglichen, ohne jede lokale Entscheidung zu dauerhafter Systemlogik werden zu lassen.

Fazit: Architektur ist eine operative Praxis

SAP-Architektur wird nicht durch ein Slide Deck geschützt. Sie wird durch wiederkehrende Entscheidungen, klare Verantwortung und operative Disziplin geschützt.

Die wichtigste Architekturarbeit passiert oft nach dem Go-live: wenn neue Anforderungen entstehen, wenn Abteilungen Änderungen anfordern, wenn Schnittstellen erweitert werden müssen und wenn Abkürzungen verlockend wirken.

Organisationen, die Architektur als lebendige operative Praxis verstehen, schaffen SAP-Landschaften, die leichter zu verändern, leichter zu betreiben und leichter zu transformieren sind.

Architektur ist nicht nur das, was entworfen wird. Architektur ist das, was unter operativem Druck kohärent bleibt.

Häufige Fragen zu SAP-Architektur

Was ist SAP-Architektur?

SAP-Architektur beschreibt, wie SAP-Systeme, Prozesse, Integrationen, Erweiterungen und Verantwortlichkeiten zusammenpassen. Sie ist nicht nur ein technisches Design, sondern auch eine Struktur, um die Landschaft über die Zeit kohärent zu halten.

Warum erodiert SAP-Architektur häufig im Betrieb?

Architektur erodiert, wenn lokale Änderungen, Schnittstellen, Varianten und Workarounds ohne gemeinsame architektonische Sicht umgesetzt werden. Jede einzelne Änderung kann klein sein, aber zusammen formen sie das System um.

Braucht jede SAP-Änderung ein Architektur-Review?

Nein. Nur architekturrelevante Änderungen sollten geprüft werden. Beispiele sind neue Integrationen, Prozessvarianten, core-relevante Erweiterungen, Workflow-Abweichungen und Änderungen mit Auswirkungen auf Daten- oder Reporting-Konsistenz.

Wie können Unternehmen ihre SAP-Architektur beherrschbar halten?

Ein pragmatischer Startpunkt ist die Klassifizierung von Änderungen, die Einführung kurzer Impact Assessments, die Dokumentation von Varianten und Integrationen sowie der Aufbau wiederkehrender Architektur-Review-Routinen.

Zurück zu den Insights