ObjektSpektrum 06/10

Agilität und EAM: Leichtgewichtige Unternehmensarchitekturen

Autor:

Niemand bestreitet die Wichtigkeit eines Enterprise Architecture Management (EAM) als zentrales Bindeglied zwischen IT-Strategie, Implementierung, Betrieb und Governance sowie zur Sicherstellung einer werthaltigen und auf die Ziele des Business ausgerichteten IT. Die Einführung eines EAM ist aber nach wie vor ein schwieriges Unterfangen, an dem viele Unternehmen scheitern oder kaum Mehrwert aus dem etablierten EAM ziehen. Dieser Artikel beschreibt, wie man mit Hilfe der agilen Grundwerte die Klippen bei der Einführung eines EAM erfolgreich umschiffen kann.

Ziele von Enterprise Architecture Management

Enterprise Architecture Management (EAM) hat sich in den letzten Jahren aus seinem Schattendasein herausbewegt. Obwohl sich das Thema bis in die 1980er Jahre zurückverfolgen lässt (u.a. [Zac87]), hat es noch viele Jahre gedauert, bis die Wichtigkeit des Themas in der Breite erkannt worden ist. „(Unternehmens-)Architektur wird benötigt, um Komplexität und Änderbarkeit zu managen”, hat es John Zachman, der Urvater des EAM, kurz und prägnant auf den Punkt gebracht [Zac08]. EAM ermöglicht es, auf einer Unternehmens-IT-Ebene die ausufernde Komplexität in den Griff zu bekommen und die Adaptionsfähigkeit der IT an die Anforderungen des Business – Stichwort: „Business-IT-Alignment” – sicherzustellen.

Neben dem Erhalt der Reaktionsfähigkeit der IT auf die sich ständig ändernden Anforderungen des Business bietet EAM auch ein mächtiges Instrument zur Kostenkontrolle und zum Risiko-Management, indem es Redundanzen und Lücken im IT-Portfolio sichtbar macht und alle IT-Assets mit den treibenden Fachanforderungen und Prozessen in Verbindung bringt – Stichwort: „Transparenz”. Letztlich bildet EAM das der Autor Bindeglied zwischen der IT-Strategie und der Umsetzung und stellt so sicher, dass die IT-Strategie zielgerichtet und nachhaltig umgesetzt wird und so (neue) Werte für das Unternehmen schafft. Zusammengefasst sind die wesentlichen Ziele von EAM noch einmal in Abbildung 1 dargestellt.

Ziele von EAM

Probleme framework- und werkzeugbasierter Ansätze

Hat ein Unternehmen die Wichtigkeit von EAM erkannt, ist es folgerichtig daran interessiert, EAM im eigenen Haus einzuführen. An der Stelle beginnen häufig die Probleme: Typischerweise wird ein Team damit betraut, einen Vorschlag für die EAM-Einführung zu erarbeiten. Es wird dann begonnen, die existierende Literatur im Internet sowie in Buch- und Artikelform zu recherchieren und sich tiefer in das Thema einzuarbeiten. Dabei werden schnell EA(M)-Frameworks wie TO GAF, Zach man, DoDAF, FEAF, etc. (für einen Überblick siehe z. B. [EAF]) entdeckt. Und da meistens keine der Personen tiefergehende Erfahrungen mit der Einführung von EAM in einem Unternehmen hat, einigt man sich normalerweise schnell darauf, sich bei der Einführung an einem der Frameworks zu orientieren.

Das ist grundsätzlich auch keine schlechte Idee, hat aber einen Haken: Stellt man ein Framework in das Zentrum seiner EAM-Einführung, erliegt man schnell dessen Umfang und dessen generellem Ansatz. Somit sind plötzlich nicht mehr die eigenen, unternehmensrelevanten EAM-Ziele, sondern der Aufbau eines unternehmensweiten Architekturmodells und eine entsprechende Governance (-Abteilung) im Zentrum des Bemühens des EAM-Teams. Also kurz: die Möglichkeiten des Frameworks formen das neue Ziel.

