Enterprise-Architecture-Management

EAM - ein Muss in Zeiten des Wandels

17.10.2012 von Kornelius Fuhrer
Das Herzstück einer Enterprise Architecture ist das Metamodell, in dem sich der Informationsbedarf aller Stakeholder niederschlägt. Es sollte passgenau und Tool-unabhängig konstruiert sein, um zu den erhofften Synergievorteilen zu führen.
Foto: fotolia.com/ArchMen

Enterprise Architecture Management (EAM) schafft eine gute Informationsgrundlage für die Planung und Gestaltung in Business und IT. Vielfältige Entscheidungsszenarien lassen sich nachvollziehbar simulieren und bewerten - und die oft komplexen Auswirkungen auf die Architektur im Detail beobachten. Unternehmen kommen so zu sicheren, konsistenten und nachhaltigen Entscheidungen. Die Mitarbeiter aus Management, Fachabteilungen, Entwicklung und Betrieb arbeiten effektiver und effizienter.

Lesen Sie auch Teil 2 unserer EAM-Reihe, der sich mit den Vorteilen einer agilen und adaptiven IT-Architektur beschäftigt.

Das Metamodell als Big Picture

Die Basis jeder Enterprise Architecture ist das Metamodell. Es bildet die relevanten Aspekte eines Unternehmens als Architekturelemente ab, zum Beispiel als Prozesse, Capabilities, Services oder Objekte. Dabei berücksichtigt es deren Wechselbeziehungen und -wirkungen. Außerdem legt das Metamodell diese Elemente in einem Architektur-Repository ab.

Szenario des EAM: Das Metamodell ist die Basis der Enterprise Architecture. Es bildet die relevanten Aspekte des Unternehmens als Architekturelemente ab.

Das strukturierte Speichern dieser Informationen schafft die Grundlage für On-demand-Abfragen und Ad-hoc-Analysen, mit deren Hilfe sich akute Problemstellungen nachvollziehen lassen. Ebenso werden Simulationen unterschiedlicher Geschäftsszenarien möglich und die zielgruppenspezifischen, praxiserprobten Architektursichten lassen sich anschließend visualisieren.

Die Praxis zeigt, dass Analysen zur Projektvorbereitung meist unerwartet lange dauern, weil das Team ihre Komplexität unterschätzt. Budgets für die Projektarbeit sind dann über viele Wochen unproduktiv gebunden. Erst die Ablage der teuer erworbenen Erkenntnisse in einem Architektur-Repository macht es möglich, dass diese für zukünftige Entscheidungen wieder herangezogen werden können.

Die schnelle Beantwortung von typischen Stakeholder-Fragestellungen mittels generierter Architektursichten aus einem Architektur-Repository beschleunigt das Analysieren und Bewerten von Anforderungen und deren Zuordnung zu Projektarbeitspaketen. Dabei gilt es, unter anderem die folgenden Fragen zu beantworten:

Unsicherheiten und Fragestellungen in Meetings lassen sich mithilfe dieser Fragen sichtbar machen und präzise beantworten. Vorbereitungs- und Abstimmungsprozesse können effizient gestaltet werden. Auf diese Weise wird nachvollziehbar, warum und unter welchen architektonischen Voraussetzungen bestimmte Entscheidungen getroffen wurden. Auf dieser Basis entscheiden die Verantwortlichen schneller, erfolgreicher und nachhaltiger.

Architektur mit oder ohne Transparenz

Jedes Unternehmen hat definitiv eine Architektur, die entweder implizit oder explizit vorhanden ist. Eine implizite Architektur, die den Stakeholdern nicht wirklich bewusst ist, macht Kontrolle, Kommunikation und strategische Weiterentwicklung schwierig. Gelingt es, die Architektur in unternehmensweit abgestimmte Strukturen aufzuteilen, entsteht Transparenz, was erheblich zum gegenseitigen Verständnis von Business und IT beiträgt.

Das Definieren und Bekanntmachen der Enterprise Architecture führt zu einem einheitlichen Vokabular im Unternehmen. Diese gemeinsame Sprache schafft eine wichtige Basis für die Kommunikation der Beteiligten in Management, Fachbereich und IT. Die gelungene Kommunikation wiederum ist das Fundament für ein erfolgreiches Business-IT-Alignment.

Eine abgestimmte Semantik und, darauf aufbauend, eine gemeinsame Sprache zwischen Fachbereich und IT ist auch die Grundlage für eine effektive IT-Investitionsplanung. Diese unternehmensweite sprachliche und semantische Governance vermindert das Risiko fachlicher und technischer Missverständnisse sowie zeitraubende Synchronisierungsphasen. IT-Entscheidungen werden verständlich und in ihren Auswirkungen auf die Architektur transparent.

Architekturdomänen als Struktur für die Enterprise Architecture.

Die Abbildung "Architekturdomänen als Struktur für die Enterprise Architecture" zeigt die verschiedenen Architekturdomänen und die ihnen zugeordneten Elemente. Nach dem Prinzip "Teile und Herrsche" findet hier eine Segmentierung der Interessen und Stakeholder-Gruppen statt.

Indem fachliche Elemente der Business-Architektur den Bestandteilen der Anwendungs- und Service-Architektur zugeordnet werden, lässt sich die IT-Unterstützung dokumentieren. Diese Dokumentation ist Voraussetzung für ein erfolgreiches Business-IT-Alignment. Für jede Business Capability, jeden Geschäftsprozess und jedes Produkt wird klar, welcher Aspekt inwieweit zur Gesamtunternehmensleistung beiträgt. Business-Ziele werden so mit IT-Strukturen in Verbindung gebracht und Korrelationen zwischen Business und IT werden transparent.

