So kommt mehr Agilität in Ihre IT-Architektur

EAM versus agil

Im Enterprise Architecture Management (EAM) schnell und agil einen Mehrwert generieren? Geht das? EAM dient dazu, alle IT-Systeme eines Unternehmens auf seine organisatorischen Ziele auszurichten. Der Schwerpunkt liegt auf klar definierten Zielen und Prozessen. Dafür betrachtet man einen Zeithorizont von zwei bis fünf, teilweise sogar bis zu zehn Jahren. Wie passt diese lange, strategisch notwendige Vorausplanung mit agilen Kontexten und noch unbekannten Problemen zusammen?

Mit dieser Frage habe ich mich im Rahmen meiner Forschungsarbeit beschäftigt. Inspiration dafür war das Konzept des Minimum Viable Products (MVP): Organisationen wollen ihre Produkte schneller für ihre Kunden zur Verfügung stellen, um früh Aufmerksamkeit zu erhalten und sich Feedback einzuholen. Dabei werden nur die Funktionen implementiert, die für ein erstes Kundenfeedback unbedingt notwendig sind.

MVP für Unternehmensarchitektur

Um dieses Konzept auf Unternehmensarchitekturen zu übertragen, habe ich ein Vorgehensmodell entwickelt, um eine Minimum Viable Architecture (MVA) zu entwickeln. Der Leitfaden soll Enterprise Architects helfen, schnell und agil einen Mehrwert mit „genau genug Architektur“ [Ben12] für ihr Unternehmen zu generieren.

Das Vorgehensmodell besteht aus zwei Kernelementen:

• Analyse und Evaluation unterschiedlicher Artefakte
• Fragenkatalog zur Ersteinschätzung des Umfangs eines Kundenauftrags

Visualisierung schafft Transparenz

Wer über die Jahre gesammelte Informationen und Daten aus unterschiedlichen Systemen visualisiert, schafft Transparenz und macht Abhängigkeiten sichtbar. Um geeignete Visualisierungsmöglichkeiten im EAM zu ermitteln und analysieren, wurden Interviews mit Expert:innen in diesem Gebiet geführt. Sie nannten folgende Artefakte als nützlich:

Big Picture: Großformatige Darstellung des Scopes (z.B. Systeme, Informationen, Stakeholder), die der späteren Kommunikation mehrerer Stakeholdergruppen dient, um sie an einem gemeinsamen Verständnis auszurichten.

Prozesslandkarte / Geschäftsprozessmodell: Diese bildet alle Prozesse im Unternehmen oder in dem für das Projekt festgelegten Umfang ab. Nach fachlichen Domänen sortiert werden die Geschäftsprozesse gruppiert. [Han16]

Business Capability Map (BCM): Die BCM stellt die Geschäftsfunktionen eines Unternehmens unabhängig von der Organisationsstruktur oder den Prozessen dar. [Lea21]

Flussdiagramm: Dieses bildet den deterministischen Verlauf eines Prozesses, Systems oder Algorithmus ab.

Bebauungsplangrafik: Sie visualisiert in Form einer Matrix, wie die Elemente der Unternehmensarchitektur zusammenhängen. [Han16]

Applikations- oder Anwendungslandschaft: Sie stellt alle oder einen Teil der betrieblichen Informationssysteme in Unternehmen dar.

Diese Visualisierungsmöglichkeiten wurden nach Kriterien wie Agilität, Menge involvierter Stakeholder und die Komplexität der benötigten Informationen zur Erstellung eines Artefakts im Laufe der Interviews bewertet. Die Grafik zeigt, dass sich nicht alle Artefakte gleichermaßen eignen, beziehungsweise mit einem gewissen Risiko verbunden sind.

Welchen Umfang soll eine Minimum Viable Architecture haben?

Mit dem Fragenkatalog als zweitem Kernelement des Vorgehensmodells lässt sich der Umfang einer MVA bestimmen. Das ist enorm wichtig. Andernfalls ist er zu groß und die MVA sprengt in Folge dessen den Rahmen oder ist bereits vor Veröffentlichung veraltet.  Ist der Umfang zu gering, enthält die MVA zu wenige  Informationen, beziehungsweise lieferte keinen Überblick.

Implementiert werden nur die notwendigsten Kernkomponenten als Fundament einer künftigen IT-Landschaft, was dann auf Basis konkreter Anforderungen iterativ erweitert wird. Durch kontinuierliches Testen der Inkremente kann die MVA – wie auch ein MVP – weiterentwickelt und an neue Kundenanforderungen angepasst werden, was die Agilität in Unternehmen fördert.