Hier könnte man widersprechen: „Damit das nicht passiert, sehen die meisten Frameworks ein Tailoring vor oder liefern Vorgehensmodelle, in denen das Framework auf die Belange des Unternehmens angepasst wird.“ Das stimmt zwar, aber da Frameworks eine Art Vereinigungsmenge von Lösungen zu vielen Aufgabenstel – lungen bieten, verlieren sich viele Menschen in dieser Vielfalt schnell und es fällt ihnen schwer, den Überblick zu behalten bzw. eine sinnvolle Einschränkung gemäß den Zielen des Unternehmens zu treffen. Es entsteht so oft eine Lösung, die wesentlich größer ist, als man sie eigentlich gebraucht hätte.

Das zweite Problem ist etwas diffiziler: Frameworks bieten Lösungen für sehr viele Fragestellungen, aber eben nicht für alle an, suggerieren aber, dass sie alle potenziell relevanten Fragestellungen, sprich Ziele, abdecken. Das ausgewählte Framework kann aber potenziell gar nicht für die tatsächlichen EAM-Ziele des Unternehmens geeignet sein, weil es dafür gar keine angemessenen Mittel zur Verfügung stellt. So könnte z. B. in einem Fusionsprojekt ein Ziel sein, die einheitliche Mandantenfähigkeit aller strategischen Anwendungen sicherzustellen, wobei diese überall auf die gleiche Weise implementiert sein sollte. Sieht das ausgewählte Framework nun keine Möglichkeit vor, dies vernünftig darzustellen und zu bewerten, wird man dieses Ziel auch nicht angemessen erreichen können. Das ist zum Zeitpunkt der Entscheidung für ein Framework in der Regel gar nicht klar identifizierbar und wenn es ans Tailoring geht, ist es zu spät. Dann ist das Framework „gesetzt”. Außerdem ist es auch dann noch immer nicht leicht zu erkennen, ob die Unternehmensziele mit dem Framework umgesetzt werden können.

Grundwerte der Agilität

Die gleichen Probleme gelten auch für EAM-Werkzeuge, die am Markt angeboten werden. Alternativ zur Auswahl eines Frameworks werden EAM-Einführungen auch gerne mit der Auswahl eines Produkts begonnen, das letztlich aber auch nur wieder ein Framework implementiert, sei es ein eigenes, proprietäres oder eines der oben zitierten.

Was ist das häufig anzutreffende Resultat? Mit viel Geld und Aufwand ist ein EAM im Unternehmen eingeführt worden, basierend auf einem Framework oder Produkt. Es wurden viele Daten erfasst und Sichten erstellt – meistens viel mehr, als man eigentlich benötigt. Kaum jemand weiß etwas mit den Daten und Sichten anzufangen außer dem EAM-Team, das stets die Wichtigkeit der Sichten betont. Inwiefern das EAM seine Ziele erfüllt hat, lässt sich nicht mehr oder nur schwer nachvollziehen, wohl aber das Geld, das die Einführung und Pflege verschlungen hat. Nur an einer Stelle hat die EAM Einführung zu einer signifikanten Steigerung der Kreativität geführt, nämlich in den IT-Projekten und Abteilungen bei dem Finden von Gründen, warum man leider gerade keine Zeit hat, die ganzen EAM Daten und -Sichten zu pflegen.

So gesehen in diversen Unternehmen …, natürlich gibt das fast niemand offiziell zu – wer tut das schon, insbesondere bei hohen EAM-Kosten? Es wird der eine oder andere Scheinerfolg gefeiert und das EAMTeam schreibt einige nette Artikel oder hält Vorträge auf Konferenzen. Aber in der Praxis schläft das EAM langsam ein, weil es nur wenige wirklich nutzen. Zurück bleiben ein bitterer Nachgeschmack und eine Menge verschwendetes Geld und Ressourcen.

Werte von Agilität

