Softwarearchitektur

Mit der Pace-layered Strategy im „Brown Field“ navigieren

Die schnelle Einbettung von neuen Fach-Applikationen in bestehende Applikationslandschaften kann die IT vor große Herausforderungen stellen. Diese müssen in der Zusammenarbeit mit der Fachabteilung besprochen werden. Wie kann ihr verständlich erklärt werden, dass es auch Aspekte aus der IT-Sicht zu berücksichtigen gibt? Eine Möglichkeit ist die Gartner Pace-layered Application Strategy. Wie diese angewendet werden kann und das gemeinsame Verständnis fördert, zeigt ein kleines Beispiel.

Philipp Friberg

Author

23.06.2023
Lesezeit: 15 Minuten
74 Views

Kontextsicht für die Einbettung in das Umfeld.
Die Gartner Pace-layered Strategy für die Platzierung des zukünftigen Systems in einem Ordnungsrahmen.
Sicht auf die Daten, um die Auswirkungen auf das (Unternehmens-)Datenmodell und die Integrationsarchitektur abzuschätzen.

Das Umfeld einer Applikation

Die Kontextsicht, auch Kontextabgrenzung genannt, betrachtet die Lösung aus der Vogelperspektive und bettet sie in das Applikationsumfeld ein. Mit einem Diagramm werden die Beziehungen zwischen der benötigten Lösung und den Organisationseinheiten, Geschäftsrollen und Geschäftsfunktionen innerhalb des Unternehmens aufgezeigt (siehe Abbildung 1) [Sta06]. Die neue Applikation wird als Blackbox gezeichnet. Das betroffene Umfeld wird darum herum platziert. Es geht dabei noch nicht um das Verhalten des Systems, sondern um die Interaktionsmöglichkeiten mit dem Umfeld:

Abb. 1: Kontextsicht

Welche Applikationen sind betroffen?
Welche Benutzerrollen interagieren mit der Applikation?
Gibt es andere Systeme, die integriert werden müssen?

Die Applikation, auch wenn auf einer grünen Wiese entworfen, wird in ein Umfeld eingebettet – wie ein Haus auf einer Parzelle, das an andere Parzellen angrenzt und sich an gewisse Gesetzgebungen halten muss: Die Applikation ist auf dem „Brown Field“ angekommen. Aus der Kontextsicht ist erkennbar, mit welchen Systemen welche Daten ausgetauscht werden müssen. Nicht immer ist aber das offensichtlichste System auch schon das optimale System. Es kann einen großen Unterschied machen, ob Artikel aus einem ERP-System oder einem Online-Shop verwendet werden – strategisch, inhaltlich und technisch.

Das fiktive Beispiel-Unternehmen

Um etwas konkreter zu werden, dient als Beispiel das fiktive Unternehmen Scotland Trading. Es betreibt einen Online-Shop, auf dem es verschiedene Produkte aus Schottland anbietet. Damit die Preis-Vergleichsdienste Scotland Trading berücksichtigen, wird vom Fach eine Applikation gefordert, die ihre Produkte an verschiedene Vergleichsdienste weiterleitet. Die Applikation wird Produktfeed genannt. Die Kontextsicht ist in Abbildung 2 ersichtlich. Aus Sicht des Fachs sollen die Produktdaten (Artikel-EAN, Preis, Verfügbarkeit, Versandbedingungen) aus dem Online-Shop bezogen werden. Scotland Trading hat aber auch ein ERP-System. Weshalb kommen diese Daten vom Shop und nicht aus dem ERP? Diese Frage soll aus dem Kontextdiagramm abgeleitet und strategisch beurteilt werden, was weiter unten erfolgt. Eine weitere Anforderung an die Applikation ist, dass anhand von Filter-Kriterien bestimmt werden kann, welche Produkte an welchen Vergleichsdienst übertragen werden.

Abb. 2: Kontextsicht der Applikation Produktfeed

Die strategische Sicht

Ist das gemeinsame Verständnis der fachlichen Einbettung in die Landschaft klar und sind die offenen Punkte identifiziert, kann für die architektonische Einbettung in das Unternehmen die Gartner Pacelayered Application Strategy zur Hilfe genommen werden. Sie ist eine Methodik zur Kategorisierung, Auswahl, Verwaltung und Steuerung von Applikationen zur Unterstützung von geschäftlichen Veränderungen, Differenzierung und Innovation [Gar]. Das Wort Pace wird im Laufsport verwendet und sagt aus, wie viele Minuten für einen Kilometer benötigt werden. Angelehnt an diese Metapher, zeigt dieses Modell auf, dass nicht alle Applikationen dieselbe Pace aufweisen. Die Strukturierung der Applikationslandschaft erfolgt im PACE-Modell auf drei Schichten [Gen12]:

Layer 1: Systems of Record,
Layer 2: Systems of Differentiation,
Layer 3: Systems of Innovation.

Je nach Layer prägen die Applikation folgenden Eigenschaften unterschiedlich:

Veränderbarkeit,
Lifecycle,
Business Impact,
Must haves.

Abbildung 3 zeigt das Modell mit den genannten Layern und Eigenschaften. Wenn Fachanwender von der IT eine Lösung benötigen, sagt nicht selten 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. Durch die Strukturierung der Pace-layered Application Strategy hilft sie, diese Situation besser zu verstehen und möglicherweise besser damit umgehen zu können [Gen12].

Abb. 3: Gartner Pace-layered Application Strategy, Abbildung aus [Fri22]

Applikationen, die die Basis-Geschäftsprozesse unterstützen, werden auf dem Layer 1, Systems of Record, platziert.
Scotland Trading platziert die ERP-Applikation und die Lagersoftware für das Hochregallager auf diesem Layer. Diese haben die Eigenschaft, dass sie die Kontinuität des Unternehmens garantieren müssen und sich nur langsam verändern. Oft spielen auch regulatorische Auflagen eine wichtige Rolle, zum Beispiel die Buchhaltungs- oder HR-Regeln. Wenn der Architekt den Fachabteilungen zuhört, dann lassen sich in diesen Layer allgemein akzeptierte Vorgehensweisen, die sich nur langsam ändern, einordnen. Die Projektlaufzeiten sind eher lang.

Applikationen auf dem Layer 2, Systems of Differentiation, bilden die Einzigartigkeit des Unternehmens bezüglich der Wettbewerbssituation ab. Im Gegensatz zum Layer 1, bei dem die Kontinuität wichtig ist, unterliegen die Applikationen auf diesem Layer einem konstanten Wandel. Scotland Trading platziert den Shop auf diesem Layer. Während ein ERP-System einen Lifecycle über Jahrzehnte aufweist, ist er beim Shop lediglich ein paar Jahre, um den Ansprüchen der Kunden gerecht zu werden. Wenn der Architekt den Fachabteilungen zuhört, 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.

Im Layer 3, Systems of Innovation, befinden sich Systeme, die neue und innovative Geschäftsmodelle unterstützen sollen. Die Applikationen haben einen sehr kurzen Lebenszyklus. Die Diskussion, ab wann etwas innovativ ist, kann eher durch den Lebenszyklus und den Business Impact definiert werden. Es muss dabei nicht gleich eine KI-Lösung sein. Wenn der Architekt den Fachabteilungen zuhört, dann lassen sich in diesen Layer neue Ideen aus Sicht des Unternehmens einordnen. Häufig ist das Konzept in einem frühen Stadium und Einzelheiten der Funktionsweise sind recht vage. Ein schneller Konzeptnachweis, der meist mehrere Iterationen durchläuft, ist hilfreich.

Wo wird die neue Applikation Produktfeed platziert? Anhand der Eigenschaften aus Abbildung 3 wird sie beispielhaft kategorisiert:

Veränderbarkeit: Neue Vergleichsdienste müssen angebunden werden oder bestehende ändern ihr API. Also dürfte die Veränderbarkeit zwischen mittel bis hoch sein. Hier müsste eine Marktrecherche erfolgen. Somit Layer 2 oder 3.
Lifecycle: Mehrere Jahre, aber weniger als ein ERP-System. Also Layer 2.
Business Impact: Für Scotland Tra- ding ist das ein neues Businessmodell, da das Produkt-Management in Zukunft die Platzierung optimieren muss. Es bringt nichts, wenn sie immer der teuerste Shop sind. Anderseits ist das heutzutage „State of the Art“. Tendenz Layer 2.
Must haves: Ohne geht es auf dem Markt nicht. Trotzdem wird eine gewisse Flexibilität durch die Filter gefordert. Das Time to Business kann durch einen Einkauf einer fertigen Lösung reduziert werden. Die Flexibilität bleibt aber wichtig. Also Layer 2.

Daraus folgt, dass der Produktfeed eher auf Layer 2 platziert wird (siehe Abbildung 4). In der Praxis müssten gewisse Aussagen ausdiskutiert werden und könnten den Layer verändern.

Abb. 4: Pace-layered Application Strategy am Beispiel von Scotland Trading