So können Enterprise Architects den Scope bestimmen

Fragenkatalog

Welches Ziel wollen Sie erreichen? Was ist ihre Vision?

Was ist der zeitlich festgesetzte Rahmen für das Projekt?

Gibt es in Ihrem Unternehmen bereits angefertigte Artefakte

Wenn ja: Auf welchem Stand befinden sie sich und können Sie Zugriff darauf gewähren?

Wer sind die wichtigsten Stakeholder und Mitglieder des Kernteams?

Auf welchem Stakeholder kann für einen ersten Entwurf nicht verzichtet werden?

Wo liegt die Verantwortung bzw. wie ist diese verteilt?

Haben Sie Daten und Unterlagen zu dem Thema gesammelt, die Sie zur Verfügung stellen können?

Arbeiten Sie in Ihrem Team agil und sind Scrum oder Kanban für Sie geläufige Begriffe?

Wo sehen Sie bereits jetzt Handlungsbedarf?

Ist der von Ihnen genannte Handlungsbedarf weiter einschränkbar? Was passiert, wenn er nicht zu 100% umgesetzt wird?

Ist der Rahmen des Projektumfangs durch den Fragenkatalog definiert, kann der Enterprise Architekt auf eine Auswahl aus den Artefakten für die MVA des Use Cases zugreifen und diese erarbeiten.

Zwei Fallstudien für den Einsatz

Als letzten Schritt habe ich das Vorgehensmodell anhand verschiedener Fallstudien theoretisch getestet und evaluiert. Die Studien dienen als Praxisbeispiele und orientieren sich an den Standardbeauftragungen im EAM.

1. Bebauung auf Unternehmensebene

Ziel ist es, einen IST-Bebauungsplan zu erstellen und daraus Handlungsbedarfe abzuleiten. Dadurch lassen sich Unstimmigkeiten und Redundanzen bezüglich der System-Funktionsabdeckung, sowie die Verantwortung einzelner Geschäftsobjekte aufzeigen.

2. Bebauung auf Projektebene

Ein Altsystem soll abgelöst und eine Strategie entwickelt werden, um ein neues, strukturiert aufgebautes System zur Verfügung zu stellen. Das kann Funktionalitäten eines bestehenden Systems nutzen, um so Redundanzen zu vermeiden und Synergien zu schaffen.

Bei Fallstudie 1 ist die Erstellung einer MVA nur durch die Verringerung der Anzahl von Artefakten und der Granularität möglich. Da es sich um eine Bebauung auf Unternehmensebene handelt, kann der Fokus nicht nur auf einzelne, spezielle Domänen gelegt werden. Im Gegensatz dazu fokussiert sich die Projektebene der zweiten Fallstudie viel stärker auf einzelne Bereiche und Prozesse. So ist sind gewisse Artefakte in wesentlich kürzerer Zeit erstellt, betrachten aber auch nur einen kleineren Abschnitt der IT-Architektur.

Bei der Bearbeitung beider Fallstudien wurde deutlich, dass es sich bei einer MVA lediglich um den Einstiegspunkt in ein Projekt handelt. Dieser bietet eine gute Basis und fördert das anschließende iterative Weiterentwickeln der Unternehmensarchitekturen in agilen Umgebungen.

Fazit

In der heutigen Zeit stehen Schnelligkeit und Agilität dem Wunsch nach Überblick gegenüber. Traditionelles EAM stößt an seine Grenzen, da es oft einer langen Vorausplanung bedarf und gleichzeitig wenig Platz für Unschärfen lässt.

Das Vorgehensmodell zur Erstellung einer MVA schafft da Abhilfe. Es wird zunächst ein grober Überblick geschaffen und nur das unbedingt Nötige erarbeitet, um schnell an Kundenfeedback zu gelangen. Auf dieser Basis kann im weiteren Verlauf iterativ aufgebaut werden. Das fördert Agilität im Umfeld des EAM und bietet eine Möglichkeit, schnell für Kunden einen Mehrwert zu generieren.

Für weitergehende Informationen oder einen unverbindlichen Austausch kontaktieren Sie mich gerne unter julia.fischer@maibornwolff.de.

Literatur

[Ben12] Bente et al., Collaborative Enterprise Architecture, 2012

[Han16] Hanschke, Inge, Enterprise Architecture Management – einfach und effektiv, 2016

[Lea21] LeanIX GmbH, Guide: Business Capability Map | LeanIX

---

Über die Autorin