„So weit, so gut, aber wie soll mir hier Agilität helfen?“, mag der ein oder andere jetzt fragen. Die Frage ist durchaus berechtigt, wenn man sich nur das oft zitierte „agile Manifest” ansieht [Man]. Dort sind Richtlinien für die agile Softwareentwicklung dargestellt, die im Kontext von EAM nicht weiterhelfen. Um Agilität auf das Thema EAM-Einführung anwenden zu können, muss man die Grundwerte betrachten, die hinter dem agilen Manifest stehen. Betrachtet man die verschiedenen agilen Methoden und Prinzipien näher, lassen sich vier Grundwerte identifizieren, auf die sich Agilität zurückführen lässt (siehe auch Abbildung 2):

  • Zielorientierung – Es steht immer das Ziel bzw. das gewünschte Ergebnis im Fokus, keine Prozesse oder Methoden. Alle Maßnahmen sind konsequent gegen das zu erreichende Ziel abzugleichen. Es wird nichts gemacht, weil es etwa so im Prozess beschrieben ist, sondern nur, wenn es zielorientiert ist. Man ist nicht fertig, wenn man das vorgeschriebene Prozessartefakt erzeugt hat, sondern wenn das Ziel erreicht ist und jede Aktivität muss einen dem Ziel näher bringen.
  • Wertorientierung – Dieser Wert ist eng mit der Zielorientierung verbunden. Für Agilität ist es sehr wichtig, Mehrwert im Sinne von Geschäftswert zu produzieren. Nur was Mehrwert erzeugt, ist es auch wert, getan zu werden. Dabei geht es darum, den Mehrwert ganzheitlich zu betrachten und z. B. nicht nur (obwohl durchaus hilfreich und wichtig) auf Basis eher kurzfristiger monetärer ROI-Berechnungen. Alle beteiligten Stakeholder müssen vom Mehrwert des Zieles und den dafür notwendigen Maßnahmen überzeugt sein.
  • Risikomanagement – Die meisten der populären agilen Praktiken sind letztlich Arten von Risikomanagement. Agilität wird häufig in Bereichen mit hoher Unsicherheit und/oder hoher Dynamik eingesetzt. Dort kann man am Anfang oft noch nicht sagen, wie das finale Ergebnis aussehen wird (auch wenn das Ziel klar ist!). Klassische Vorgehensmodelle versagen häufig, weil sie von falschen Voraussetzungen bzgl. Wissensstand der Beteiligten und Stabilität der Anforderungen ausgehen. Agilität akzeptiert die Unsicherheiten und die Dynamik und reagiert darauf, wie es jeder gute Projektleiter tun würde: Mit viel Transparenz und einem der Situation angemessenen Risikomanagement. Das tägliche Standup-Meeting in Scrum, die kurzen Iterationen in fast allen agilen Methoden, das Pair-Programming in XP, der Burndown Chart in Scrum, usw.: Das sind letztlich nichts anderes als Instrumente, um Risiken zu minimieren bzw. zumindest schnell transparent zu machen.
  • Denken! – Das ist der eigentliche Kernwert der Agilität, auch wenn er nirgendwo explizit aufgeschrieben steht. Agilität verpflichtet jeden Teilnehmer, sein Hirn ständig zu nutzen und sich nicht auf Vorgefertigtes zu verlassen. Praktisch alle agilen Methoden geben nur einen groben Handlungsrahmen mit vielen Lücken vor. Das sind die Stellen, an denen der gesunde Menschenverstand gefordert ist, mit dessen Hilfe angemessene Entscheidungen getroffen werden müssen. Es gibt keine bis ins letzte Detail ausformulierten Prozesse, die den Beteiligten alle Eigenverantwortung abnehmen, hinter denen sie sich bequem verstecken können. Diese Verpflichtung zum Denken, zum Treffen angemessener Entscheidungen ist auch der Teil, der Agilität letztlich so schwierig macht.

Schaut man sich die verschiedenen agilen Methoden und Prinzipien an, findet man vielleicht noch den einen oder anderen zusätzlichen Aspekt. Letzten Endes lässt sich aber alles Wichtige auf die vier Grundwerte zurückführen.

Konsequenzen für die EAM-Einführung