Auf dieser Grundlage können aus fachlichen Vorgaben und Zielen informationstechnische abgeleitet werden. Umgekehrt lassen sich Kennzahlen über diese Verbindung in einen Zusammenhang mit den Elementen der Business-Architektur und den strategischen Zielen bringen. Geschäftsrisiken, fachliche und technische Handlungsbedarfe sowie mögliche Maßnahmen für eine verbesserte IT-Unterstützung lassen sich identifizieren. Darüber hinaus können detaillierte Aussagen darüber getroffen werden, wie sich Business-Entscheidungen auf die IT-Architektur auswirken.

Die strategische Ausrichtung von Business und IT

Das Verzahnen der Prozesse im Enterprise Architecture Management hat deren strategisch gesteuerte Evolution zur Folge: Investitionen werden so verteilt, dass nur die richtigen Business Capabilities und Funktionen neu entstehen. Sie können bei gleichbleibender Effizienz und konstanten Kosten von der IT realisiert werden.

Die Abbildung "Prozesse des Enterprise Architecture Management" illustriert das Zusammenspiel der elementaren EAM-Prozesse, das folgendermaßen beschrieben werden kann:

Prozesse des Enterprise Architecture Management.

Die größten Zielkonflikte bestehen zwischen dem an Best Practices orientierten Projekt-Management und dem Architecture Management. Letzteres hat die Aufgabe die Projekte entlang des strategischen Evolutionskorridors in Richtung Zielarchitektur zu steuern. In der Praxis bewährte Governance-Institutionen wie das Project Review Board bewerten die erzielten Projektergebnisse hinsichtlich ihrer Architekturqualität und ihres Beitrags zum Erreichen der Zielarchitektur jeder Lebenszyklusphase.

In der Realität müssen Kompromisse möglich sein, damit Anforderungen, die gegen Architekturstandards verstoßen, aufgrund des Marktdrucks trotzdem umgesetzt werden können. Das Architecture Management darf solche Vorfälle nicht verhindern, hat aber die Aufgabe, derartige Architekturverletzungen schnellstmöglich wieder zu korrigieren.

Die definierten Standards und Prinzipien aus dem Strategy- und Value-Management werden mittels Governance über Rollen, Policies, Prozesse etc. weiter verfeinert und in den Projektmanagement-Prozess integriert. In der Praxis führen Governance-Verantwortliche frühzeitig und fortlaufend entlang des Projekt-Managements Reviews und Messungen durch, um die Standardkonformität in Projektergebnissen zu prüfen und nachzuhalten.

Um die Business- und IT-Ziele zu erreichen und eine Business-orientierte Gestaltung zu gewährleisten, werden projektspezifische Plan-Architekturen im Architecture Management immer wieder mit den Vorgaben zum Erreichen der Zielarchitektur (Soll-Zustand) abgeglichen. In der Praxis steigt dabei die Sicherheit in der Projektplanung, denn deren Planungskontext umfasst neben den Informationen der Ist-Architektur auch die der Plan-Architekturen aller Projekte. Business-Analysten und Projektleiter können Inkonsistenzen oder Kollisionen von Anforderungen paralleler Projekte schon zu einem sehr frühen Zeitpunkt identifizieren.

Erkennen die Analysten beispielsweise rechtzeitig, dass beim Vergleich der eigenen Plan-Architektur des fokussierten Projekts mit den Plan-Architekturen anderer Projekte eine Schnittstelle im nächsten Release durch ein spezifisches Projekt verändert oder vollständig abgelöst wird, dann können die zuständigen Mitarbeiter eine Anbindung an den Nachfolger gegebenenfalls zeitnah koordinieren. Kostenintensive und folgenschwere Fehler, die oftmals erst in der Produktion auffallen, können so frühzeitig erkannt und korrigiert werden.

Fazit

Das Metamodell ist das Herzstück einer Enterprise Architecture, in dem sich der essenzielle Informationsbedarf der Stakeholder vollständig abbildet. Um in frühen Phasen einer EA-Initiative von den Einschränkungen eines Werkzeugs frei zu sein, ist es wichtig, ein werkzeugneutrales Metamodell zu konstruieren. Nur mit einem passgenauen Metamodell lassen sich Synergien heben und die Chancen im Unternehmen umfassend nutzen.

Die Architekturelemente strukturiert zu erfassen und dabei ihre Wechselbeziehungen mit zu berücksichtigen, schafft Transparenz über die Architektur und bildet das Fundament für ein gemeinsames Verständnis und letztlich die strategische Planung. Durch die Zuordnung fachlicher Architekturelemente der Business -Architektur zu den Bestandteilen der IT-Architektur werden beide Domänen miteinander verknüpft. Der gegenseitige Austausch zwischen Business und IT wird so gewährleistet und forciert.

In diesem Kontext bedeutet Effektivität, dass nur die richtigen Projekte umgesetzt werden. Entsprechend ihrer Wettbewerbssituation sind Unternehmen mithilfe einer Enterprise Architecture in der Lage, Business-Ziele entlang des strategischen Projektportfolios zu operationalisieren. Effizienz hingegen bedeutet, dass die Projekte richtig umgesetzt werden. Hier greifen die Prozesse Demand-, Architektur- und Projekt-Management sowie die Governance von EAM nahtlos ineinander und stellen sicher, dass die Projektergebnisse den Anforderungen entsprechen und die Architekturstandards und -prinzipien zur Bewahrung der IT-Agilität eingehalten werden.