Das Konzept einer Enterprise Architecture ist nicht neu. Bereits in den 80er Jahren wurden die grundlegenden Ideen unter anderem von John Zachman beschrieben. Heute erhält die Idee jedoch im Zusammenhang mit Business-Process-Management und Service-orientierten Architekturen (SOA) neue Bedeutung.

Grundsätzlich unterscheiden wir drei EAM-Haupteinsatzgebiete, die einzeln oder in Kombination berücksichtigt werden können. Der erste ist die Dokumentation und Analyse einer gegenwärtigen oder zukünftigen (IT-)Unternehmensstruktur. Dabei handelt es sich um konzeptionelle, entwerfende Tätigkeiten, die im Zusammenhang mit EAM am häufigsten genannt werden. Der zweite Bereich ist das Projektportfolio-Management, welches ebenfalls im Zusammenhang mit EAM diskutiert wird, jedoch mehr planend und verwaltend arbeitet. Schließlich kann man noch das Management einer vorhandenen IT-Infrastruktur, unter anderem im Bereich des Konfigurations-Managements, als operativ beziehungsweise steuernd zum EAM zählen. Für alle drei Bereiche gibt es Hersteller, die ihre Produkte als Enterprise-Architecture-Suite kennzeichnen. Bevor man jedoch Tools auswählt und implementiert, sollte man wissen, was auf einen zukommt.

Das Metamodell

Jedes EAM basiert auf dem Erfassen, Verknüpfen, der Pflege und Auswertung von Informationen, meistens bezogen auf die IT. Ein Modell hilft bei der Kommunikation dieser Informationen. Der Ursprung des Begriffs Modell liegt im italienischen "modello" und bedeutet frei gesprochen in den Naturwissenschaften ein "Abbild der Natur". Wir verstehen in unserem Fall unter einem Modell ein Abbild der realen IT-Welt. Grundlage zum Aufbau eines solchen Modells ist immer ein Metamodell. Hinter dem abstrakt klingenden Begriff steckt eigentlich nichts anderes als die Vorschrift, nach der ein Modell zu entwerfen ist. Es ist damit einfach ausgedrückt die "Bauanleitung" für das zukünftige Modell.

Unabhängig davon, in welchem der genannten drei Bereiche man den Schwerpunkt seiner Enterprise Architecture plant, ist es entscheidend für den Erfolg, dass die Informationsmenge beherrschbar bleibt. Die Größe, mit der sich die Beherrschbarkeit einer EA bestimmen lässt, ist der zu erwartende Pflegeaufwand. Um diesen schnell abschätzen zu können, wird das Metamodell benötigt.

Um eine EA zu überprüfen, bevor Zeit und Geld in den Aufbau investiert werden, gibt es eine wirkungsvolle Methode. Sie dient dem schnellen und einfachen Entwurf einer ersten EA-Metamodellstruktur und der exakten Ermittlung des voraussichtlichen Pflegeaufwands. Selbstverständlich lässt sich auf diesem Weg auch die Überlebensfähigkeit eines bestehenden EAM kontrollieren.

Vier Hauptsichten auf die Architektur

Es ist erstaunlich, wie viele Unternehmen ein EAM implementieren, ohne vorher über das Metamodell nachzudenken. Diese Projekte scheitern häufig, weil sich in ihrem Verlauf herausstellt, dass man nicht in der Lage ist, den Pflegeanforderungen gerecht zu werden. Um diesen Fehler zu vermeiden, müssen Sie vor dem eigentlichen Projekt festlegen, wobei ihnen die EA helfen soll. Dazu ist es sinnvoll, zunächst die Hauptarchitektursichten zu betrachten und ein grobes Metamodell zur Aufwandsabschätzung zu entwickeln. Unterscheiden Sie zwischen der Business-, Application-, Information- und Infrastructure-Achitecture. Zu jeder Sicht formulieren Sie Grundsätze, die zur Gestaltung der EA herangezogen werden. Sie beschreiben übergeordnete Ziele, deren Erfüllung die EAM unterstützen soll (siehe Tabelle unten "Architektursichten und ihre Ziele").

Alle Grundsätze müssen neutral formuliert sein und dürfen keine konkreten methodischen, technologischen und organisatorischen Ausprägungen enthalten. Zum Beispiel wäre der Grundsatz "Anwendungsentwicklung grundsätzlich mit Java" nicht zulässig. Neutral formuliert, muss es heißen: "Die Anwendungsentwicklung soll technologische Unternehmensstandards einhalten."

Architektursichten und ihre Ziele