Nimmt man die Grundwerte der Agilität und hält sie gegen die angestrebte EAM-Einführung, so kommt man zu einem anderen Vorgehen. Die Ziele, die das Unternehmen mit einer EAM-Einführung verbindet, stehen konsequent im Vordergrund. Oft kennt das EAM-Team diese Ziele am Anfang noch gar nicht. Denn obwohl sich diese Ziele aus den Geschäftszielen ableiten sollen, kann man das oft nicht, weil die Geschäftsziele z. B. nicht vorhanden bzw. dokumentiert sind oder sie sich so häufig ändern, dass man nicht weiß, welche nun die „richtigen“ sind. In diesen Fällen ist es die Team- Aufgabe, Ziele einzufordern und keine Ruhe zu geben, bis man sich auf die Ziele geeinigt hat. „Einfordern” bedeutet übrigens nicht, dass man nicht selber einen Vorschlag entwerfen und zur Abstimmung anbieten darf. Wichtig ist nur, dass am Ende eine gemeinsame Zielvorstellung bei allen beteiligten Stakeholdern etabliert ist – man bleibt fokussiert!

Zusätzlich sind Ziele und Maßnahmen gegen den resultierenden Geschäftswert zu prüfen. Findet man keinen Mehrwert hinter dem Ziel oder der Maßnahme, ist das ein Indikator dafür, dass man noch einmal gründlich prüfen sollte, ob das Ziel überhaupt einen Sinn macht bzw. die Maßnahme wirklich benötigt wird. Dieses Hinterfragen führt oftmals zu wesentlich besseren Zielen und hilft dabei, nicht benötigte Maßnahmen zu finden und zu beseitigen – das spart nicht nur Kosten, sondern auch Nerven!

Das Risikomanagement führt schnell zu der Erkenntnis, dass eine EAM-Einführung mit vielen Unsicherheiten verbunden ist und man in der Regel erst hinterher weiß, wie man es hätte machen sollen. Entsprechend fängt man möglichst klein an, produziert möglichst schnell Ergebnisse, lernt aus den Reaktionen auf das Geschaffene und verbessert sich über viele schnelle Iterationen. So kann man sich etwa zu Beginn nur auf eine einzige Fragestellung beschränken, die man mit dem EAM beantworten will – damit schafft man Erfolgserlebnisse und Akzeptanz!

Greifen wir das oben erwähnte Beispiel aus der Praxis wieder auf: In vielen Unternehmen ist die Mandantenfähigkeit der Systeme ein wichtiges Thema. Allerdings ist häufig nicht klar, welche Systeme überhaupt mandantenfähig sind und ob überall ein gleiches Verständnis von Mandantenfähigkeit implementiert ist. So kann man eine Anwendungslandkarte mit den bestehenden Systemen erstellen, die strategisch wichtigen Systeme darin identifizieren und erheben, ob und wie diese Systeme Mandantenfähigkeit implementieren. Gegen dieses Ist-Bild stellt man ein Soll-Bild mit dem gewünschten Zielzustand und leitet entsprechende Maßnahmen ab, die dann Einzug in die Projektportfolio-Planung halten. All das lässt sich in sehr kurzer Zeit bewerkstelligen, man produziert schnell einen Mehrwert für das Unternehmen (Stichwort: „Quick-Win”) und kann die Erfahrungen nutzen, um die nächsten Aktivitäten zu verbessern. Nebenbei hat man auch schon eine erste Datenbasis für das EAM geschaffen.

Frameworks und Werkzeuge im agilen Ansatz

„Und wo bleiben die Frameworks und Werkzeuge? Sind die jetzt komplett nutzlos geworden?“ Nein, natürlich nicht, aber sie sortieren sich an die richtige Stelle im Ablauf ein. Aus unserer Erfahrung ist es sehr hilfreich, sich frühzeitig Frameworks anzusehen, nicht um sie einzuführen, sondern im Sinne eines Werkzeugkastens. Sie bieten gute Musterlösungen für viele Aufgabenstellungen und als Unternehmensarchitekt bin ich gut beraten, diese zu kennen, damit ich nicht für jede Standardaufgabe das Rad neu erfinden muss (wäre ja auch ein Widerspruch zur Ziel- und Wertorientierung der Agilität). Ziele und Maßnahmen stehen im Fokus des Handelns und nicht das Framework. Bietet das Framework gute Vorschläge für die anstehende Aufgabe, was oft der Fall sein wird, sollte man diese nutzen – und wenn nicht, dann muss man gemäß der Ziele weitersuchen bzw. selber denken, halt agil … ;-).

