In der Vergangenheit sind - nicht zuletzt aufgrund unerwarteter Anforderungen - komplexe Applikationslandschaften entstanden, die immer schwerer zu warten sind. Dies betrifft nicht nur die einzelnen Applikationen, die als proprietäre Monolithen immer unhandlicher werden, sondern auch die Vielfalt der Verbindungen zwischen den einzelnen Systemen. Daher wird das Ziel verfolgt, standardisierte Schnittstellen für den Zugriff auf bestehende Funktionalität zu etablieren, die großen Applikationen aufzuspalten und die Verknüpfungen zwischen den Applikationen in einer kontrollierten Weise zu verwalten. Der letztgenannte Trend führt dabei zum Aufbau Service-orientierter Architekturen (SOA), bei denen die Services jeweils einen in sich geschlossenen Abschnitt der Geschäftsprozesse kapseln zu dem Zweck, Veränderungen in den Geschäftsprozessen in der IT leichter durch eine Neuverknüpfung der bestehenden Services miteinander abbilden zu können - so zumindest die Hoffnung.
SOA bietet Lösungen
In der Tat ist dieses Ziel leichter beschrieben als erreicht. Das Problem beginnt bei der Auswahl der in einem Service zu bündelnden Prozessschritte: Wie viele Prozessschritte umfasst ein Service? Welche "Schnitte" eines Geschäftsprozesses werden sich im Zeitablauf als richtig erweisen, und an welchen Stellen in den Geschäftsprozessen werden sich wahrscheinlich Änderungen ergeben? Wie wird mit Änderungen verfahren, die zu einer Änderung eines Service führen?
SOA-Technologien bieten für einige Fragen elegante Lösungen: Ist durch eine geänderte Anforderung eines Fachbereiches nur die innere Struktur eines Service betroffen, so ändert sich für jene Systeme, die diesen Service aufrufen, nichts, und die Änderung ist schnell vollzogen. Auch wenn die Methode, mit der ein Service aufgerufen werden kann, aufgrund fachlicher Änderungen modifiziert werden muss, bieten die eingesetzten Integrationstechnologien die Möglichkeit, die alten Aufrufmethoden darauf abzubilden (" Mapping"); es können auch einfach zusätzliche Aufrufmethoden angeboten werden. Problematischer wird es bei Änderungen, bei denen unterschiedliche Versionen eines Service angeboten werden müssen und die dann gleichzeitig produktiv genutzt werden. Technisch ist dies kein Problem, aber die Architektur wird komplexer. Zugleich ist es erforderlich, beim Bau neuer Services darauf zu achten, dass beispielsweise nur die jeweils neueste Version vorhandener Services genutzt wird. Andernfalls entsteht ein Geflecht von Abhängigkeiten, das im Zeitablauf nicht mehr zu kontrollieren ist.
Es ist ein Satz von Regeln notwendig, damit der Aufbau einer Service-orientierten Architektur in kontrollierter Form erfolgt und nicht zu einer Situation führt, die komplexer und noch weniger handhabbar ist als mit den monolithischen Systemen der Vergangenheit. Insbesondere bei Design und Implementierung der Services muss überprüft werden, ob die realisierten Services zu den vorhandenen Services passen. Dabei geht es nicht nur um das Vermeiden unnötiger Redundanzen, sondern auch um die Kontrolle erheblicher Einflussfaktoren der Implementierungskosten.
Beispielsweise ermöglichen bei der Deutschen Post die Services den standardisierten Zugriff auf die Domänen, in die die fachliche Geschäftslogik gegliedert ist. Um beispielsweise eine solche, am Kerngeschäft orientierte Gliederung der Services oder Applikationen vornehmen zu können, muss die Enterprise-Architektur mehr als nur die IT-Sicht umfassen.
Enterprise Architecture ist mehr
Eine Enterprise Architecture beinhaltet verschiedene Architekturebenen: Es kann zwischen Geschäfts-, Organisations-, Integrations-, Software- und Daten- sowie Infrastrukturebene unterschieden werden. Im Einzelnen: Die Geschäfts- oder Strategieebene adressiert das Geschäftsmodell und die Positionierung des Unternehmens im Leistungsnetzwerk. Die Organisationsebene beinhaltet die Aufbau- und Ablauforganisation, bei Letzterer insbesondere die Prozessarchitektur. Diese beiden Ebenen sind primär fachlich geprägte Sichtweisen, die unabhängig von den verwendeten Technologien in der IT sind. Die Integrationsebene führt die fachliche und die IT-Sicht zusammen und ermöglicht die Entkopplung der Prozesse von den einzelnen Softwaresystemen und damit erst die flexible Reorganisation der IT-Systeme.
Im Kontext beispielsweise einer SOA erfolgt hier die Choreographie der Services. Auf der Software- und Datenebene finden sich die Softwarekomponenten und Daten wieder, auf der Infrastrukturebene die verwendeten technologischen Plattformen, Server und Netzkomponenten.
Architektur-Governance ist nötig
Die einzelnen Architekturen können allerdings nicht unabhängig voneinander betrieben werden, im Gegenteil: Sie müssen sorgfältig aufeinander abgestimmt werden, um eine schnelle Übernahme von Änderungen auf die jeweils untergeordnete Ebene möglich zu machen und sich abzeichnende Änderungen früh zu antizipieren. Der Granularitätsgrad - also die Frage, wie fein eine Architektur unterteilt ist - unterscheidet sich dabei von der Ebene. Strategische Aspekte werden nur in groben Zügen, Prozesse dagegen mit etwas feinerer Struktur aufgenommen. Die eher technisch geprägten Sichtweisen sind auf der Integrationsebene wiederum detaillierter als auf der Prozessebene. Auf den Software- und Infrastrukturebenen sind sie idealerweise sehr detailliert, da sie dort aus Repositories übernommen beziehungsweise abgeleitet werden können, die im Idealfall bereits bestehen.
Auf den unterschiedlichen Architekturebenen sind Architekturen zu entwerfen, die in sich und mit anderen Ebenen konsistent sind. Dabei sind sowohl fachliche strategische Vorgaben zu berücksichtigen als auch laufende Veränderungen in den Geschäftsprozessen.
Eine schlechte Architektur wirkt bis in die Fachbereiche hinein. Es ist daher eine konsistente Architektur-Governance notwendig, die in die IT und letztlich die Corporate Governance eingebunden wird.
Architekturen als Sammlung von Beschreibungen und Regeln zu ihrer Erstellung und Umsetzung müssen auch kommuniziert werden. Da über die verschiedenen Ebenen hinweg sehr unterschiedliche Ansprechpartner existieren, kommt der zielgruppengerechten Kommunikation der Architektur eine hohe Bedeutung zu. Um wirksam zu werden, ist Glaubwürdigkeit der Architekten gegenüber der Fachseite wie auch den Entwicklern in der IT erforderlich. Daraus ergeben sich in der Praxis unterschiedliche Architekturrollen und Aufgabenträger. Für die Entwicklung und Abstimmung fachlicher Architekturen braucht man Menschen, die idealerweise aus den Fachabteilungen stammen und die Prozesse beherrschen. Für die IT-Architekturen sind solche Mitarbeiter nötig, die schon entwickelt und IT-Projekte geleitet haben.
Vorschläge oder gar Vorgaben der Architektur an die Entwicklung dürfen dort nicht als Restriktion oder umständlich wahrgenommen, sondern müssen als hilfreich und nützlich empfunden werden. Die aktive Mitwirkung in Entwicklungsprojekten, auch die (beispielhafte) Implementierung von Architekturvorgaben durch Architekten selber können dazu beitragen, die Glaubwürdigkeit von Architekten und Architektur in der Entwicklung zu erhöhen.
Vielseitige Architekten gesucht
Problemlose Kommunikation mit Fachabteilungen wie mit Entwicklern, ein Verständnis der Geschäftsprozesse wie technischer Details der verwendeten technologischen Plattformen und die Fähigkeit, dies sowohl leitend als auch durchführend umsetzen zu können: Das sind Anforderungen an einen Architekten, die eine jahrelange praktische Erfahrung mit diesen Themen voraussetzen. In der Summe ergeben sie ein Anforderungsprofil, das in der Praxis kaum ein Mitarbeiter allein abdecken kann. Geeignete Kandidaten für einige der in diesen Anforderungen enthaltenen Architekturrollen sind interessierte Mitarbeiter aus den Fachabteilungen, die dort die Schnittstelle zur IT bilden, sowie in der IT die Projektleiter an der Schnittstelle zu den Fachabteilungen oder auch Entwickler, die sich in die letztgenannte Richtung qualifiziert haben. Alle beschriebenen Rollen gleichzeitig zu spielen wird nur selten möglich sein.
Dies spricht für ein Team von Architekten, das sich, je nach Hintergrund, auf unterschiedliche Schwerpunkte konzentrieren kann.
Joachim Schelp ist Projektleiter an der Integration Factory der Uni St. Gallen.
Robert Winter ist Direktor des Instituts für Wirtschaftsinformatik der Uni St. Gallen.