Zwischen den Layern

Das Ziel ist, die Abhängigkeiten zwischen den Applikationen zu reduzieren. Deshalb sollen Applikationen unterschiedlicher Layer mittels einer Integrationsplattform entkoppelt werden. Zertifizierte Schnittstellen sind da aus Sicht des Risikomanagements direkt erlaubt. Das kann zum Beispiel die Anbindung der Lagersoftware an das ERP-System sein. Oftmals werden auch Schnittstellen zwischen Applikationen auf gleichem Layer ohne Integrationsplattform integriert – mit allen Vor- und Nachteilen. Eine weitere Ausnahme kann das Frontend zum Shop sein. Wenn sich das Frontend auch auf Layer 2 befindet, dann kann dies akzeptiert werden. Ist dieses aber auf Layer 1, sollte zumindest ein API-Gateway dazwischengeschaltet werden.

Die neue Applikation Produktfeed benötigt das Datenobjekt Artikel mit den Attributen Verkaufspreis, Verfügbarkeit, Versandkosten und die, die vom Filter verwendet werden. Diese Attribute entstehen nicht im Produktfeed, sondern werden von einer bestehenden Applikation bezogen. Zu jedem Datenobjekt soll es eine führende, verantwortliche Applikation geben. Der Produktfeed verarbeitet die Daten und übermittelt die Informationen an die APIs von Vergleichsdiensten. Somit ist diese Konfiguration auch ein Datenobjekt.
Abbildung 5 zeigt eine mögliche Modellierung des Geschäftsobjekts Artikel in der Modellierungssprache ArchiMate.

Abb. 5: Datensicht vom Geschäftsobjekt Artikel

Das Datenobjekt Artikel mit den wichtigsten Grunddaten realisiert das Geschäftsobjekt Artikel. Spezialisierungen gibt es für den Artikel ERP. Dieser beinhaltet die ERP-Sichten, zum Beispiel die Lagerverwaltung (nicht abgebildet). Die Produkt-Spezialisierung enthält zusätzlich verkaufsfördernde Daten wie Bilder, Videos usw. Die Komponente Produktfeed braucht nur Daten vom Datenobjekt Artikel. Aus dieser Sicht wird klar, dass nicht unbedingt der Shop die Daten liefern muss. Es ist die erste Diskrepanz zur Kontextsicht feststellbar. Die zentrale Frage ist, welche Applikation das führende System für den Artikel ist. Aus Abbildung 5 ist ersichtlich, dass es nur Systeme für die Spezialisierungen gibt. Das Produkt entsteht aus dem Artikel ERP, indem es dem Shop übermittelt und angereichert wird. Somit gibt es verschiedene Argumentationen, zum Beispiel:

Der Produktfeed soll den Artikel aus dem ERP erhalten, da das ERP führend ist.
Gemäß dem PACE-Modell ist der Pro- duktfeed näher (gleicher Layer) am Shop, was für das Produkt spricht.
Das ERP ist für einen langfristigen Lifecycle ausgelegt und deshalb wird die Schnittstelle langlebiger sein.

In der Realität dürfte der Artikel ein viel benutztes Datenelement sein. Wenn es eine Integrationsplattform gibt, so könnte diese den Artikel über eine Publish-Subscribe-Architektur allen notwendigen Systemen einheitlich zur Verfügung stellen. Dies ist eine Eigenschaft, die die PACE-Strategie aufzeigen kann: Der Layer 1 stellt Objekte dem Layer 2 entkoppelt über eine Integrationsplattform (als Bus, Publish-Subscribe, …) einheitlich zur Verfügung. Der Layer 2 stellt dann die Services für den Layer 3 zur Verfügung. Ist diese Strategie so umgesetzt, dann soll der Produktfeed die Artikel-Daten von der Integrationsplattform beziehen und somit vom ERP. Hiermit ist eine Navigation im „Brown Field“ vorhanden.

Anwendung der PACE-Strategie

Die Anpassung der Datenquelle vom Shop zum ERP erfolgte aufgrund der PACE-Strategie. Eine weitere Frage ist, ob auf der freien Parzelle ein Fertighaus, somit eine eingekaufte Software, oder ein Haus nach Kundenvorstellung, also eine Eigenentwicklung, gebaut werden soll. Das sind zwei Extrem-Situationen, eine dritte Möglichkeit besteht darin, dass eine bereits vorhandene Applikation um die Funktionen des Produkfeeds erweitert wird – um bei der Analogie zu bleiben, das Haus um einen Hausteil erweitert wird. Mit der Bewertung auf die vier Eigenschaften der PACE-Strategie ergeben sich Kriterien, um diese Frage zu beantworten. Beim Szenario Eigenentwicklung hat die Einordnung auf einem der drei Layern unterschiedliche Auswirkungen:

Integration: Im Layer 1 wird tendenziell mit einem Peer-to-Peer-Muster integriert. Richtung Layer 2 über ein Kommunikations-Szenario der Integrationsplattform und zu und vom Layer 3 über einen API-Gateway.
Verwendung der Bibliotheken: Während im Layer 3 durch die Kurzfristigkeit und den experimentellen Aspekten auch solche Bibliotheken verwendet werden dürfen, sollten im Layer 1 eher etablierte, auf Performance ausgelegte Bibliotheken verwendet werden.
Software-Design: Während beim Layer 1 der Durchsatz Priorität hat, wird im Layer 2 der Servicegedanken wichtig sein.
Business Impact: Dieser ist beim Rollout und dem Betrieb nicht zu unterschätzen und hat wahrscheinlich Einfluss auf das Design und das Projekt.
Projektmanagementmethode: Ein agiles Projektmanagement ist in Layer 3 nicht wegzudenken. Das Time to Business und die hohe Veränderbarkeit fördern dies regelrecht. Auf Layer 1 wird durch den Business Impact eher eine Methode gewählt, die Prozess- und Qualitätsmanagement im Fokus hat und meilensteinorientiert ist [Zen].

Beim Szenario Software-Einkauf sind mögliche Auswirkungen auf die Architektur:

Integration: Die beste Software bringt nichts, wenn die Daten nicht unternehmenskonform in und aus der Software geladen werden können.
Lifecycle: Er bestimmt die Lizenzkosten und Wartungsverträge mit. Im Layer 1 kann eine Lieferantenbeurteilung helfen, wie wahrscheinlich es ist, dass der Lifecycle eingehalten werden kann.
Business Impact: Das Produkt muss den Business Impact unterstützen und nicht nur Funktionen anbieten.
Veränderbarkeit: Sie kann durch Release-Zyklen und der Möglichkeit zur Mitsprache von Weiterentwicklungen abgeschätzt werden.

Es gibt bestehende Applikationen, die mit einem Plug-in erweitert werden können. Dieses kann eingekauft oder selbst entwickelt werden. Wichtig dabei ist, dass das Architektur-Prinzip Offen-Geschlossen [Mar96] gewährleistet werden kann: offen für Erweiterungen, geschlossen für Modifikationen. Das Ziel ist, dass der Kern der Applikation stabil gehalten werden soll (Keep the core clean). Welche Applikation soll als Basis dienen?

Layer: Die Applikationen sollten auf dem gleichen Layer sein. Befinden sie sich auf unterschiedlichen Layern, besteht die Gefahr, dass die Eigenschaften sich gegenseitig beißen.
Datenobjekte: Es ist am sinnvollsten, wenn über die Hälfte der Datenobjekte bereits in der Applikation vorhanden sind.
Plattform: Sie sollte bereits die geforderten Technologien bieten. Wird zum Beispiel ein Regel-Framework benötigt, sollte dies auch angeboten werden.
Team: Es ist aus Sicht der Architektur nicht sinnvoll, die Entwicklung auf einer Applikation oder Technologie umzusetzen, nur weil das Team gerade Zeit hat. Die PACE-Strategie kann hier helfen zu erklären.

Fazit

Die Einordnung einer Applikation in die drei Layer des PACE-Modells hilft, die Applikationsarchitektur zu gliedern und eine Strategie zu definieren. Eine Applikation auf dem Layer Systems of Innovatio n muss losgelöst von einem ERP-System sein, das sich auf dem Layer Systems of Record befindet. Die vier verschiedenen Merkmale helfen, die Applikation zu positionieren. Somit lässt sich die dazugehörige Strategie besser erkennen und erklären. Dieses gemeinsame Verständnis fördert die Kommunikationskultur. Sind die Merkmale einer Applikation identifiziert, können verschiedene Anforderungen an die Softwarearchitektur abgeleitet werden, wie zum Beispiel die Verwendung von möglichen Bibliotheken. Die Entscheidung zwischen Kaufen versus Eigenentwicklung kann besser beurteilt und argumentiert werden. Zusammen mit der Kontextsicht, der Datensicht und einer Integrationsarchitektur ist eine Landkarte vorhanden, auf der sich im „Brown Field“ navigieren lässt.