Mittlerweile haben die meisten größeren Unternehmen erkannt, dass bei der Planung von IT-Landschaften der "Blick auf das Ganze" immer wichtiger wird. Dieser Artikel erklärt, was dahinter steckt und warum das Management von IT-Unternehmensarchitekturen mehr und mehr zur "Königsdisziplin" der IT wird.

EAM als Kernkompetenz

Abb. 1: Terminologie in IT-Unternehmensarchitekturen. Vergrößern

Abb. 2: Architekturpyramide. Vergrößern

Abb. 3: Prozesse für das Management von IT-Unternehmensarchitekturen. Vergrößern

Abb. 4: IT-Anwendungsportfolio-Management in der Planung. Vergrößern

Eine der zentralen Aufgaben im IT-Management besteht darin, eine strategische Planung der IT-Architekturen für das gesamte Unternehmen vorzunehmen.

Die Entwicklung, Auswahl und das Management solcher IT-Unternehmensarchitekturen wird unter dem Begriff Enterprise Architecture Management (EAM) zusammengefasst. Im Rahmen der IT beschreibt die Unternehmensarchitektur das Zusammenspiel von IT-Komponenten und der geschäftlichen Tätigkeit im Unternehmen. Unternehmensarchitekturen gewinnen zunehmend an Bedeutung, da sie das zentrale Bindeglied zwischen der geschäftlichen Sicht und der IT-Sicht eines Unternehmens bilden. Dieses Bindeglied stellt gleichzeitig aber auch eine der größten Herausforderungen in der heutigen IT-Welt dar.

Was kommt auf uns zu?

Es müssen sowohl technologische Entwicklungen, vorgegebene Geschäftsprozesse als auch Reduzierung der Komplexität der Architektur-Landschaften in Einklang gebracht werden. Häufig sind Unternehmensleitungen und auch klassische IT-Leitungen aufgrund der Anforderungen und der Fülle an möglichen Vorgehensweisen und Lösungen überfordert.

In den Unternehmen werden mittlerweile spezielle Teams für die IT-Unternehmensarchitektur gebildet. Zu den typischen Fragestellungen, mit denen sich die IT-Unternehmensarchitekten befassen müssen, zählen u. a.:

• Was ist die optimale IT-Unterstützung für die Geschäftsstrategie eines Unternehmens?
• Wie wird ein Portfolio von mehreren großen IT-Systemen verwaltet?
• Wie wird sichergestellt, dass die Komplexität der Unternehmens-IT nicht weiter anwächst?
• Wie sorgt man für technologische Innovationen in älteren Anwendungen?

Die Fragestellungen, verdeutlichen dass klassische Softwarearchitekturen sie nicht alleine beantworten können, da sie sich mit dem Aufbau einzelner Softwaresysteme befassen. Im Gegensatz dazu befasst sich die IT-Unternehmensarchitektur mit den Komponenten und deren Beziehungen untereinander. Hierbei steht allerdings nicht nur der technische Aspekt, sondern vielmehr der Bezug zu betriebswirtschaftlichen Anforderungen im Vordergrund.

Mit Überblick auf das Wesentliche

In Anlehnung an die urprüngliche Bedeutung des Begriffs Architektur, kann man die Unternehmsarchitektur mit einem Bebauungsplan vergleichen. Auch hier betrachtet man nicht nur isoliert die Architektur einzelner Gebäude, sondern balanciert die Interessen aller Beteiligten aus.

Dabei ist der Kunde nicht der Einzige, der dem Architekten Vorgaben macht. Es sind aktuelle Vorschriften, Bebauungsziele, Kostenrahmen, bereits vorhandene Altbauten und auch der neueste Stand der Technik zu berücksichtigen. In dieser Analogie kamen mit Einführung der IT-Unternehmensarchitektur ebenso neue Begriffe wie IT-Anwendungsportfolio-Management, IT-Governance, IT-Strategie und IT-Business-Alignment hinzu. Diese Begriffswelt rund um EAM wurde aus der Zusammenarbeit der Gartner Group mit dem MIT Sloan Center for Information Systems Research entwickelt. Abbildung 1 verdeutlicht den Zusammenhang der einzelnen Begriffe.

