Gross denken, klein anfangen: Evolutionsarchitektur

Dieser Beitrag stammt aus eunserer Blogserie zum Thema digitale Unternehmensarchitektur. Bisher veröffentlicht wurden die Beiträge:

• Teil 1: IT Architektur im Kontext der digitalen Transformation
• Teil 2: 4 Frameworks für die Unternehmensarchitektur
• Teil 3: Die Vorteile einer Geschäftsarchitektur
• Teil 4: Was ist eine Technologie-Architektur?
• Teil 5: Wie Sie Geschäfts- und Technologie-Architektur auf eine Linie bringen

Die Evolutionsarchitektur beschreibt die Dynamik, wie sich ein Unternehmen verändert, d.h. welche Projekte und Veränderungsprogramme es mit welchen Zielen und Ressourcen ausführt. Je besser ein Unternehmen seine Dynamik managen kann, desto agiler kann es sich neuen Gegebenheiten anpassen. In der Unternehmensarchitektur werden oft Beschreibungen des Unternehmenszustands zu verschiedenen Zeitpunkten erstellt. Gängig sind:

• IST-Modell: Eine Beschreibung des aktuellen Unternehmenszustands. Ein IST-Modell wird verwendet, um fundierte operative Entscheide im Tagesgeschäft zu treffen.
• SOLL-Modell: Eine Beschreibung eines möglichen Zustands des Unternehmens in seiner Zukunft. Da sich ein Unternehmen zu einem gegebenen Zeitpunkt in verschiedene Richtungen entwickeln kann, sind auch mehrere (parallele) SOLL-Modelle denkbar. SOLL-Modelle werden für Planungszwecke, aber auch als Entscheidungsgrundlage für Variantenvergleiche genutzt. Aus den einen oder anderen SOLL-Modellen werden im Verlaufe der Zeit (hoffentlich) einmal IST-Modelle.

Formal handelt es sich bei diesen Modellen um mögliche Welten mit Trans-Welt-Identitäten 1, was einen Unternehmensarchitekten zwar kaum kümmern muss, einen Werkzeug-Hersteller, der Zeitaspekte in Modellen unterstützen möchte, dafür umso mehr. Etwas weniger gängig, aber in gewissen Fällen trotzdem hilfreich, sind Vergangenheits-bezogenen Modelle:

• WAR-Modell: Eine Beschreibung des Unternehmenszustands in der Vergangenheit. Ein WAR-Modell war früher einmal ein IST-Modell.
• WAR NIE-Modell: Eine Beschreibung des Unternehmenszustands, der in der Vergangenheit einmal geplant war, so aber nie in die Realität umgesetzt wurde. Ein WAR NIE-Modell war früher einmal ein SOLL-Modell.

Diese Vergangenheits-bezogenen Modelle dienen einerseits dafür, um die historische Entwicklung eines Unternehmens nachvollziehen zu können. Andererseits stellen insbesondere die WAR NIE-Modelle einen Fundus von Ideen dar, die zwar in der Vergangenheit verworfen wurden, in Zukunft aber vielleicht doch wieder aufgegriffen werden können. Das folgende Bild illustriert die Entwicklung eines Unternehmens im Verlauf der Zeit anhand obiger Modelltypen:

Quelle: KnowGravity

IST- und WAR-Modelle zeigen die sequentielle Geschichte eines Unternehmens in verschiedenen Modellversionen. Demgegenüber sind SOLL- und WAR NIE-Modelle parallele, hypothetische Modellzweige (auch «Branches» genannt).

Agile Entwicklung versus agile Systeme

Wenn wir über Agilität in der Entwicklung sprechen, so gibt es zwei zum verwechseln ähnliche, aber fundamental unterschiedliche und teilweise gegensätzliche Ziele:

• Ein System wird agil entwickelt
• Ein agiles System wird entwickelt

Ob dabei mit «System» eine Software, eine Maschine oder ein Unternehmen gemeint ist, ist sekundär. Je nach dem, ob das eine oder das andere dieser beiden Ziele verfolgt wird, resultiert daraus eine deutlich andere Architektur des entstehenden Systems.

