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.
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:

  • Welche Services hängen von welchen anderen ab? Welche Schnittstellen existieren? Welche Informationsobjekte werden über diese Schnittstellen ausgetauscht?

  • Welche Business Capabilities, welche Business-Prozesse und welche Produkte werden von welchen Services unterstützt? Welche Business-Einheiten nutzen welchen Service für welchen Business-Prozess oder welche Business-Funktion?

  • Welche IT-Maßnahmen unterstützen welche Business-Ziele? Wie sind sie architektonisch und parallel koordinierbar? Passen sie zur IT-Strategie? Werden Standards und gesetzliche Richtlinien eingehalten? Welche Risiken bestehen hinsichtlich Compliance, Sicherheit und Verfügbarkeit, und wie lassen sich diese in den geplanten Projekten minimieren?

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.
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.

Inhalt dieses Artikels