In der Praxis hat sich bewährt, bei der Planung und Behandlung der Bereiche von der Strategie ausgehend zu den Einzelsystemen vorzugehen. Auf diese Weise können die Unternehmensziele wesentlich besser abgebildet werden. Zunächst werden die Fragen geklärt, die sich näher auf das Geschäft beziehen, um dann anschließend alle Aspekte zu betrachten, die die technischen Voraussetzungen hierfür schaffen. Um zu verdeutlichen, dass sich alles aus der Business- und IT-Strategie ableitet, stellt man diese Zusammenhänge auch in Form einer Pyramide dar.

Die Architekturpyramide in Abbildung 2 bildet die Hierarchie der unterschiedlichen Architekturen in idealer Weise ab. Die Schichten der Pyramide werden im Folgenden erklärt:

Strategie ist einfach alles

Damit der IT-Unternehmensarchitekt die IT-Funktionen auf die Bedürfnisse des Geschäfts ausrichten kann, braucht er Zugriff auf die Geschäftsstrategien (Business Strategy), die von der Leitung des Unternehmens vorgegeben werden muss.

Ziel ist es, aus der Geschäftsstrategie eine IT-Strategie abzuleiten. Zu den Inhalten einer IT-Strategie gehören u. a. Aspekte zur geografischen Ausdehnung der IT-Funktion, IT-Governance-Modell, Umgang mit Legacy-Anwendungen, Virtualisierung durch Outsourcing und Budget der IT-Funktion.

Geschäftsarchitektur - unser Was und Wie

Die Geschäftsarchitektur (Business Architecture) ist ein Modell, das in der Summe alle beschriebenen Geschäftsprozesse eines Unternehmens definiert. In der Praxis findet man neben der Geschäftsarchitektur häufig noch Geschäftsmodelle (Business Models), die beschreiben, wie ein Geschäft funktionieren soll.

Fach- und Informationsarchitektur - der Generalbebauungsplan

Mit der Facharchitektur wird den Entwicklern ein fachliches Referenzmodell zur Verfügung gestellt, das die komplette Fachlichkeit einer Branche beschreibt. Die Beschreibungen beinhalten dabei keine Details zur technischen Implementierung. Neben einem fachlichen Generalbebauungsplan werden die wichtigsten fachlichen Dienstleistungen (Services) der Systeme und deren Schnittstellenvereinbarungen untereinander dokumentiert.

Anwendungsarchitekturen - moderne Technikplanung

Die Anwendungsarchitekturen beschreiben, mit welchen Arten von technischen Komponenten ein Softwaresystem aufgebaut wird. Dabei wird häufig auf die klassischen Drei-Schichten-Architekturen mit Middle-Tiers zurückgegriffen. In umfangreichen Dokumenten wird festgelegt, welche Frameworks, welche Module und Objekttypen in welcher Schicht realisiert werden. Da für komplexe Systeme oder Netze von Komponenten die Drei-Schichten-Architekturen oft nicht ausreichen, werden für die Dokumentation von Web-Architekturen Blueprints eingesetzt. Mit ihnen können durch einen höheren Detaillierungsgrad die Zusammenhänge zwischen Content Management Systems, Enterprise Information Systems, Business Process Management und Enterprise Service Bus besser verdeutlicht werden.

System- und Infrastrukturarchitektur - unser "Maschinenraum"

Nachdem die Anwendungsarchitekten festgelegt haben, in welche technische Schichten ein Softwaresystem aufgegliedert ist, wird mit der Systemarchitektur dokumentiert, auf welchen Plattformen diese implementiert werden.

Wichtige Kriterien hierfür sind Hochverfügbarkeit, Skalierbarkeit und die Leitfrage, was bereitgestellt werden muss, um alle Systeme unter Einhaltung der Service Level Agreements (SLAs) laufen zu lassen. Darüber hinaus sollte der IT-Unternehmensarchitekt neben betriebswirtschaftlichen Aspekten, wie Wartungs- und Betriebskosten, auch Ziele zur Verringerung der Komplexität von Gesamtinstallationen im Auge behalten.

