SAP ALM Zielarchitekturen nach SAP Solution Manager – Serie 4/6

Entstehende Zielarchitekturen

Basierend auf den oben beschriebenen funktionalen Ebenen ergeben sich in der Praxis typischerweise zwei strukturelle Architekturansätze. Der Unterschied zwischen ihnen liegt nicht in spezifischen Produkten, sondern in der architektonischen Zielsetzung und der historisch gewachsenen Governance-Positionierung.

Muster 1: Enterprise-First SAP ALM mit integrierter SAP Software-Logistik

Das erste Muster findet Anwendung, wenn das unternehmensweite ALM-Backbone bereits fest außerhalb der SAP-Welt etabliert ist. In solchen Umgebungen sind Tools wie Jira, Azure DevOps oder ServiceNow seit Langem die primären Systeme zur Verwaltung von Anforderungen, Workflows und Release-Steuerung. SAP Solution Manager spielte dabei häufig eine eher technische Rolle und war primär auf die Durchführung von Transporten fokussiert.

In diesem Modell sind Enterprise-Architektur und Prozessverantwortung typischerweise in Plattformen wie SAP LeanIX und SAP Signavio verankert. Dokumentation und Wissensmanagement werden in Confluence und SharePoint gepflegt oder alternativ im Azure DevOps Wiki in Kombination mit SharePoint.

Das operative Rückgrat für Änderungen und Auslieferung verbleibt im unternehmensweiten Toolset, zum Beispiel:

• Jira erweitert durch Conigma CCM 

• Azure DevOps Boards erweitert durch Conigma CCM 

• ServiceNow erweitert durch Conigma CCM

Das Testmanagement orientiert sich an den bestehenden Enterprise-Standards, wie beispielsweise Xray, Azure DevOps Test Plans oder Tricentis qTest.

In dieser Architektur integriert Conigma CCM die SAP-Transport-Governance direkt in das etablierte Enterprise-Backbone. SAP wird zu einer Domäne innerhalb der Gesamtarchitektur, anstatt als separates Lifecycle-Ökosystem betrieben zu werden.

Das strukturelle Ergebnis ist klar: Die Governance bleibt einheitlich, Reporting-Strukturen bleiben konsolidiert, es wird keine parallele ALM-Suite eingeführt, und gleichzeitig wird eine tiefgehende SAP-Transportkontrolle ohne architektonische Doppelstrukturen erreicht.

Muster 2: SAP Lifecycle Core mit Enterprise-Integration

Das zweite Muster findet typischerweise Anwendung in Organisationen, in denen die SAP-Governance historisch zentral verankert und tief in operative Prozesse eingebettet ist. In solchen Umgebungen war der SAP Solution Manager mehr als nur ein Transportwerkzeug; er stellte eine strukturierte Steuerungsebene für den SAP-Lifecycle dar.

Hier entwickelt sich die Zielarchitektur zu einem geschichteten Modell: Enterprise-Work-Management-Systeme bleiben auf Organisationsebene bestehen, während SAP Cloud ALM die Rolle des Lifecycle-Kerns innerhalb der SAP-Domäne übernimmt. In komplexeren Landschaften können erweiterte SAP-Software-Logistik-Funktionen – beispielsweise durch Conigma CCM – dieses Setup ergänzen, um eine Governance-Tiefe zu erreichen, die über das standardmäßige, featurebasierte Transporthandling hinausgeht.

Die Enterprise-Tools bleiben bestehen, werden jedoch mit SAP Cloud ALM integriert. Dieses Modell eignet sich besonders für Umgebungen mit starken SAP-zentrierten Compliance-Anforderungen, etablierten ChaRM-Strukturen oder einer hohen Abhängigkeit von SAP-Governance.

In komplexen SAP-Landschaften mit Multi-Track-Entwicklung oder regulatorischer Aufsicht kann Conigma CCM die Transportkontrolle innerhalb dieses geschichteten Modells stärken, ohne die architektonische Rolle von Cloud ALM grundlegend zu verändern.

Im nächsten Artikel beleuchten wir den entscheidenden Faktor, der letztlich darüber bestimmt, ob eines dieser Muster erfolgreich ist: die Qualität der Integration.