Die Gartner Pace-layered Application Strategy
In einem Transformations-Projekt sind die Auswirkungen auf die Systemlandschaften eine große Herausforderung. Wann werden welche Systeme wie angepasst? Weshalb ist die Veränderbarkeit nicht immer gleich groß? Welche Abhängigkeiten voneinander gibt es? Welche Datenobjekte sind betroffen und welche Systeme haben die Datenhoheit über diese? Weshalb können Features in gewissen Systemen pragmatischer als in anderen Systemen implementiert werden? All diese Fragen können mit der der Gartner Pace-layered Application Strategy besser beantwortet werden, indem die Anwendungslandschaft auf eine einfache Art strukturiert wird. Es gibt drei unterschiedliche Layers mit unterschiedlichen Ausprägungen, von den Core-Systemen zu innovativen Systemen.
In diesem Artikel diskutieren wir dieses Hilfsmittel und wenden es auf ein Transformations-Projekt an, das das ERP-System schrittweise austauscht. Auf dieses sind viele andere Systeme angewiesen, zum Beispiel ein Data-Warehouse-System. Es soll während der ganzen Transformation ein konstantes und vergleichbares Reporting liefern (Source of Truth). Dessen Kopplungen werde ich aufzeigen und Hilfsmittel für eine erfolgreiche Architektur liefern.
Die Gartner Pace-layered Application Strategy
Bevor wir mit unserem Beispiel beginnen, folgt eine kleine Einführung in die Gartner Pace-layered Application Strategy. Die Gartner Pace-layered Application Strategy ist ein gutes Hilfsmittel, die Anwendungslandschaft zu strukturieren. Es dient hierbei als Strategierahmen und als Kommunikationsinstrument zur Unterstützung der IT, indem es bei kurz- und langfristiger Priorisierung sowie bei der Modernisierung von IT-Architekturen hilft [1].
Die Pace-layered Application Strategy von Gartner ist eine Methodik zur Kategorisierung, Auswahl, Verwaltung und Steuerung von Anwendungen zur Unterstützung von geschäftlichen Veränderungen, Differenzierung und Innovation [2]. Als Architekt hören wir den Fachabteilungen zu, verfolgen die Unternehmensstrategie und müssen den Zoo von IT-Lösungen im Griff haben. Das kann zu folgender Situation führen: Wenn Fachanwender von der IT eine Lösung benötigen, sagt die IT, dass sie die Funktionalität des bestehenden Anwendungsportfolios nutzen sollen oder dass sie warten müssen, bis ein mehrjähriges Projekt abgeschlossen ist. Dazu kommt, dass vordergründig einfache Lösungen aus Sicht der Fachabteilungen immer viel zu lange dauern. Die Pace-layered Application Strategy hilft, diese Situation besser zu verstehen und möglicherweise besser damit umgehen zu können.
Modell
Das Pace-Layer-Modell beinhaltet drei Ebenen, wobei alle Anwendungen der Anwendungslandschaft aufgrund ihrer Änderungsanforderungen und Charakteristik zu einem entsprechenden Layer zugewiesen werden (Abb. 1).
Betrachten wir die einzelnen Layer, wobei wir unten beginnen.
- Layer 1: Systems of Record – Der Systems of Record Layer implementiert die Basis-Geschäftsprozesse eines Unternehmens. Die Systeme verändern sich langsam und bilden den Backbone des Unternehmens. Dies sind meist standardisierte Anwendungen, die im Grunde alle Unternehmen haben. Der Klassiker ist das Finanzsystem oder das ERP-System. Gewisse Unternehmen sprechen auch vom Core-Layer. Wenn wir den Fachabteilungen zuhören, dann lassen sich in diesen Layer allgemeine Ideen einordnen. Das sind allgemein akzeptierte Vorgehensweisen, die sich nur langsam ändern. Oft spielen auch regulatorische Auflagen eine wichtige Rolle, z. B. die Buchhaltungs- oder HR-Regeln.
- Layer 2: Systems of Differentiation – Die Systeme auf dem Systems of Differentiation Layer bilden die Einzigartigkeit des Unternehmens bezüglich der Wettbewerbssituation ab. Diese Systeme unterliegen einem konstanten Wandel. Typischerweise werden hier Systeme wie ein Shop oder ein CRM platziert. Wenn wir den Fachabteilungen zuhören, dann lassen sich in diesen Layer Geschäftsaspekte einordnen, bei denen das Unternehmen anders vorgehen will als vergleichbare Unternehmen. Es muss davon ausgegangen werden, dass sich Details dieser Aspekte regelmäßig ändern.
- Layer 3: Systems of Innovation – Im Systems of Innovation Layer befinden sich Systeme, die neue und innovative Geschäftsmodelle unterstützen sollen. Diese unterliegen einem kurzen Lebenszyklus. Aus meiner Sicht ist der Lebenszyklus wichtiger als die Diskussion, ob etwas innovativ ist. Innovationen können auf allen Layern stattfinden, aber auf diesem Layer wird kurzfristig gedacht und experimentiert. Eine iPhone-App wird auf dieser Ebene angesiedelt. Diese Anwendungen stellen nicht selten eine Schnittstelle zum Kunden dar. Wenn wir den Fachabteilungen zuhören, dann lassen sich in diesen Layer neue Ideen einordnen. Häufig ist das Konzept in einem frühen Stadium und Einzelheiten der Funktionsweise sind recht vage. Häufig wird ein schneller Konzeptnachweis gefordert, der meist mehrere Iterationen durchläuft.
Kommunikation
Die Kommunikation zwischen den Layern erfolgt über eine Integrationsplattform. Dies ist wichtig, um das Prinzip der losen Kopplung zu gewährleisten. So können die Komponenten mit unterschiedlichen Lebenszeiten unabhängiger weiterentwickelt und einfacher ersetzt werden. Auch können Integrationsplattformen ein einheitliches API zur Verfügung stellen und somit das Blackbox-Prinzip gewährleisten. Dies kann jedoch schnell aufwändig werden. Deshalb werden standardisierte und zertifizierte, direkte Schnittstellen zwischen Systemen zugelassen, z. B. zwischen einem ERP und einem Hochregalsystem.
Einordnung
Wir erkennen, dass sich die Layer sowohl in der Methodik als auch Geschwindigkeit der Veränderung unterscheiden. Die Veränderbarkeit steigt von tief nach hoch. Die Architektur von traditionell zu agil, wobei mit traditionell nicht gemeint ist, dass keine Agilität möglich ist. Es ist eher gemeint, dass die Projekte länger dauern und eher Auswirkungen auf die Prozesse haben. Der Lebenszyklus verläuft von lange zu kurz. Der Business-Impact geht von kontinuierlich zu neu. Durch die Digitalisierung haben die Layer 2 und 3 deutlich mehr Gewicht erhalten.
Die Einordnung der Unternehmensanwendungen in diese drei Ebenen hilft den Architekten, die Unternehmensarchitektur zu gliedern und den Fokus auf die entscheidenden Systeme zu legen. Wenn die Systeme wie oben in den Beispielen zugeordnet werden, ist zum Beispiel ersichtlich, dass eine iPhone-App (System of Innovation, die Anforderungen ändern sich kontinuierlich) losgelöst von einem ERP-System (System of Records, standardisiertes Datenmodell, zehn Jahre bis zur nächsten Ablösung) sein sollte. Im Layer System of Differentiation sollten bei einer Kommunikation zwischen den Applikationen Business-Services gelegt werden, die sowohl unabhängig vom Datenmodell eines ERP-Systems als auch unabhängig von einer sich schnell ändernden Welt sind.
Eine Bedingung des Schichtenmodells ist, dass keine Schicht übersprungen wird, d. h. immer die obere Schicht auf die untere Schicht zugreift. Dies gilt auch hier. Die iPhone-App aus dem obigen Beispiel soll nicht direkt auf das ERP zugreifen, umgekehrt sollen Preisänderungen nicht vom ERP direkt an Apps verteilt werden. Ist dies nicht gewährleistet, wird es schwierig, den Anforderungen der Fachabteilungen in notwendiger Frist nachzukommen. Es zwingt uns, die Schichten und somit die Applikationen zu entkoppeln.
Das Gartner Pace-Layer-Modell für den Pragmatiker
Versuchen Sie, die Systeme den Layern zuzuordnen und machen Sie sich Gedanken darüber, was das konkret für Umsetzungen von Geschäftsanforderungen bedeutet. So wird eher verstanden, weshalb die Entwickler im System of Innovation in agilen Teams mit kurzen Sprints arbeiten können und Entwicklungsteams im System of Records in einem regulierten Umfeld auf ganz andere Aspekte achten und in größeren Release-Zyklen denken.
Beispiel
Um die Anwendung des Modells besser zu verstehen, betrachten wir ein kleines Beispiel und platzieren die Systeme eines Beispiel-Unternehmens auf diesem Modell:
- Das ERP-System dient für die Grundprozesse wie Finanzen, Logistik und Verkauf.
- Das Data Warehouse (DWH) implementiert Modelle für die Auswertungen, die in einer Analytics Cloud zur Verfügung gestellt werden.
- Mit dem Online-Shop werden Produkte aus dem ERP verkauft.
- Es gibt eine App, mit der auf spielerische Weise dem Anwender, der Anwenderin, Produkte aus dem Shop schmackhaft gemacht werden. Diese kann er oder sie sofort kaufen. Zu dieser innovativen App braucht es einen Backend-Service, nach dem Backend-for-Frontend-Muster (BFF), der selbst entwickelt wird und auf dem Shop aufsetzt.
Das ERP und DWH platzieren wir auf dem Layer Systems of Records (Abb. 2). Diese Systeme stellen die Basis für folgende Systeme und Prozesse zur Verfügung. Der Shop stellt Services zur Verfügung, genauso die Analytics Cloud. Somit sind diese auf System of Differentiation platziert. Sie bauen auf den Layer System of Records auf. Auf System of Innovation platzieren wir die App mit dem Backend-Service. Ohne regelmäßige neue Ideen dürfte die App schnell beim Anwender an Reiz verlieren.
Durch die Unterscheidung der Layer sind die Abhängigkeiten gut erkennbar und entsprechend in den Projekten zu berücksichtigen. Betrachten wir folgend die Auswirkungen bei Projekten: So dürften Änderungen an der App keine Änderungen am ERP zur Folge haben, außer vielleicht, dass der Artikelstamm mal erweitert werden muss. Der Einkauf mit der App und die eigentliche Kommunikation laufen über die Services vom Shop. Die Artikeldaten, Kundendaten, das Checkout usw. können sowohl für die App als auch dem Online-Shop benutzt werden.
Dasselbe gilt bei einem Transformations-Projekt beim Shop. Das Resultat von einem Einkauf, die Bestellung, dürfte gleichbleiben, egal welches Produkt verwendet wird und wie der Bestellprozess sich im Shop ändert. Die Schnittstellen zum ERP, im Layer darunter, werden über eine Integrations-Plattform lose gekoppelt angeboten. Die App, einen Layer darüber, greift über ein API-Gateway auf die Shop-Services zu. Im idealen Fall kann das Gateway ein konstantes API der App zur Verfügung stellen und das API wrappen. Bei neuen Funktionen, die auch die App benutzen will, braucht es Anpassungen. Da diese aber eine hohe Veränderbarkeit aufweist, kann dies zeitnah im agilen Team umgesetzt werden.
Spannender ist es, wenn es ein Transformations-Projekt gibt, das das ERP ersetzt. Es stellt die Basis dar und hat zumindest implizite Abhängigkeiten zu den oberen Layers. Solch ein Projekt hat oftmals eine hohe Durchlaufzeit, was mit der dynamischen Welt der oberen Layers in Einklang gebracht werden muss. Betrachten wir das etwas genauer.
Transformationsprojekt im Core-Layer
Auf der technischen Ebene sind oftmals die Abhängigkeiten bekannt. Eine Integrationsplattform zeigt diese gut auf und entkoppelt die Systeme voneinander. Bekannt sein dürften auch zertifizierte Schnittstellen. Oftmals ist aber nicht die technische Kopplung das Problem, sondern zeitliche Abhängigkeiten, insbesondere der Prozesse, und Abhängigkeiten zu den Daten und Belegen.
Kopplungen zwischen den Komponenten und Systemen gibt es auf folgenden Ebenen:
- Kopplung durch Aufruf: Ein System ruft eine Funktion eines anderen Systems auf. Der Shop benutzt Funktionen im ERP.
- Kopplung als Auslöser einer Aktivität: Der Kunde will ein Produkt kaufen und benutzt den Checkout-Service des Shops für die Kartenzahlung.
- Kopplung durch Benachrichtigung: Ein Service benachrichtigt einen anderen Service, dass ein Event eingetroffen ist. Die Kartenzahlung war erfolgreich und die Bestellung kann abgeschlossen werden.
- Kopplung durch Daten oder Datenstrukturen: In der Bestellung ist ersichtlich, ob diese vom Online-Shop oder von der App aus getätigt wurde und sie kann im DWH ausgewertet werden.
- Kopplung über die Zeit: Eine aussagekräftige Auswertung kann erst erfolgen, wenn alle relevanten Daten im DWH von den Umsystemen geladen wurden.
Wird nun ein zentrales System wie ein ERP-System ausgewechselt, so kann dies auf zwei Arten erfolgen:
- Ersatz des alten Systems durch das neue: Bestehende Umsetzungen werden in das neue System übernommen. Dies ist ein technisches Projekt und oftmals bei Upgrades anzutreffen. Das System wird auf eine neue Version bzw. eine neue Generation aktualisiert und in einem späteren Projekt sukzessive auf die neuen Möglichkeiten umgestellt.
- Ein System wird neu implementiert. Die Prozesse werden hinterfragt und es erfolgt in der Regel auch eine Digitalisierung gewisser Aufgaben. Danach erfolgt eine Datenübernahme.
Bei einem Transformations-Projekt wird gemäß Definition der Ist-Zustand wesentlich hinterfragt und verändert. Somit sind Transformationen Projekte der zweiten Art. Die Digitalisierung solch eines Projektes unterstützt die Transformation, zum Beispiel Forecast-Bestimmungen für Bestellungen von Material-Nachschub.
Das ERP ist das Herz des Unternehmens. Wenn daran "operiert" wird, sind ganz viele Systeme davon abhängig. Nicht selten werden deshalb in eine Transformation auch Umsysteme im gleichen Zug konsolidiert. Dank dem Gartner-Modell erkennen wir in unserem Beispiel, dass der Shop und das DWH im Auge behaltet werden muss. In einem echten Unternehmen gäbe es sicher viele weitere Systeme.
Betrachten wir dazu zwei Beispiele der Kopplung über Daten: Beim Shop werden die Stammdaten Artikel und Kunden ausgetauscht und als Beleg die Bestellung. Existiert eine Integrations-Plattform, die zum Beispiel die Datenobjekte Artikel und Kunde bei Änderungen an die Teilnehmer verteilt (Public-Subscribe-Prinzip), muss nur die Schnittstelle ERP – Integrations-Plattform genauer betrachtet werden. Bedingung ist, dass aber das Datenobjekt semantisch gleichbleibt – was bei Transformationen nicht selbstverständlich ist. Wir haben also eine Kopplung durch Daten. Dieser Fall ist sicher einfacher zu handhaben, als wenn 20 Systeme eine Schnittstelle zum ERP haben, um Kundendaten auszutauschen.
Stellen wir uns vor, in unserem Beispiel konnte über drei Kanäle ein Artikel bestellt werden:
- Über den Onlineshop,
- indirekt über die App und
- als Offline-Bestellung, die direkt im ERP erfasst wird. Zum Beispiel erfasst der Kundenberater für B2B-Bestellungen diese im Büro nach seinem Verkaufsgespräch.
In der Transformation werden die Kanäle und die unterschiedlichen Prozesse harmonisiert. Dabei könnte das Szenario eintreten, dass es die direkten ERP-Bestellungen nicht mehr geben werden. Es soll alles über den Web-Shop bestellt werden, in einem bestimmten Assistenz-Modus. Im B2B-Fall wird dann der Außendienstmitarbeiter anhand des Shops das Verkaufsgespräch auf einem Tablet (statt auf Papier) führen und gleich die Bestellung mit dem Kunden im Shop tätigen. Das scheint auf den ersten Blick eine einfache Digitalisierung und Prozess-Konsolidierung zu sein. Betrachten wir dazu das DWH etwas genauer: Es gibt eine Auswertung, die die Dimension des Kanals verwendet, z. B. welche Artikel in welcher Menge über welchen Kanal verkauft werden. Es ist nun zu prüfen, wie weiterhin unterschieden werden kann, ob der Kunde selbst oder ein Mitarbeiter die Bestellung für ihn aufgegeben hat. Immerhin wurde im zweiten Fall Arbeitszeit dafür eingesetzt, somit ist diese Dimension aus Erfahrung nicht unerheblich. Diese Kopplung durch Daten ist vordergründig nicht erkennbar, muss in der Transformation aber berücksichtigt werden. In der Regel wird dies bei der Definition der Kennzahlen für die Steuerung des Unternehmens erkannt. Bleiben wir beim letzten Fall des DWHs: Der Hauptfokus eines DWHs liegt auf dem "Single Source of Truth" und der Unveränderlichkeit:
- Reproduzierbare Auswertungen,
- Kennzahlen und deren Stabilität (Marge = Marge) und
- Langlebigkeit der Modelle.
Während eines mehrjährigen Transformations-Projekts, das in mehreren Phasen umgesetzt wird, ist dieser Aspekt sehr wichtig. Das steuernde Reporting kann nicht alle 3 Monate inhaltlich neu definiert werden – es braucht eine Konstanz, auch wenn sich die Daten semantisch und von der Herkunft her verändern (Abb. 3).
Anhand der Abb. 3 kann nun die einfache Aussage entstehen, dass bei einem Transformations-Projekt einfach das Quellsystem im DWH geändert werden kann. Aber genau der oben genannte Fall mit dem Kanal ist somit nicht gelöst. Auch neue Möglichkeiten von Kennzahlen und Dimensionen würden so außer Acht gelassen. Technische Errungenschaften werden genauso nicht berücksichtigt: Soll weiterhin eine alte Technologie mit Ladeprozessen benutzt werden oder kann direkt auf eine In-Memory-Datenbank zugegriffen werden? Diese Frage stellt sich oft bei Transformationen von SAP R/3 nach S/4. Und genau da kommt der nächste spannende Punkt: Wo werden Near-Realtime-Auswertungen gemacht? Und wie vermischt sich Reporting mit Operativem?
Hier kommt die Architektur ins Spiel:
- Die Pace-layered Strategy gibt eine Struktur. Anhand dieser kann die Architektur-Entwicklung besprochen werden und das Verständnis der unterschiedlichen Projektarten und Laufzeiten besser verstanden werden (s. Abb. 1): zum Beispiel weshalb gewisse Teil-Projekte in einem Scrum-Team und andere eher traditionell umgesetzt werden.
- Gibt es eine Integrations-Architektur, die hilft, die Komplexität zwischen den Layers technisch zu klären?
- Eine Architektur-Dokumentation hilft in der Architektur-Arbeit.
- Gibt es ein Gremium, das diese Architektur bespricht?
Auf die ersten zwei Punkte wurde bereits eingegangen, also folgen noch die letzten zwei Punkte.
Dokumentation
Als Dokumentation der verschiedenen Architektur-Layer eignet sich zum Beispiel ArchiMate® oder das Zachman-Framework zusammen mit einem Tool. Die Modellierungssprache ArchiMate ist ein Ordnungsrahmen für die grafische Beschreibung der Unternehmensarchitektur [1;3]. Sie wird, wie das TOGAF®, von The Open Group weiterentwickelt und unterstützt sämtliche Phasen des TOGAF ADM [4]. Ein Vorteil von ArchiMate ist, dass es ein von Tool-Herstellern unabhängiger Standard ist. ArchiMate gliedert sich in fünf Sichten, die sich den TOGAF-Phasen zuordnen lassen (Abb. 4).
Wenn die Architekten der verschiedenen Teil-Domänen die Modellierungssprache von ArchiMate verstehen und ihren Teil sogar modellieren können, entsteht eine riesige Datenbank der Architektur, mit der stakeholderspezifisch verschiedene Views und Viewpoints mit den wichtigen Aspekten erstellt werden können.
Kommen wir auf unser DWH-Beispiel zurück. In ArchiMate sind die Geschäftsobjekte dokumentiert und einem System und einer Schnittstelle zugewiesen. Wenn sich also etwas ändert, können die Abhängigkeiten im Architektur-Team schnell erfasst werden. Vorsicht ist mit der Flughöhe dieser Datenobjekte geboten: Wenn ein Artikel mit all seinen unterschiedlichen Sichten modelliert wird, wird es schnell zu detailliert und unübersichtlich. Der Mehrwert ist oft nicht gegeben und die Gefahr, dass etwas übersehen wird, ist groß. Ist das Datenobjekt jedoch zu abstrakt, wachsen die Abhängigkeiten, die alle einzeln geprüft werden müssen [1].
Die Schnittstelle zwischen ERP und DWH mit den Datenobjekten kann vereinfacht wie in Abb. 5 modelliert werden.
Hier sehen wir, dass der Artikel bereits vom neuen ERP-System verteilt wird, während Bestellungen in das alte ERP-System fließen. Wenn alle Datenobjekte gepflegt sind, können einfach solche Übersichtssichten erstellt werden und aufgezeigt werden, welches System von welchen Systemen die Daten zu einem bestimmten Zeitpunkt bezieht.
Wichtig in solch einem Transformations-Projekt ist, dass die Datenhoheit der Datenobjekte definiert ist und das DWH von diesen Systemen, dem Master, die Daten bezieht. Würde es die Daten über Umwege beziehen, steigen die Abhängigkeiten, die gerade in komplexen Systemen durchschlagen. Besser wäre eine saubere Integrations-Architektur, die diese Problematik abstrahiert. So müssten sich die DWH-Modellierer nicht darum kümmern, welches System die Hoheit hat. Sie beziehen das Datenobjekt von der Integrations-Plattform und diese gewährt die Konsistenz. Die ERP-Objekte können in der Regel technologisch als auch inhaltlich (gemeinsame Semantik) einfacher direkt aus dem ERP bezogen werden. Das ist durch die Ansiedlung im gleichen Pace-Layer auch zugelassen. Aber bei den vielen Datenobjekten aus den anderen Layern ist die Datenhoheit und Integrations-Architektur von Vorteil zu beachten.
Diese Modellierungen bringen nichts, wenn sie nicht besprochen werden. Dazu helfen Architektur-Cluster. Übergeordnet kann dann ein Architektur-Board ins Leben gerufen werden.
Architektur-Board
Das TOGAF-Dokument (in der Version 10) Enterprise Architecture Capability and Framework beschreibt die Organisation, den Prozess, die Fähigkeiten, die Rollen und die Verantwortlichkeiten, die für die Einrichtung und den Betrieb einer Architekturfunktion innerhalb eines Unternehmens erforderlich sind [4].
Ein Architektur-Board ist eine Gruppe, die für die Überprüfung und Pflege der strategischen Architektur und aller ihrer Teilarchitekturen verantwortlich ist. In das Board sollen die Mitglieder Architekturvorschläge aus ihren Projekten einbringen und diskutieren. So wird vermieden, dass in den verschiedenen Projekten entgegengesetzte Architekturentscheidungen getätigt werden und der Unternehmensarchitekt nie wirklich zu einer Soll-Architektur kommt. Die gemeinsamen Architektur-Prinzipien helfen dem Board, eine gemeinsame Basis zu haben.
Im DWH-Beispiel mit den Bestellungen würde der Semantik-Cap der B2B-Bestellung erkannt und könnte so als Architektur-Bedingung in das Projekt miteinfließen.
Zusammenfassung
Das A und O in solchen Projekten ist die Visualisierung und die Besprechungen miteinander (ArchiMate, Architektur Board). Die Gartner Pace-layered Application Strategy hilft, das gegenseitige Verständnis und die gemeinsamen Ebenen zu finden. Die Systeme unterschiedlicher Layer sollen mittels einer Integrationsarchitektur integriert werden, mit der die Komplexität abstrahiert werden kann. Gleichzeit kann entkoppelt werden. Eine Datenarchitektur hilft, weitere – oftmals nicht offensichtliche – Abhängigkeiten zu erkennen. Deshalb hilft eine gemeinsame Sicht auf diese Architektur, die mittels eines Architektur-Boards und eines gemeinsamen Verständnis' gefördert wird. So können die involvierten Architekten der Teilarchitekturen im richtigen Augenblick mit den richtigen Teams sprechen.
Wenn Transformations-Projekte über mehrere Jahre laufen, kann ein Unternehmen nicht plötzlich alle anderen IT-Projekte stoppen. Eine Parallelität wird unumgänglich sein. Dies kann aber zu einer andauernden Unruhe führen, die solche Projekte noch ineffizienter machen. Eine übergeordnete Phasenplanung hilft hier. So können beim Einsatz von SAFe die aktuellen Projekte mit den Transformations-Phasen (PI, Program Incement) geplant werden [5]:
- Wenn die Einführung eines Features in die Transformation zwei PIs später so oder so geplant ist, könnte es Sinn machen, die Ressourcen zu sparen und dies später umzusetzen.
- Wenn in der Transformation an einem Thema in einem PI gearbeitet wird, das Auswirkungen auf andere Projekte haben kann, so muss dieses Team integriert werden.
- Die Abhängigkeiten und Risiken können auch zur Transformation im PI-Planning dargestellt werden.
- Zu beachten ist jedoch, dass Transformations-Phasen in dem Core-Layer oft länger andauern als ein PI (von oft 10 Wochen). Deshalb können nicht immer die Phasen in ein PI gedrückt werden. Dies muss für ein Miteinander akzeptiert werden.
Der vorliegende Artikel entstammt dem Buch "Softwarearchitektur pragmatisch – Der Weg von der Software in die Unternehmens-Architektur" (Philipp Friberg, 294 Seiten, 2022, Hanser Fachbuch, ISBN 978-3-446-47370-6)
Lernen Sie die Architektur-Prinzipien und Muster anhand von Betriebssystemen zu lesen und führen Sie mit diesem Wissen ein Transformations-Projekt der Scotland Trading durch.
- Sie lernen die wichtigsten Software-Architektur-Muster und -Prinzipien kennen.
- Mit Best Practices für die Mitarbeit in der Unternehmensarchitektur.
- Mit einer Einführung in die Modellierungssprache ArchiMate.
- Sie lernen anhand eines durchgängigen Beispiels Schritt für Schritt die Applikations- und Integrationsarchitektur kennen.
- Ph. Friberg: Softwarearchitektur pragmatisch – Der Weg von der Software in die Unternehmens-Architektur, Hanser, München 2022
- Y. Genovese: Accelerating Innovation by Adopting a Pace-layered Application Strategy
- ArchiMate
- TOGAF
- SAFe