Benefit fürs Business

Aus Sicht der Unternehmensleitung stellt sich immer wieder die Frage nach der Notwendigkeit einer solchen Hierarchie (siehe Abbildung 2). Wenn die Unternehmensleitung durch den Einsatz Ihrer IT die Wettbewerbsposition positiv beeinflussen will, ist der o. g. Ansatz unabdingbar.

Im Top-Management wird mittlerweile erkannt, dass die IT der Motor für neue Entwicklungen und ein zentraler Erfolgsfaktor für das eigentliche Geschäft sein kann. Voraussetzungen dafür ist, dass die IT-Funktion strategisch an den Bedürfnissen der Geschäftsfunktion ausgerichtet wird. Ein solches Business Alignment kann durch die Einführung der oberen Pyramidenspitzen mit einer passenden IT-Governance langfristig sichergestellt werden.

Wo fängt man an und wie geht's weiter?

Mit Hilfe der Architekturpyramide kann ein IT-Unternehmensarchitekt beginnen, die Systemlandschaft des Unternehmens zu modellieren. Doch wie geht man dabei konkret vor? Die vorliegenden Modelle können sowohl zur Darstellung des aktuellen Zustands (IST-Architektur) als auch eines zukünftigen Zustands (SOLL-Architektur) genutzt werden. Die Weiterentwicklung der Unternehmensarchitektur wird über einen Kreislauf aus IST zum SOLL abgebildet. Abbildung 3 zeigt die wesentlichen Prozesse der IT-Unternehmensarchitektur.

Ausgangspunkt ist die Beschreibung der Geschäfts- und IT-Strategie, aus der die Beschreibung der SOLL-Architektur abgeleitet wird. Sobald sich die IT-Strategie verändert, ist immer ein erneuter Durchlauf zur Aktualisierung der Unternehmensarchitektur erforderlich. Für die Umsetzung der Planung stehen anschließend die Aktivitäten Monitoring und Projektbegleitung im Vordergrund. Begleitet werden diese Aktivitäten durch die Hilfsprozesse Modellierung und der Entwicklung von Richtlinien aus der unteren Hälfte in Abbildung 3.

Insbesondere bei der Modellierung orientiert man sich gerne an bereits vorhandenen EA-Frameworks für die IT-Unternehmensarchitektur. In der Fachliteratur werden mittlerweile bis zu 20 EA-Frameworks dokumentiert, von denen laut einer Umfrage des Institute for Enterprise Architecture Developments hauptsächlich das Zachman Framework und TOGAF (The Open Group Architecture Framework) genutzt werden.

Abbildung 4 stellt die Aktivitäten des IT-Anwendungsportfolio-Managements etwas detaillierter dar. Bereits in der Planungsphase wird mit Hilfe der vorliegenden IT-Strategie die SOLL-Architektur aus dem Anwendungsportfolio der IST-Architektur kontinuierlich weiterentwickelt.

Erste Ergebnisse

Die Ergebnisse von IT-Anwendungsportfolio-Analysen werden in der Praxis häufig mit Softwarekarten in Form kombinierter Cluster-, Prozessunterstützungs-, Intervall-Karten oder Architekturbeschreibungen nach IEEE 1471 dokumentiert. Sie bilden die Basis, um daraus unter Berücksichtigung der IT-Strategie das SOLL-Portfolio zu erstellen. Doch wie stellt man sicher, dass sich das Portfolio in die richtige Richtung entwickeln wird?

Die Antwort liegt in einer notwendigen Dokumentation von Projektplanungen, aus der ersichtlich wird, welche Projekte wann und mit welchen Budgets Änderungen am Portfolio herbeiführen sollen. Nur so wird deutlich, welche zukünftigen Planungen mit welcher Priorität durchgeführt werden müssen. Das Ganze ist ein kontinuierlicher Planungsprozess, der in jährlichen Intervallen durchgeführt wird und uns vor Augen hält, dass immer nur Zwischen- aber nie finale Endzustände erreicht werden. Im Anschluss daran gibt es weitere Planungen und weitere Umbauten.

