SAP Cloud ALM vs. Solution Manager: Der ultimative Deep-Dive zur Architektur, Transition und zum Operations-Framework

Als Senior SAP Technology Consultant und Tech-Blogger beobachte ich seit Jahren die tektonischen Verschiebungen in der SAP-Landschaft. Die wohl bedeutendste Veränderung für uns als Administratoren, Entwickler und Architekten ist das nahende Ende des SAP Solution Managers. Der Wechsel zu SAP Cloud ALM ist nicht einfach nur ein Upgrade – es ist ein fundamentaler Paradigmenwechsel in der Art und Weise, wie wir Application Lifecycle Management (ALM) betreiben. In diesem extrem detaillierten Deep-Dive verschmelze ich historisches Basiswissen der klassischen On-Premise-Welt mit den modernsten technologischen Fakten aus aktuellen SAP-Spezifikationen.

Das Ende einer Ära: Der Sunset des SAP Solution Managers

Historisch gesehen war der SAP Solution Manager über zwei Jahrzehnte lang das unangefochtene, monolithische Herzstück vieler SAP-Landschaften. Er basierte klassisch auf einem Dual-Stack (oder später separaten ABAP- und Java-Stacks), was enorme Hosting- und Administrationskosten für Datenbanken, Kernel-Updates und Infrastruktur verursachte. Zudem entwickelte sich die Benutzeroberfläche des Solution Managers über die Jahre zu einem regelrechten "Zoo" aus unterschiedlichsten UI-Technologien – von CRM UI über veraltetes Flash bis hin zu modernen Fiori-Ansätzen.

Der harte Schnitt steht fest: Zum 31. Dezember 2027 endet die Mainstream Maintenance für den SAP Solution Manager.

Was passiert technisch am 1. Januar 2028? Das System wird nicht spontan den Dienst quittieren, es läuft exakt so weiter wie am Tag zuvor. Jedoch treten ab diesem Datum drastische Support-Einschränkungen in Kraft:

• Es werden keine Support Packages mehr ausgeliefert.

• Es gibt keine technologischen Updates mehr, weder für neue Kernel-Versionen noch für neue Datenbank-Releases.

• Sowohl für ABAP- als auch für Non-ABAP-Komponenten (wie Java oder Frontend-Systeme) werden keine neuen Patches mehr bereitgestellt.

• Die Unterstützung für neue Schnittstellen entfällt und es gibt bei Support-Tickets keine garantierten SLAs mehr.

• Zudem wird SAP keinerlei Investitionen im Bereich Künstliche Intelligenz (KI) in den Solution Manager tätigen; diese Use Cases sind exklusiv für SAP Cloud ALM reserviert.

Architektur und Value Proposition von SAP Cloud ALM

SAP Cloud ALM ist eine von Grund auf neu konzipierte, Cloud-native SaaS-Lösung (Software-as-a-Service), die für die Anforderungen moderner IT-Landschaften von heute und morgen entwickelt wurde.

Die Kernarchitektur- und Bereitstellungsvorteile umfassen:

• Keine Infrastrukturkosten: Da es sich um ein von SAP betriebenes SaaS-Modell handelt, entfällt der Bedarf an internen Experten zur Wartung komplexer ABAP/Java-Stacks. SAP übernimmt das Hosting, die Skalierung und das Patch-Management.

• Agiles Deployment: Im Gegensatz zum Solution Manager, bei dem die Bereitstellung neuer Funktionen durch Support Packages oft Monate bis Jahre dauerte, nutzt Cloud ALM tägliche Deployments im Hintergrund und rollt alle zwei Wochen neue Funktionen (Feature-Updates) aus.

• Instant Provisioning: Die Einrichtung eines Solution Managers konnte Tage bis Monate in Anspruch nehmen. Bei Cloud ALM wird der Tenant unkompliziert über SAP for Me angefordert und ist innerhalb von 30 Minuten einsatzbereit.

• Kostenmodell: Für Kunden mit einer bestehenden SAP-Subscription fallen für SAP Cloud ALM keine zusätzlichen Lizenzkosten an ("fair use" vorausgesetzt).

Implementation Lifecycle: Vom Design bis zum Deployment

SAP Cloud ALM integriert die SAP Activate Methodologie tief in seine Architektur und unterstützt Projekte lückenlos von der Discover/Prepare-Phase bis zum Deployment.

Design-Phase & Fit-to-Standard

Anstatt wie früher mit leeren Systemen zu beginnen, liefert Cloud ALM umfangreiche Best Practices und Beschleuniger ("Accelerators") direkt out-of-the-box. Im Process Authoring Tool können Geschäftsprozesse detailliert modelliert (bis Level 4) und als BPMN, SVG oder PDF ex- und importiert werden. In den Fit-to-Standard-Workshops werden Requirements direkt an diese Prozesshierarchien (Process Diagram Flows) geknüpft.

Build-Phase: Agile vs. Waterfall & Requirement Management

Die erfassten Requirements (das "Was") werden während der Build-Phase granular in ausführbare User Stories und Tasks (das "Wie") heruntergebrochen. Das System bietet ein komplettes Scrum-Framework:

• PI Planning (Program Increment): Zuweisung von Requirements in spezifische Zeitfenster und Identifikation von technischen Abhängigkeiten in einer Gantt-Chart-Ansicht.

• Sprint Planning & Daily Scrum: Management der Tasks in Sprints (z.B. Sprint 0 für Functional Specification Documents - FSD, spätere Sprints für Development) über interaktive Kanban-Boards.

Ein technisches Kernelement ist das Feature-Objekt. Ein Feature agiert in Cloud ALM als logischer Container für Transports. Wenn Code- oder Konfigurationsänderungen vorgenommen werden, werden die Transports an Features gebunden, welche wiederum mit den initialen Requirements verknüpft sind. Dies ermöglicht eine lückenlose Traceability.

