Eine hybride SAP-ALM-Architektur ist eine ALM-Landschaft, die SAP-Cloud-Komponenten und SAP-On-Premise-Komponenten gemeinsam steuert, in einem konsistenten Change-Prozess, mit einem konsistenten Audit Trail und unter einer konsistenten Governance. Sie ist die strukturelle Antwort auf eine ebenfalls hybride Anwendungslandschaft, in der S/4HANA On-Premises, Private Cloud, Public Cloud, BTP, BW/4HANA, SuccessFactors, Ariba und Non-SAP-Systeme nebeneinander betrieben werden.
Im DACH-SAP-Markt ist diese Architektur kein Sonderfall, sondern die Regel. Der DSAG-Investitionsreport 2026 dokumentiert, dass 78 Prozent der DSAG-Mitglieder hybride On-Premise- und Cloud-Umgebungen betreiben. Die Public-Cloud-Penetration liegt bei etwa 5 bis 7 Prozent. 42 Prozent der 2026-Investitionen fliessen in S/4HANA On-Premises, 22 Prozent in Private Cloud, 6 Prozent in Public Cloud. 54 Prozent der Befragten haben noch ECC oder Business Suite in der Systemlandschaft.
Die hybride Architektur ist nicht eine Zwischenstation auf dem Weg in die reine Cloud. Sie ist für die Mehrheit der Anwender die Ziel-Architektur. Eine ALM-Strategie, die nur Cloud-Pfade kennt, lässt 78 Prozent der DACH-Anwender unterversorgt.
Der DSAG-Investitionsreport 2026 liefert die empirische Grundlage. Die Zahlen: 64 Prozent der S/4HANA-Investitionen sind On-Premise oder Private Cloud. Der RISE-Anteil (Public Cloud) ist marginal. 54 Prozent der befragten Unternehmen haben noch ECC oder Business Suite in der Landschaft.
Für die Mehrheit der DACH-SAP-Kunden bedeutet das: Sie betreiben gleichzeitig alte On-Premise-Systeme, neue S/4HANA-Instanzen (On-Premise oder Private Cloud), SAP-Cloud-Lösungen (SuccessFactors, Ariba, Concur), SAP BTP und Non-SAP-Anwendungen. Jedes dieser Systeme hat eigene Transport-Mechanismen, eigene Release-Zyklen und eigene Change-Anforderungen.
Ein ALM, das nur für S/4HANA ausgelegt ist, steuert einen Teil der Landschaft. Ein ALM, das nur für Cloud-Systeme ausgelegt ist, steuert einen anderen Teil. Weder SAP Cloud ALM noch ServiceNow deckt den gesamten hybriden Betrieb out-of-the-box ab.
Für hybride SAP-ALM-Architekturen gibt es vier grundlegende Optionen:
Option A: SAP Cloud ALM als zentrale Plattform mit Third-Party-Ergänzungen. Cloud ALM übernimmt Operations Monitoring, ITSM und Teile des Change Managements. Für die Funktionslücken (Transport-Orchestrierung, Single-Landscape-CSOL, Release-Zyklen) werden Third-Party-Werkzeuge ergänzt. Geeignet für Kunden, die SAP-nah bleiben wollen.
Option B: SAP Solution Manager (Extended Maintenance) als Überbrückung. SolMan bleibt das zentrale ALM-Werkzeug bis Cloud ALM die fehlenden Funktionen liefert. Kostenpflichtige Extended Maintenance bis 2030. Kauft Zeit, löst das strukturelle Problem nicht.
Option C: Third-Party ALM als zentraler Orchestrierungs-Layer. Ein SAP-nativer Third-Party-Anbieter (Rev-Trac, ActiveControl, Solutive ESM Suite) übernimmt Transport-Orchestrierung, CSOL, Release-Governance und Audit Trail für alle SAP-Komponenten. Bietet die vollständigste Abdeckung für hybride Landschaften.
Option D: ITSM-Plattform als Dach. ServiceNow übernimmt das Change Management, integriert über Konnektoren mit SAP-spezifischen Werkzeugen. Für Unternehmen sinnvoll, die ServiceNow enterprise-weit einsetzen.
Die Funktionslücken-Akkumulation. Cloud ALM hat individuelle Funktionslücken (Single-Landscape-CSOL, Transport-Orchestrierung, Release-Zyklen). Für einen reinen Cloud-Kunden mögen diese tolerierbar sein. Für einen hybriden Kunden mit parallelen On-Premise-Wartungslinien akkumulieren sie sich zu einem strukturellen Defizit.
Das SolMan-Auslauf-Problem. Wer heute hybride Landschaften und ChaRM betreibt, hat bis Ende 2027 Zeit. Die Migration zu Cloud ALM allein ist keine vollständige Lösung, weil sie Funktionslücken erzeugt. Mit Third-Party-Ergänzung funktioniert es, aber mit höherer Komplexität.
Das Regulatorik-Problem. SOX, NIS2, DORA und EU AI Act verlangen lückenlose Audit Trails für alle Systeme. Eine hybride Landschaft mit halbem ALM-Prozess erzeugt lückenhafte Compliance. Der nicht abgedeckte Teil der Landschaft hat keinen belastbaren Audit Trail.
Landschaftsinventar als Ausgangspunkt. Vor jeder Werkzeug-Entscheidung wird die Landschaft inventarisiert: Welche Systeme werden betrieben? Welche Change-Mechanismen haben sie? Welche Abhängigkeiten bestehen? Dieses Inventar ist die Grundlage für die Anforderungsdefinition.
Anforderungsmatrix für die hybride Architektur. Aus dem Inventar entsteht eine Matrix: Welche Systeme müssen durch das ALM gesteuert werden? Welche Transport-Mechanismen müssen unterstützt werden? Welche Compliance-Anforderungen gelten? Welche Funktionen sind nicht verhandelbar?
Werkzeugauswahl auf Basis der Anforderungsmatrix. Erst nach Inventar und Matrix wird die Werkzeugauswahl getroffen. Für viele hybride Kunden wird die Antwort eine Kombination sein: ein Werkzeug für Transport-Orchestrierung und Governance, ein Werkzeug für ITSM und Monitoring.
Migrationspfad mit expliziten Übergangsphasen. Die Migration von ChaRM zu einer hybriden Ziel-Architektur ist ein Prozess, kein Ereignis. Übergangsphasen müssen explizit geplant sein, mit klaren Kriterien für den Abschluss jeder Phase.
Eine hybride SAP-ALM-Architektur ist 2026 nicht eine Übergangsphase, sondern die Ziel-Architektur für 78 Prozent der DACH-SAP-Kunden. Cloud-first ALM reicht für hybride Landschaften nicht aus. Landschaftsinventar und Anforderungsmatrix kommen vor dem Tool-Entscheid. Die Antwort für viele Kunden: ein Werkzeug für Transport-Orchestrierung und Governance, ein Werkzeug für ITSM und Monitoring.