Wird ein System agil entwickelt, so geht es darum, möglichst rasch die im Moment nützlichste Funktionalität bereitstellen zu können. Ist dieser erste Schritt einmal erledigt, so wird aufgrund der damit gewonnenen Erkenntnisse erneut bestimmt, was als nächstes die nützlichste Funktionalität ist, die umgesetzt werden soll. Ein Hauptproblem dieses Ansatzes ist, dass dabei die Architektur des Systems (d.h. seine Anatomie) oft auf der Strecke bleibt und dadurch dessen Weiterentwicklung immer schwieriger wird. Als Gegenmassnahme wird ein regelmässiges «Architektur-Refactoring» empfohlen, d.h. die Anatomie des Systems muss jeweils an die bisherige Evolution seiner Funktionalität angepasst, stabilisiert und optimiert werden. Man spricht dabei auch von einer «emergenten Architektur».

Wird ein agiles System entwickelt, so wird versucht, die Anatomie des Systems so zu gestalten, dass es auch in Zukunft einfach neuen Anforderungen angepasst werden kann. Dazu ist es erforderlich, gewisse «Stellschrauben» und «Platzhalter» in die Architektur einzubauen, über die sich in Zukunft die Funktionalität des Systems relativ einfach anpassen oder erweitern lässt. Diese «Stellschrauben» und «Platzhalter» sind «Variationspunkte» der Architektur, die zukünftig eine flexible «Rekonfiguration» des Systems ermöglichen. Ein Hauptproblem dieses Ansatzes ist, dass es schwierig ist, die Zukunft des Systems frühzeitig zu antizipieren und dass in einer ersten Phase relativ viel konzeptionelle Vorarbeit erforderlich ist, ohne dass dabei schon viel Funktionalität entsteht (auch als «Upfront-Thinking» bezeichnet). Als Gegenmassnahme bieten sich Variantenvergleiche (siehe SOLL-Modelle oben) oder Simulationen (z.B. der Betriebskosten) an, die allerdings allesamt viel Erfahrung erfordern.

Variabilität und Varianten

Eine zentrale Eigenschaft eines komplexen Systems ist dessen Variabilität, d.h. dessen Anpassungsfähigkeit an unterschiedliche Bedürfnisse und Situationen. Mit «System» sind hier nicht nur technische Systeme im engeren Sinn gemeint, sondern auch Services oder gar das ganze Unternehmen selber. In unserer fiktiven Fallstudie «EU-Rent» sind beispielsweise die folgenden Variabilitäten vorstellbar:

• Ein von einem Kunden reserviertes Fahrzeugmodell kann bei Nicht-Verfügbarkeit durch eines der nächst höheren Kategorie ersetzt werden.
• Ein von einem Kunden reserviertes Fahrzeugmodell kann ein Cabrio sein, dann muss der Fahrer allerdings mindestens 25 Jahre alt sein und es ist eine Zusatzversicherung erforderlich.
• Die Versicherung für einen Mietvertrag kann für einen explizit genannten Fahrer oder für eine (anonyme) Gruppe mehrerer Fahrer abgeschlossen werden. Im ersten Fall läuft die Versicherung auf deren Fahrer, im zweiten Fall auf EU-Rent.
• Das primäre Rechenzentrum von EU-Rent steht in München, im Störfall kann aber auf die Backup-Infrastruktur in Frankfurt umgeschaltet werden. In diesem Fall müssen aber Fahrzeug-Subskriptionen (ein spezielles Mietmodell) durch einen Mitarbeiter von EU-Rent abgeschlossen werden, da das Backup-System dieses Mietmodell noch nicht über das Web anbietet.

Variabilität kann in ein System hinein konstruiert werden, um es resilienter zu machen. Dazu können «Stellschrauben» vorgesehen werden, die sich bei Bedarf einstellen bzw. verändern lassen. Zwei verschiedene Fälle lassen sich unterscheiden:

• Konfiguration: Der Prozess der initialen Massschneiderung eines Systems auf spezifische Bedürfnisse
• Re-Konfiguration: Der (ggf. wiederholte) Prozess der dynamischen Anpassung eines Systems an eine neue Situation

Um die Variabilität eines Systems beschreiben zu können, sind drei Elemente erforderlich:

• Variationspunkte: Explizite, bekannte Stellen, an denen das System verändert oder erweitert werden kann
• Varianten: Optionen, die für einen gegebenen Variationspunkt zur Verfügung stehen
• Variationsregeln: Abhängigkeiten und Einschränkungen, die zwischen Variationspunkt und zwischen Varianten bestehen