Man kann sehr leicht nachvollziehen, dass die Durchführung ohne ein begleitendes Monitoring und ohne eine kontinuierliche Projektbegleitung wenig Sinn macht. Diese Aufgaben sollten organisatorisch von einem eigenständigen Gremium (IT-Architekturboard) durchgeführt werden, um rechtzeitig zu erkennen, welche Projekte sich "architekturverändernd" im Unternehmen auswirken könnten.

Teufelskreis

Um gute Ergebnisse zu erzielen, sollte man unbedingt das Ganze im Blick halten. Die Komplexität der Anwendungslandschaft steigt mit jeder Einführung eines neuen Systems. Dies hat häufig sehr aufwändige Integrationsprojekte zur Folge. Das führt wiederum dazu, dass die Komplexität des Gesamtsystems noch weiter zunimmt - ein Teufelskreis. Da in der Regel das Tagesgeschäft im Vordergrund steht, werden übergreifende Architekturaufgaben vernachlässigt und der Teufelskreis sorgt für hohen Zeitdruck und weiter steigende Komplexität.

Gerade hier zeigt sich, wie wichtig es ist, eine ausgewogene Balance zwischen strategischen und operativen Aktivitäten zu finden.

EAM gleich Kommunikation

Das Management von IT-Unternehmensarchitekturen erfordert vor allem eine Bereitschaft zur intensiven Kommunikation mit allen Beteiligten. Dabei geht es nicht nur um den Austausch fachlicher und technologischer Informationen, sondern vielmehr um die Rückverfolgung von Zuständen aus einer Vielzahl von Kommunikationskanälen.

Dazu gehören Zustände der Anwendungs- und Geschäftsprozess-Landkarten mit den zugehörigen Schnittstellenlisten, Richtlinien, Migrationsplanungen, SOA-Schnittstellen, Compliance-Themen, APM-Repositories und architektonische Informationen aus den IT-Projektteams. Man kann sich leicht vorstellen, dass die Bearbeitung aller Themen nicht in einer einzigen Gesprächsrunde erledigt sein wird.

In vielen periodisch stattfindenden Gesprächen werden Reviews phasenbezogener Ergebnisse durchgeführt und dabei überprüft, ob Ziele und Schnittstellen noch aktuell sind. Wie erfolgreich ist die Zusammenarbeit mit allen beteiligten Teams? Effizient durchgeführte Architektur-Reviews helfen, die Arbeitsergebnisse schrittweise weiter zu verbessern.

Was kommt unterm Strich heraus?

Zu den wichtigsten Ergebnissen eines guten EAM zählt neben der Darstellung der Unternehmensarchitektur in geeigneten Modellen auch die Dokumentation der Richtlinien, die die Grundzüge der Architektur bestimmen. Dabei beschäftigen sich diese Richtlinien nicht mit konkreten Technologien oder einzelnen Anwendungen.

Oberste Prämisse im EAM ist immer ein möglichst umfassendes Business-IT-Alignment. Nur so kann sichergestellt werden, dass durch gut dargestellte Architekturen mit all ihren Zusammenhängen die Komplexität moderner IT-Landschaften beherrschbar wird bzw. bleibt.

Fazit

Das Management von IT-Unternehmensarchitekturen spielt inzwischen eine Schlüsselrolle in größeren Unternehmen. Von der Unternehmensleitung sollte die IT als wichtiges Management-Instrument begriffen werden - nicht nur, um Kosten zu sparen, sondern auch, um die Kunden besser bedienen zu können. Dabei ist nicht die Entwicklung rein technischer Architekturen ausschlaggebend. Es ist vielmehr wichtig, Unternehmensarchitekturen strategisch an den Geschäftsvorgaben auszurichten.

Letztlich hängt vieles davon ab, ob auch die Leitung das Thema Enterprise Architecture Management unterstützt. Wird es von dort mit einem weitsichtigen Blick auf das Ganze vorangetrieben, so wird die IT zum aktiven Werkzeug und ihre Architektur bringt mehr ein, als sie kostet.

Matthias Heinl (info@coniatos.com).