Testing: Qualitätssicherung & Tricentis-Integration

Die Test-Architektur von Cloud ALM deckt manuelle und automatisierte Testfälle ab. Testfälle werden in Testplänen orchestriert, Vorbereitungen getrackt und Defekte direkt aus fehlgeschlagenen Testschritten (inklusive Beweis-Screenshots) generiert.

Ein massiver technologischer Fortschritt ist die Integration von Drittanbieter-Testwerkzeugen. Eine Light-Version von Tricentis ist für die Testautomatisierung nativ integriert. Zudem können Tools wie Tricentis LiveCompare für die Testoptimierung angebunden werden.

Operations & Business Process Monitoring

Während sich der Solution Manager stark auf technisches Monitoring konzentrierte, legt Cloud ALM den Fokus verstärkt auf die Geschäftsebene. Die Operations-Suite bietet:

• Business Process Monitoring: End-to-End Transparenz durch vordefinierte KPIs. Sinkt beispielsweise der Lagerbestand unter einen Schwellenwert von 10, feuert das System automatisch Alerts.

• Technical & User Performance Monitoring: Überwachung von Job-Fehlern, Systemgesundheit und Anomalie-Erkennung durch intelligente Verarbeitung.

Das Integrations-Ökosystem & Open APIs

Historisch gesehen litten heterogene Landschaften unter dem "Dual-Entry"-Problem: Entwickler pflegten Tasks in Jira, während Transporte im Solution Manager getrackt wurden. Cloud ALM löst dies durch offene APIs und tiefe Third-Party-Konnektoren.

• Bidirektionale Jira- & Azure DevOps-Integration: Requirements in Cloud ALM fließen automatisch als "Epics" nach Jira. Tasks werden zu "User Stories". Updates synchronisieren sich in Echtzeit.

• ServiceNow: Fokus auf Alerting im operativen Betrieb sowie ITSM-Szenarien.

Selbst für Transport Management existieren direkte Konnektoren aus Jira, Azure DevOps und ServiceNow heraus.

Strategische Transition: Der Weg vom Solution Manager zu Cloud ALM

Eine Migration erfordert exakte Planung. SAP stellt hierfür dezidierte Werkzeuge und Best Practices im Transition Center bereit.

1. SAP Readiness Check für SAP Cloud ALM: Dies ist der zwingende erste technische Schritt. Durch das Einspielen der SAP Note 3236443 (bzw. des neuesten SP) auf dem Solution Manager wird das System tiefgreifend analysiert. Der Check mappt historische SolMan-Szenarien direkt auf Cloud-ALM-Fähigkeiten (inklusive Anzeige der SAP-Roadmap für noch fehlende Features) und analysiert detailliert die Landschaft für den selektiven Datentransfer.

2. Selective Data Transfer (SDT): Wenn Lösungsdokumentationen (Solution Documentation) oder Testfälle migriert werden müssen, greift das Konzept des SDT. Hierbei werden spezifische Bibliotheken (z.B. Executable Libraries zur Application Library) und Prozessdiagramme gezielt aus den Design- und Produktions-Branches des Solution Managers nach Cloud ALM überführt.

3. Umgang mit ChaRM & Focused Build: Für Kunden des Change Request Management (ChaRM) gibt es spezielle Whitepaper. Wichtiges Architektur-Detail: Komplexe ChaRM-Funktionen wie Retrofit sind aktuell in Cloud ALM noch auf der Roadmap und nicht final verfügbar. Eine hybride Nutzung (Cloud ALM für Projekte, SolMan für ChaRM) ist vorerst möglich. Für Focused Build-Szenarien wird SAP bis Ende des Jahres funktionale Äquivalente in Cloud ALM implementieren, die denselben "Spirit" eines strikten Workflows für Großprojekte abbilden.

4. Auslagerung von Non-ALM-Funktionalitäten: Der SolMan wurde oft zweckentfremdet. Basis-Funktionen verschwinden nun aus dem ALM-Fokus: SLD (System Landscape Directory) und LMDB werden nicht mehr im klassischen Sinne überführt. Zertifikatsmanagement (Maintenance Certificates) und Lizenzverwaltung wandern in den Host Agent, das SL Toolset oder direkt in den Maintenance Planner. Die CUA (Central User Administration) muss auf andere NetWeaver- oder Identity-Management-Systeme ausgelagert werden.

Fazit

Der Wechsel vom SAP Solution Manager zu SAP Cloud ALM ist kein reines Lift-and-Shift-Projekt, sondern eine strategische Neuausrichtung. Während der On-Premise-SolMan mit seinen ABAP/Java-Stacks, komplexen Setup-Zeiten und veralteten UIs ab 2028 von sicherheitskritischen Updates (OS, Kernel, DB) abgeschnitten wird, bietet Cloud ALM eine SaaS-Architektur mit wöchentlichen Innovationen, modernsten KI-Integrationen und nativer API-Offenheit zu Jira und Tricentis.

Die Transition erfordert ein klares Verständnis der alten Datenstrukturen. Der Startschuss muss heute mit dem SAP Readiness Check (Note 3236443) fallen. Gerade bei hochkomplexen ChaRM-Setups oder streng regulierten Umgebungen (Pharma) müssen Architektur-Abhängigkeiten wie Retrofit genau auf der SAP Roadmap getrackt werden. Wer die integrierten Funktionen zur Traceability – vom Fit-to-Standard-Requirement über das Sprint-Feature bis hin zum produktiven Transport – richtig nutzt, wird sein Application Lifecycle Management massiv beschleunigen, Lizenzkosten einsparen und seine IT zukunftssicher aufstellen.