Soll Variabilität graphisch dargestellt werden, so bietet sich dazu beispielsweise OVM (Orthogonal Variability Modeling) 2 als Modellierungssprache an. Sind einem Unternehmen bzw. seinem Unternehmensarchitekten die wichtigen Variationspunkte sowie deren Einfluss auf die operativen Zusammenhänge erst einmal bewusst, so kann es viel einfacher auf veränderte Bedürfnisse und neue Situation reagieren.

Evolution in Architektur-Frameworks

Das klassische Zachman Framework für Unternehmensarchitektur (siehe auch Teil 2 dieser Artikelserie) beschreibt in 6 Dimensionen aus 5 Perspektiven, welche Aspekte eines Unternehmens zumindest potentiell beschreibenswert sind. Alle diese Aspekte beschreiben aber den Zustand des Unternehmens, entweder heute (IST-Modell) oder in einer von mehreren möglichen Zukünften (SOLL-Modelle). Sie sind somit statische Beschreibungen des Unternehmens.

TOGAF als weit verbreitetes und sehr umfassendes Framework für Unternehmensarchitektur bietet mit der Architecture Development Method (ADM) einen dynamischen Aspekt der Unternehmensarchitektur. Dabei handelt es sich aber mehr um ein generisches Vorgehensmodell, wie TOGAF in einem Unternehmen eingeführt und am Leben gehalten werden kann als einen Ansatz, wie ein Unternehmen dynamischer oder auch agil werden kann.

In dem von uns entwickelten MDEE-Framework haben wir neben den statischen «Was» und «Wie» Beschreibungen des «Geschäfts» sowie der unterstützenden Technologie (jeweils IST und SOLL) einen separaten Bereich «Change» vorgesehen, in dem dynamische/transiente Aspekte der Unternehmensarchitektur abgebildet sind. Dazu zählen…

• Variationspunkte im Unternehmen sowie seinen Produkten und Dienstleistungen
• Veränderungsvorhaben wie Projekte, Meilensteine und Change Requests
• Wichtige Entscheidungen, die in der Vergangenheit getroffen wurden, inklusive deren Begründungen
• Informations-Artefakte wie Dokumente, Statistiken, SW-Code, etc.
• Automatisierte Prozesse zur konsistenten Durchführung von Änderungen (Modell-Transformationen)
• Gültige Prinzipien, Qualitätsregeln, Richtlinien und Metriken zur Unterstützung der Architektur-Governance

Quelle: KnowGravity

Nutzen einer Evolutionsarchitektur

Hauptaufgabe der Evolutionsarchitektur ist die ganzheitliche Unterstützung der Weiterentwicklung eines Unternehmens. Dazu zählen im wesentlichen vier Punkte:

• Auf der Basis des aktuellen IST-Modells lassen sich fundierte operative Entscheide fällen.
• Durch den Vergleich verschiedener SOLL-Modelle lässt sich zu jedem Zeitpunkt die optimale Richtung der Weiterentwicklung des Unternehmens bestimmen.
• Auf der Basis des aktuell gewählten SOLL-Modelles lassen sich Ziel-Vorgaben und Prinzipien für Veränderungsvorhaben ableiten.
• Aus den Differenzen zwischen dem aktuellen IST-Zustand und einem angestrebten SOLL-Zustand des Unternehmens lassen sich Realisationsschritte für Veränderungsvorhaben ableiten.

Quelle: KnowGravity

In der Praxis ist es durchaus üblich, dass gleichzeitig mehrere, parallel gültige SOLL-Teilmodelle existieren. Dies heisst nichts anderes, als dass mehrere parallele Change-Projekte durchgeführt werden. Dabei ist eine pragmatische Ausrichtung der lokalen Ziele der einzelnen Projekte an der globalen Ausrichtung des Unternehmens essentiell. Die Sicherstellung dieses Alignments ist wiederum eine Kernaufgabe der Evolutionsarchitektur.

Die Beschreibung der Evolutionsarchitektur soll also nicht nur Fragen zum aktuellen Zustand des Unternehmens beantworten können, sondern auch dessen Weiterentwicklung unterstützen. Somit stehen die folgenden typischen Fragestellungen im Vordergrund:

Gegenwartsbezogene Fragestellungen