EAM-Sicht	Grundsätze
Geschäftsarchitektur	Sicherstellung eines kontinuierlichen Geschäftsbetriebs; Erfüllung und Einhaltung gesetzlicher Vorschriften; klare Zuweisung fachlicher Verantwortlichkeiten; klare Zuweisung technischer Verantwortlichkeiten; übergreifende Nutzung von Anwendungssoftware in verschiedenen Unternehmensbereichen.
Anwendungsarchitektur	Sicherstellung technischer Unabhängigkeit; Durchsetzung von Standardapplikationen; Gewährleistung einer guten Bedien- und Anwendbarkeit.
Informationsarchitektur	Unternehmensübergreifende Nutzung von Informationen; Sicherstellung des jederzeitigen Informationszugriffs; klare Zuordnung von Informationsverantwortlichen; Etablierung von Standards im Informations-Management; Sicherung der Informationen der Organisation gegen Verluste.
Infrastrukturarchitektur	Steuerung verwendeter Techniken; Sicherstellung von Interoperabilität.

Die Objekttypen des Metamodells

Nachdem die Grundsätze Ihres EAM definiert sind, ermitteln Sie die zugehörigen essenziellen Fragen, auf die die EA antworten soll. Sie drücken den Informationsbedarf der beteiligten Personen aus, die in die Erstellung, Nutzung und Wartung des EAM eingebunden sind, und müssen sich auf die Grundsätze beziehen. Die Fragen liefern das Fundament für den Entwurf Ihres individuellen Metamodells, der zentralen Komponente eines jeden EAM. Ein einfaches Beispiel für eine essenzielle Frage ist: "Welche Prozesse sind betroffen, wenn ein Anwendungssystem nicht mehr zur Verfügung steht?"

In dieser Frage sind die zwei Sichten Geschäfts- und Anwendungsarchitektur enthalten, repräsentiert durch die Objekttypen "Prozesse" und "Anwendungssysteme". Wiederholen Sie diesen Vorgang, bis alle wichtigen Fragen formuliert und daraus die für Sie wichtigen Objekttypen des Metamodells abgeleitet sind. Anschließend setzen Sie die Objekttypen zueinander in Beziehung und entwickeln auf diese Weise Ihr individuelles EA-Metamodell. Dazu ist es nicht erforderlich, ein syntaktisch korrektes Entity-Relationship-Diagramm (ER-Diagramm) des Metamodells zu erstellen. Eine einfache Skizzierung reicht vollkommen aus.

Und so rechnen Sie

Dann folgt der entscheidende Schritt. Ermitteln Sie, welchen Aufwand die Füllung und Pflege des EA-Metamodells verursachen wird. Auch wenn sich die genaue Zahl der erforderlichen Personentage in dieser frühen Phase meist nicht angeben lässt, so kann man doch mit Hilfe einer Näherung abschätzen, welche Größenordnungen zu erwarten sind. Dazu müssen Sie das zukünftige Volumen Ihres Modells annähernd bestimmen. Ermitteln Sie für jeden Objekttyp und jede Beziehung zwischen den Objekttypen die Zahl der zu modellierenden Instanzen. Schätzen Sie beispielsweise für den Objekttyp Anwendungssystem ab, wie viele Instanzen Sie in Ihrem Unternehmen erfassen müssen und wie viele Beziehungen diese zu Instanzen anderer Objekttypen aufweisen. Anschließend bestimmen Sie, welcher durchschnittliche Aufwand zur Ermittlung der Inhalte je Objekttyp und Beziehung erforderlich ist. In der Regel ist bei den meisten Instanzen eines Objekttyps mit annähernd gleichem Erfassungsaufwand zu rechnen, weshalb in erster Näherung von einer kleinen Varianz der Zeiten zur Informationsbeschaffung ausgegangen werden kann. Berechnen Sie dann den zu erwartenden Erstellungsaufwand Ihres EA-Modells (siehe Kasten unten "Rechenmethode").

Bewerten Sie abschließend das Ergebnis unter Berücksichtigung der Ihnen zur Verfügung stehenden Ressourcen. Erst wenn Sie sicher sind, dass Sie mit den bestehenden Kapazitäten Ihre individuellen EAM-Anforderungen abdecken können, sollten Sie mit dem weiteren Aufbau fortfahren. Natürlich müssen dann noch Themen wie die Werkzeugauswahl und die Governance bearbeitet werden. Dabei haben aber alle Beteiligten ein besseres Gefühl im Bauch. (ph)

Bei dem Beitrag handelt es sich um einen bearbeiteten Auszug aus dem Buch "Enterprise Architecture, BPM und SOA für Business-Analysten. Leitfaden für die Praxis" von Dirk Stähler, Ingo Meier, Rolf Scheuch, Christian Schmülling, Daniel Somssich, München 2009, Carl Hanser Verlag, 277 Seiten, 39,90 Euro.