Funktionale Ebenen in einer Enterprise SAP ALM-Architektur – Strukturelle Perspektive - Serie 3/6

Funktionale Ebenen in einer unternehmensweiten SAP-ALM-Architektur

Bevor Zielarchitekturen bewertet werden, ist es hilfreich, die funktionalen Ebenen zu klären, die typischerweise ein unternehmensweites SAP Application Lifecycle Management (ALM) definieren. Unabhängig von konkreten Tool-Entscheidungen beschreiben diese Ebenen die strukturellen Verantwortlichkeiten innerhalb des gesamten Lebenszyklus.

Dokumentations- & Wissensebene

Die Dokumentations- & Wissensebene regelt, wie strukturiertes und unstrukturiertes Wissen über Fachbereiche und IT hinweg gepflegt wird. Ihr Zweck ist langfristige Transparenz – nicht die operative Workflow-Steuerung.

Typischerweise umfasst sie:

• Fachliche und technische Spezifikationen

• Prozessdokumentation

• Architekturentscheidungen

• Betriebsverfahren

• Compliance-relevante Nachweise

Diese Ebene fungiert als langfristiges System of Record. Sie stellt die Nachverfolgbarkeit über Initiativen hinweg sicher und gewährleistet kontextuelle Kontinuität über einzelne Release-Zyklen hinaus.

Unabhängig davon, ob sie mit Confluence, SharePoint oder Azure DevOps Wiki umgesetzt wird, bleibt ihre architektonische Funktion gleich: dauerhaftes, durchsuchbares und auditierbares Wissensmanagement über Enterprise- und SAP-Landschaften hinweg bereitzustellen.

Change- & Software-Delivery-Backbone

Der Change- & Software-Delivery-Backbone bildet den operativen Kern des Lifecycle Managements. Er steuert, wie Änderungen von der Anforderung bis zum produktiven Release gelangen.

Diese Ebene verwaltet typischerweise:

• Anforderungen und Backlog-Steuerung

• Change-Request-Workflows

• Release-Tracking

• Aufgabenverteilung und Freigaben

• Systemübergreifendes Abhängigkeitsmanagement

In SAP-Landschaften muss sie zusätzlich sicherstellen:

• Transport-Orchestrierung

• Release-Sequenzierung

• End-to-End-Traceability

• Audit-Nachweise zur Verknüpfung von Anforderungen mit Transporten

Dieser Backbone wird häufig mit Jira, Azure DevOps oder ServiceNow implementiert. In SAP-intensiven Umgebungen kann er durch Conigma CCM erweitert werden, um eine tiefgehende Governance von SAP-Transporten zu gewährleisten.

Architektonische Kohärenz erfordert, dass Change-Artefakte über Systemgrenzen hinweg logisch miteinander verbunden bleiben. Fragmentierung auf dieser Ebene erhöht unmittelbar die Governance-Komplexität und das Compliance-Risiko.

Testmanagement & Automatisierung

Die Ebene Testmanagement & Automatisierung stellt die Validierung vor dem produktiven Deployment sicher und schützt die Release-Qualität.

Sie umfasst:

• Testfall-Design

• Testplan-Orchestrierung

• Mapping der Anforderungsabdeckung

• Nachverfolgung der Testausführung

• Sammlung von Audit-Nachweisen

Testmanagement-Plattformen wie Xray, Azure DevOps Test Plans oder Tricentis qTest ermöglichen eine strukturierte Qualitätssicherung über Unternehmensbereiche hinweg.

Automatisierungs-Frameworks wie Tosca erlauben skalierbare Regressionstests und risikobasierte Validierung. In vielen Unternehmen verbleibt Tosca aus organisatorischen Gründen weiterhin On-Premise, während zukünftige Migrationspfade in Richtung Tosca Cloud offenbleiben.

Die zentrale architektonische Anforderung auf dieser Ebene ist bidirektionale Traceability:
Anforderung → Change → Transport → Testfall → Testergebnis → Release

Ohne diese durchgängige Kette leiden Audit-Integrität und Release-Sicherheit.

Mit diesen funktionalen Ebenen als Grundlage lässt sich nun untersuchen, wie sie in konkrete Architekturmodelle übersetzt werden – und warum es kein universelles Nachfolgemuster gibt.