Werkzeuge sind dann nützlich, wenn sie helfen, die erfassten Daten effizient zu pflegen, Redundanzen und Widersprüche zwischen verschiedenen Darstellungen zu vermeiden und mit wenig Aufwand neue Darstellungen und Auswertungen zu erzeugen. Man kann EAM zwar problemlos mit Excel, Visio und Powerpoint beginnen, doch auf Dauer wird das keinen Spaß machen und auch eine Menge Probleme bereiten. Bei EAM-Werkzeugen gilt aber auch, dass man erst wirklich verstehen sollte, was man eigentlich tun will bzw. muss, bevor man sich Gedanken über ein Werkzeug macht, das dann – richtig eingesetzt – die Arbeit tatsächlich erleichtern wird. In der Praxis sollte man üblicherweise die ersten zwei bis drei EAMIterationen hinter sich gebracht haben, bevor man sich um die Anschaffung eines Produktes kümmert.

Fazit

EAM ist ein wichtiges Thema, daran besteht heute kein Zweifel mehr. Nur bei der Einführung und Umsetzung hapert es häufig noch. Getrieben durch verfügbare Frameworks und Werkzeuge verlieren EAM-Einführungen immer wieder die daran geknüpften Unternehmensziele aus den Augen und entwickeln sich zu Sklaven der Frameworks und Werkzeuge, ohne wichtigen Geschäftswert zu erzeugen. Durch die Anwendung der agilen Grundwerte Zielorientierung, Wertorientierung, Risikomanagement und Denken kann man sicherstellen, dass die EAM-Einführung immer an den Zielen des Unternehmens ausgerichtet bleibt, stets den Geschäftswert aller Maßnahmen sowie das mit der Einführung verbundene Risiko im Auge behält und versucht, immer angemessene Lösungen für die gestellten Aufgaben zu finden.

Zusätzlich unterstützt die Ausrichtung der EAM-Initiativen an den agilen Grundwerten kleinere Unternehmen bei der Einführung eines EAM, die bislang von den großen, vorherrschenden Frameworks abgeschreckt worden sind. Durch die agile Ausrichtung an den individuellen Zielen und Wertvorstellungen können sie bei der EAM-Einführung sicherstellen, dass genau das getan wird, was das Unternehmen benötigt, und genau in der Art und dem Umfang, um einen optimalen Mehrwert zu erzeugen.
Die Anwendung der agilen Werte scheint zunächst keine große Veränderung gegenüber dem „normalen” Vorgehen zu bewirken. Doch es ist genau diese klein erscheinende Änderung des Blickwinkels, die aus unserer Erfahrung den Unterschied zwischen Erfolg und Misserfolg ausmacht. Deshalb können wir auch nur empfehlen, eine EAM-Einführung agil zu gestalten. Und wenn man sich einmal nicht sicher ist, wie man am besten weitermachen sollte, dann einfach an den vierten agilen Grundwert halten: Denken … am besten pragmatisch und mit einer guten Portion gesundem Menschenverstand. Das hilft in der Regel besser als jedes noch so große Framework oder Werkzeug.

Referenzen

[EAF] Enterprise Architecture framework in Wikipedia, siehe http://en.wikipedia.org/wiki/Enterprise_Architecture_framework
[Man] Manifesto for Agile Software Development, siehe http://www.agilemanifesto.org/
[Zac87] John A. Zachman: A framework for information systems architecture, IBM Systems Journal, Vol. 26, No. 3, 1987.
[Zac08] John A. Zachman: Introduction to the Zachman Framework, Enterprise Architecture Conference London, 2008.

Zurück zu den Publikationen

Vollständiger Artikel