• Wie häufig wird Applikation X genutzt und wie häufig verursacht sie Probleme?
• Wann muss der Lizenzvertrag X verlängert oder gekündigt werden?
• Welche Aufwände/Kosten/Probleme verursacht Abteilung X?
• Welche Vorhaben sind aktuell im Gang?
• Was sind unsere grössten Risiken, die adressiert werden müssen?

Vergangenheitsbezogene Fragestellungen

• Wie hat sich die Fehlerrate von Prozess X entwickelt?
• Wie hat sich die Nutzung von Applikation X entwickelt?
• Warum hatten wir uns damals gegen den Ersatz von Applikation X entschieden?

Zukunftsbezogene Fragestellungen

• Bis wann soll Applikation X ersetzt werden?
• Soll zuerst Applikation X oder Applikation Y ersetzt werden?
• Was fehlt noch bis zum Ziel X?
• Welche fehlende Capability soll zuerst aufgebaut werden?
• Welche Kosten entstehen, wenn wir Plan X umsetzen würden?
• Was ist der optimale Zeitpunkt, um Projekt X zu starten?
• Welchen Impact hätte Ereignis X auf das Unternehmen?
• Wie erreichen wir am schnellsten / günstigsten Ziel X?

Insbesondere die letzten vier Fragestellungen sind «Was wäre wenn»-Fragen, die je nach Werkzeug-Unterstützung bis hin zu komplexen Unternehmenssimulationen führen können. Um dies zu ermöglichen, ist die Überwachung des aktuellen Gesundheitszustandes und des sich verändernden Umfelds des Unternehmens eine zentrale Aufgabe der Unternehmensarchitektur.

Ein Metamodell zur Beschreibung der Evolution eines Unternehmens

Bereits im ersten Teil dieser Artikelserie habe ich aus TOGAF zitiert, was «Architektur» bedeutet:

«Architektur ist eine formale Beschreibung der wesentlichen Komponenten eines Systems, deren Beziehungen untereinander sowie der Prinzipien und Richtlinien zur Gestaltung und Evolution des Systems.»

Es stellt sich also wiederum die Frage, was die «wesentlichen Komponenten» einer Evolutionsarchitektur sind. Dies lässt sich auf der Basis der 7 «W-Fragen» beantworten:

Wer macht wann warum womit wo wie was?

Diese Elemente erlauben es der Evolutionsarchitektur, Vorgaben wie das folgende Beispiel zu machen:

«Team X (WER) realisiert bis Ende Jahr (WANN) in allen Standorten in Deutschland (WO) das Customer Relationship Management (WAS) durch die neue Applikation XYZ (WOMIT), welche in der Cloud betrieben wird (WIE), da die heutige Applikation ABC in 2 Jahren vom Hersteller nicht mehr weiter gepflegt wird (WARUM).»

Aus diesen sieben Grundpfeilern lassen sich Entitäten bilden, die das grundlegende Metamodell der Evolutionsarchitektur bilden:

Quelle: KnowGravity

Wichtig dabei ist zu beachten, dass die Evolutionsarchitektur orthogonal zu den anderen Architekturen ist, d. h. sie nimmt Bezug auf die Entitäten der anderen Architekturen, um deren Veränderungsaspekte zu beschreiben.

Fazit

Die Architektur eines Unternehmens muss sich im Verlauf der Zeit entwickeln und das Management dieser Entwicklung ist eine zentrale Aufgabe des Unternehmensarchitekten. Die Evolutionsarchitektur unterstützt eine solche Entwicklung durch die Inventarisierung wichtiger Entscheidungsgrundlagen sowie Vorgaben für die zukünftige Evolution des Unternehmens. Eine zentrale Heuristik, die bei solchen Vorhaben aber immer zur Anwendung kommen soll, ist «Gross denken, klein anfangen»!

Weiterlesen:

• Teil 1: IT Architektur im Kontext der digitalen Transformation
• Teil 2: 4 Frameworks für die Unternehmensarchitektur
• Teil 3: Die Vorteile einer Geschäftsarchitektur
• Teil 4: Was ist eine Technologie-Architektur?
• Teil 5: Wie Sie Geschäfts- und Technologie-Architektur auf eine Linie bringen

Referenzen:

• 1 https://plato.stanford.edu/entries/identity-transworld/
• 2 https://knowgravity.com/pdf-e/Presentation%20SWISSED%202017%20Model-based%20Engineering%20of%20Product%20Lines%20(E).pdf