Evolution der Integrationsarchitektur. Geschäftsorientierte Gestaltung von IT-Anwendungslandschaften. Evolution

Transkript

1 Evolution Geschäftsorientierte Gestaltung von IT-Anwendungslandschaften Evolution der Integrationsarchitektur Infolge unterschiedlicher Integrationsstrategien sind viele IT-Anwendungslandschaften über die Jahre komplexer geworden und können immer weniger Einfl uss auf ihr Wettbewerbsumfeld nehmen, da sie die ursprünglichen Ziele nicht mehr erreichen. Im ersten Teil des Artikels wird auf Basis eines praktischen Beispiels erörtert, wie es zu dieser Situation gekommen ist. Im zweiten Teil wird ein vollständig klassifi ziertes Referenzmodell für eine serviceorientierte Integrationsarchitektur mit umfassender Geschäftsausrichtung diskutiert und schließlich werden strukturelle Implikationen des Gestaltungsprozesses für die Organisation der IT behandelt. 30 bt

2 AUTOREN: KORNELIUS FUHRER UND THOMAS HAVEMEISTER In Unternehmen beginnt die IT-Unterstützung oftmals mit einem Customer-Relationship-Management- (CRM-)System. Mit diesem System werden Kunden- und Vertragsdaten gepflegt, es ist gleichzeitig Produktmodell und Grundlage für die Rechnungsstellung. Eine einfache Webpräsenz dient der Kontaktdatenpflege. Sie enthält ein Content-Management-System und einen Formulardownload für Neuverträge. Die IT-Landschaft wird ergänzt durch weitere Produkte von der Stange aus dem Bereich Finance und Service-Provisioning. Weitere Kaufprodukte folgen in der Regel durch neue Vertriebskanäle oder gesetzliche Vorgaben. Nach einer rasanten Wachstumsperiode ist bei Unternehmen häufig eine ähnliche Symptomatik festzustellen. Durch den starken Zuwachs an Kunden nimmt der Wunsch nach einer höheren Automatisierungsquote zu. Damit nähern wir uns dem in Abbildung 1 dargestellten ersten Integrationsszenario der Ad-hoc-Integration mit einem sternförmigen Kommunikationsmodell. Dieses stützt sich im Wesentlichen auf Coderedundanz und Schnittstellenvielfalt. Im ersten Schritt wurde die Webpräsenz mit dem ursprünglich statischen Formulardownload um eine Order-Komponente K erweitert, die direkt Aufträge in das CRM einstellen kann. Bestandskunden sollen sich am besten selbst verwalten, also wird neben der Webpräsenz zusätzlich ein Kundenportal bereitgestellt. WAS PASSIERT JETZT? Das abstrakte Ziel ist die automatisierte Auftragsannahme und -abwicklung. Es bestehen große Ähnlichkeiten zwischen der Order-Komponente K der Webpräsenz und Orderkomponente K1 im Kundenportal. Daher wird die Komponente um eine Schnittstelle sowie die entsprechende Logik erweitert und beiden Applikationen durch Codeduplikation zur Verfügung gestellt. Mit der Zeit steigt die Komplexität. Monolithen wachsen heran. Der Lebenszyklus beider Applikationen ist stark gekoppelt. Beispielsweise bedeutet eine Bugfixdowntime bei der einen in der Regel auch eine bei der anderen. Ein Portal für Handelsvertreter und Servicemitarbeiter mit ähnlichen Automatisierungsintentionen bekommt seine eigene Order-Komponente, die sich zweckmäßig und autark erweitern lässt. Zur Entlastung des Servicecenters werden externe Dienstleister hinzugenommen, die in Hinblick auf Sicherheit und Vertraulichkeit wiederum eine eigene Applikation erforderlich machen. Technisch wird analog zur Webpräsenz und dem Kundenportal verfahren. Im selben Zeitraum, in dem Applikationsvarianten mit der Intention zur Automatisierung wie Pilze aus dem bt

3 Abb. 1: Integrationsszenario: Ad-hoc-Integration mit sternförmigem Kommunikationsmodell Boden sprießen, verändert sich das Geschäft kontinuierlich. Das muss es auch, damit ein Unternehmen am Markt wettbewerbsfähig bleiben kann. Das CRM wird dafür stetig um neue Produkte und Produktkategorien erweitert, was wiederum Anpassungen in den Applikationen nach sich zieht. Hier eine Modifikation und dort eine neue Schnittstelle so ein Vorgehen bewirkt ein drastisches Ansteigen der Komplexität und Heterogenität. Diese Quick and Dirty - bzw. Copy/Paste - Methodik zieht sich dann wie ein roter Faden durch alle Facetten des Entwicklungsprozesses im Unternehmen. Beginnend bei der Anforderungsaufnahme dem Software- und Datendesign über die Anwendungsarchitekturen bis hin zu einer wildwuchsartig entstandenen IT-Anwendungslandschaft. Mittlerweile ist das historisch gewachsene CRM zur Spinne im Netz mutiert. Geblendet durch die vorherrschenden Performance- und Verfügbarkeitsprobleme, treibt das IT-Management die Mission Skalierbarkeit mit höchster Priorität voran. Schließlich gilt es, weiter zu wachsen. In der Regel führt es zu einer Variante des nächsten Integrationsszenarios. EAI DIE REPLIZIERTE ANWENDUNGSLANDSCHAFT Strategien zur Datenreplikation sind nichts Neues. Datenbank- und ETL/Warehouse-Hersteller bieten ein breites Spektrum an. Die Technik ist gut verstanden, kostenmäßig überschaubar und bringt einen gewissen Komfort mit sich. Zudem wird dieser Ansatz von den Herstellern hoch stilisiert und stark empfohlen. Sie versprechen blitzschnelle Synchronisation im Gigabit-Netzwerk und absolute Konsistenz. Zudem klingt der Ansatz einfacher, praktikabler und ist besser zu kommunizieren als ein kompliziertes Redesign der IT-Anwendungslandschaft. Ferner würde ein kostenintensives Redesign das Wachstum womöglich gefährden und es müssten u. U. neue Mitarbeiter mit entsprechenden Qualifikationen wie z. B. IT-Architekten oder Integrationsspezialisten eingestellt werden. Replikation hingegen ist trivial, denn eigentlich ändert sich ja gar nichts. In den meisten Fällen ist das anfangs auch so. Es wird nochmals kräftig in Hardware und Lizenzen investiert, die Performance steigt, die Ausfallsicherheit erhöht sich. Abbildung 2 illustriert das Szenario. Die IT-Anwendungslandschaft wurde um ein paar Datenbanken reicher. Ein so genannter Replicator repliziert die Masterdaten in alle anderen applikationslokalen Datenbanken und vice versa. Nun wird mithilfe des Tools ein Teil der Masterdaten, der für die Auftragsannahme relevant ist, in die neue Order-Datenbank dupliziert. Da Servicecenter und externes Callcenter einen anderen 32 bt

4 Schwerpunkt setzen, erhalten sie ebenfalls eine eigene lokale Datenbank mit replizierten Daten. Damit sind die wichtigen Portale unabhängig vom Hauptsystem und müssen sich nicht mehr mit den Callcenter-Applikationen einen Datentopf teilen. Wenn das Masterdatensystem jetzt nicht verfügbar ist, sind nicht mehr alle Applikationen gleichzeitig betroffen. Kurzfristig scheint das Ziel der Skalierbarkeit erreicht. DOCH IST DAS AUCH TATSÄCHLICH DER FALL? Die Skalierbarkeit sinkt mit der Anzahl der Systeme. Werden replizierte Masterdaten in einer applikationslokalen Datenbank verändert, müssen das Masterdatensystem und alle anderen applikationslokalen Datenbanken aktualisiert werden. Verkomplizierend wirkt dabei, dass sich Applikationen spezifisch und autark weiterentwickeln. Um die Kompatibilität zu erhalten, müssen die Daten hiernach transformiert werden. Je nach Anzahl der Systeme kann die vermeintlich gewonnene Skalierbarkeit schnell einbrechen, vor allem, wenn die IT des Unternehmens global verteilt ist. Befindet sich das externe Callcenter beispielsweise in Indien, müssten die Daten über schmale Ozeanleitungen repliziert werden. Aber auch im eigenen Netz ist es eine Herausforderung, die Synchronität der Daten und damit die Konsistenz zur gewährleisten: Die geänderten Daten müssen in allen applikationslokalen Datenbanken umgehend zur Verfügung stehen. Im gesamten Unternehmen werden Daten invasiv verteilt. Für die Bearbeitung fast gleicher Daten existieren unzählige Komponentenvarianten (Order H, K, K1, S, S1). Von fast gleichen Daten ist hier die Rede, da der Kunde häufig nicht ein und dieselbe Entität über alle Applikationen hinweg verkörpert. Durch das ganz wichtige IT-Projekt werden die replizierten Datensätze in den applikationslokalen Datenbanken mal eben um ein paar Felder erweitert wer kennt diese Situation nicht? Das Projektbudget und der gesetzte Zeitrahmen reichen selten aus, um die Änderungen am Masterdatensystem und dann auch in allen peripheren Applikationsdatenbanken vorzunehmen. Zusehends verschwimmt die Kenntnis darüber, welche Applikation die Hoheit über welche Daten hat, und so schwindet auch die Kontrolle über die Daten mehr und mehr.

5 Abb. 2: EAI und Datenreplikation Diese Entwicklung wirkt sich bis in den Fachbereich aus, der für rasche Erweiterungen des Geschäftsmodells eine Art Geschäftssicht benötigt. Das Beispiel des Geschäftsobjekts Kunde kann somit in einem applikationsübergreifenden Geschäftsprozess kaum noch modelliert werden. In der Konsequenz wird die Adaptivität und Reaktivität des Unternehmens zum Markt reduziert und das weitere Wachstum gefährdet. Das ursprünglich allein existierende Masterdatensystem muss Geschäfts- und Zugrifflogik auf die Daten angewendet haben. Die Verteilung der Daten bringt damit zwangsweise auch die redundante Verteilung dieser Logik mit sich. Auch hier wird diese separat und applikationsspezifisch modifiziert, d. h. Änderungen im Masterdatensystem müssen nun in alle peripheren Applikationen, die die ursprünglich gleiche Geschäfts- und Zugriffslogik spezifisch erweitert haben, migriert und getestet werden. Nicht selten erfordert diese Änderung einen erheblichen Roundtrip durch die IT-Anwendungslandschaft. Testteams haben in solchen Unternehmen eine beachtliche Größe und Sonderstellung. Nicht selten können sie schon in der Entwurfsphase mitbestimmen, was überhaupt testbar ist und somit umgesetzt werden darf. Änderungen werden so kostenintensiv und unplanbar, Agilität und Flexibilität des Unternehmens nehmen immer mehr ab. Die Komplexität erhöht sich weiter, wenn für Applikationen bereits replizierte Daten erneut repliziert werden. Am Beispiel des externen Callcenters in Abbildung 2 zeigt sich die so genannte zweistufige Replikation. Klar ist, dass auch hier wieder die Geschäfts- und Zugriffslogik mitgeliefert werden, die sich nur diesmal nicht direkt vom Masterdatensystem ableiten. Diese Replikation entwickelt sich nicht selten zu einer zweistufigen Transformation. In diesem Komplexitätsstadium lassen sich IT-Projekte kaum noch umsetzen und testen. Vor dem Hintergrund, dass aus der Geschäftsstrategie bestimmte Geschäftsziele abgeleitet und zu Anforderungen und von IT-Projekten umgesetzt werden, können die langfristigen Folgen für die Wettbewerbsfähigkeit eines Unternehmens drastisch ausfallen. Ursprünglich wurde die Replikationsstrategie gewählt, um Kosten zu sparen. Mittelfristig ist jedoch das Gegenteil der Fall: Es werden zusätzliche Infrastruktur, mehr Plattenplatz, mehr Netzwerk-Traffic und weitere Datenbanken benötigt und außerdem weitere Mitarbeiter, die das alles administrieren. Sicherlich existieren in einigen Bereichen auch sinnvolle Replikationsszenarien, z. B. im Umfeld der Hochverfügbarkeit, Reporting oder auch bei der später diskutierten Legacy-Entkopplung. SERVICEORIENTIERTE INTEGRATIONSARCHITEK- TUR MIT GESCHÄFTSAUSRICHTUNG Während das Geschäftsmodell die Geschäftstätigkeit der Organisation in der Gegenwart beschreibt, definiert 34 bt

6 die Strategie das koordinierte Vorgehen zur Erreichung von Zielen eines zukünftigen Geschäftsmodells. Das Ziel sollte dabei die Erhaltung oder Verbesserung der Position im Wettbewerbsumfeld sein. Im Kontext der Geschäftsausrichtung können Geschäftsmodell und Service als korrespondierende Artefakte betrachtet werden, die eine in sich geschlossene und eigenständige Geschäftstätigkeit aus einer jeweils anderen Perspektive betrachten und sich ausschließlich in dem Grad der IT-Unterstützung unterscheiden. Die in den folgenden Abschnitten klassifizierte serviceorientierte Integrationsarchitektur berücksichtigt diesen strategischen Wandel des Geschäftsmodells, indem sie die Artefakte der Geschäftsarchitektur auf die Artefakte der IT-Anwendungslandschaft abbildet und im Rahmen eines so genannten Business-IT- Align ments fortlaufend aufeinander ausrichtet. Einerseits verschafft es dem Unternehmen dabei die Fähigkeit, mit innovativen Impulsen seine Wettbewerbsumgebung zu stimulieren und andererseits die erforderliche Agilität, um adaptiv auf eine veränderte Marktsituation reagieren zu können. Im Gegensatz zu den bisher diskutierten Integrationsarchitekturen ist der Gestaltungsprozess in diesem Szenario mehrdimensional und äußerst facettenreich. Hier geht es weder nur um die Einführung eines neuen IT-Produkts oder einer Technologie, noch kann dieser Ansatz auf eine IT-Strategie reduziert werden. In diesem Fall muss das Unternehmen als Ganzes betrachtet werden, denn die Veränderungen betreffen die Unternehmenskultur, Organisationsstrukturen, Prozesse, Rollen, Menschen und deren Einflussbereiche. Bei diesem Ansatz handelt sich um einen langfristigen Prozess mit spätem Return on Invest (ROI), der auf Nachhaltigkeit ausgelegt ist. Eine Einbettung in die Unternehmensstrategie ist deshalb notwendig alleine schon, um lokale Interessen von Organisationseinheiten und kurzfristigen IT-Projekten zu übersteuern. Dieses Integrationsszenario adressiert einen ganzheitlichen Ansatz zur geschäftsorientieren Gestaltung Abb. 3: Referenzarchitektur für ein serviceorientiertes Integrationsszenario mit Geschäftsausrichtung von IT-Anwendungslandschaften und schafft schlussendlich den Grundstein für das strategische Management der Unternehmensarchitektur. Für die realistische Planung, Steuerung und Bewertung des Gestaltungsprozesses ist es enorm wichtig, sehr früh mit dem Aufbau eines qualitativ hochwertigen Fundaments einer Unternehmensarchitektur zu beginnen. ASPEKTE DER UNTERNEHMENSARCHITEKTUR Die Unternehmensarchitektur beschreibt das Unternehmen sowie die zugrunde liegende IT-Anwendungslandschaft aus einer höchst abstrahierten, fachlichen Perspektive. Die Modellierung der Unternehmensarchitektur schafft in erster Linie Transparenz über das Geschäftsmodell und dessen IT-Unterstützung und stellt damit die Verknüpfung zwischen Geschäfts- und IT-Strukturen her. In einem weiteren Schritt wird ein Instrumentarium bereitgestellt, mit dem der Gestaltungsprozess koordiniert werden kann. Im Rahmen der ganzheitlichen Betrachtung der Unternehmensebene beleuchten Teilarchitekturen der Unternehmensarchitektur die IT-Anwendungslandschaft jeweils aus einem anderen Blickwinkel. Jede der folgend aufgeführten bt

7 Teilarchitekturen macht dabei Vorgaben zu den Architekturelementen, mit denen sie bebaut werden darf. GESCHÄFTSARCHITEKTUR Die Geschäftsarchitektur betrachtet die Fachlichkeit der Organisation. Elementare Bebauungsartefakte der Geschäftsarchitektur sind die Produkte, die Geschäftsprozesse mit Akteuren und unterschiedlichen Rollen, Geschäftsdomänen inklusive Geschäftsfunktionen und -services sowie Geschäftsobjekte. Geschäftsdomänen sind die logischen Einheiten des Unternehmens. Sie segmentieren die Geschäftsarchitektur und kapseln ihr Geschäftsmodell über ein definiertes Spektrum an Geschäftslogik, ohne Redundanzen zu erzeugen. Letzteres adressiert die Normalisierung der Fachlichkeit und pos tuliert die vollständige und eindeutige Lokalisierung von Geschäftslogik. Geschäftsdomänen aggregieren Geschäftsfunktionen, die aus fachlicher Sicht eine Einheit bilden und die fachliche Normalisierung weiter verfeinern. Dieser Verfeinerungsprozess zieht sich über die Geschäftsservices von Geschäftsfunktionen und wird auf die korrespondierenden IT-Services bis auf dessen Geschäftslogikbausteine abgebildet. Geschäftsdomänen stellen somit einen idealen Zielzustand dar und bilden die Schnittfläche zum Business-IT-Alignment. Eine Geschäftsfunktion ist eine grobgranulare, kontextfreie und unterteilbare fachliche Funktionalität. Sie zeichnet sich durch ihre Unabhängigkeit vom Kontext eines Geschäftsprozesses aus und bleibt dadurch über verschiedene Geschäftsprozesse hinweg anwendbar. Geschäftsfunktionen sind elementare Bausteine zum Aufbau von Geschäftsprozessen. Sie bündeln eine Anzahl von Geschäftsservices, die sich direkt auf einen IT-Service abbilden lassen. IT-SERVICEARCHITEKTUR Die IT-Servicearchitektur definiert die IT-Service-Sicht der Unternehmensarchitektur. Hier werden die IT-Services verwaltet und beschrieben, die für die Ausführung der Geschäftsprozesse erforderlich sind (z. B. der Auftragsabwicklung bei Produktbestellungen). INFORMATIONSARCHITEKTUR In der Informationsarchitektur werden die Geschäftsdaten mit ihren Beziehungen identifiziert und beschrieben. Durch die Modellierung von Informationsflüssen verbindet diese Architektur die konkreten Bebauungsartfakte der IT-Anwendungslandschaft horizontal sowie die jeweiligen Teilarchitekturen vertikal. TECHNISCHE ARCHITEKTUR Die technische Architektur umfasst Architekturelemente wie Plattformen, unternehmensspezifische technische Standards und Betriebsinfrastruktur-Bestandteile, die für den Aufbau und den Betrieb erforderlich sind. Sie definiert die Basis, auf der IT-Services beschafft, integriert und betrieben werden können. REFERENZ-UNTERNEHMENSARCHITEKTUR Abbildung 3 veranschaulicht die gesammelten und branchenübergreifenden Projekterfahrungen der Autoren im Kontext von qualitativ hochwertigen serviceorientierten Integrationsarchitekturen mit einer sehr engen Geschäftsausrichtung auf der Flughöhe der Unternehmensarchitektur. Ein fundamentaler Schritt zur Modellierung des Geschäfts ist die Definition von Geschäftsdomänen und die Segmentierung in diese. Die Geschäftsdomänen bilden praktisch die Schnittfläche zwischen den Harmonisierungsbestrebungen von Fachbereich und IT. Mit ihrer Hilfe können zum einen die Verantwortungsbereiche im Unternehmen geschäftsorientiert gestaltet werden, zum anderen können aber auch verschiedene Geschäftsmodelle, Strategien und Ziele pro Geschäftsdomäne gelten. Der Hauptfokus gilt der Geschäftsarchitektur. Während sie zunächst einmal unabhängig von der konkreten IT-Anwendungslandschaft existiert, bildet die Geschäftsarchitektur den Ausgangspunkt für die geschäftsorientierte Ausrichtung einer Zielanwendungslandschaft. Auf technischer Ebene übernimmt ein Service Bus pro Geschäftsdomäne die Segmentierung. So lassen sich domänenübergreifende Harmonisierungsbestrebungen durch Unternehmensstandards und Richtlinien gestalten, basierend auf einer Auswahl von De-facto- und Industriestandards. Diese sind wichtig, um die Synergieeffekte bei Betrieb, Wartung und Entwicklung von Services verstärkt zu nutzen und letztendlich die IT-Kosten zu reduzieren. Gleichzeitig wird innerhalb der Geschäftsdomäne ein wichtiger Spielraum für eine kontrollierte Heterogenität geschaffen, die ein notwendiges Maß an Innovationen und Flexibilität ermöglicht. In vielen Teams lässt sich ein domänenspezifischer Best-of-breed-Ansatz nur so umsetzen. Tatsächlich ist die flexible Kombinierbarkeit in Form einer hochgradigen Wiederverwendbarkeit von Geschäftslogik zur Laufzeit ein fundamentales Merkmal, um die strategischen Ziele der Serviceorientierung zu erreichen. Einerseits sind Unternehmensstandards zum Entwurf von wiederverwendbaren IT-Services erforderlich, andererseits müssen Richtlinien den offiziellen und singulären Zugriffspunkt auf die Geschäftslogik, die von ihnen gekapselt ist, über ein zentral verfügbares, fachlich normalisiertes IT-Serviceinventar absichern. Ausgehend von den zugehörigen Geschäftsdomänen repräsentiert ein IT-Service eine eigene Funktionsdomäne in dem beschriebenen Inventar, die über die Geschäfts- 36 bt

8 logikbausteine noch weiter verfeinert wird. Analog dazu implementieren die Geschäftsobjektbausteine eine stringent vertikalisierte Zugriffskontrolle auf die inkludierten Geschäftsobjekte, die einen disjunkten Ausschnitt an Geschäftsdaten der gesamten Organisation kapseln und damit die dargestellte Datenhoheit charakterisieren. Das Streben nach Interoperabilität ist die Basis für die unternehmensweite Wiederverwendung über die Grenzen der Geschäftsdomänen hinweg und stellt einen inhärenten Bestandteil der hier vorgestellten Referenzarchitektur dar. Für die effektive Wiederverwendbarkeit der IT-Services ist es zwingend erforderlich, dass eine zuverlässige Performance zu jedem Zeitpunkt gewährleistet werden kann. Die Performance kann nur durch die absolute Kontrolle über alle beteiligten Software- und Hardwarebausteine und durch eine so genannte Laufzeitautonomie zur Ausführung der Geschäftslogik gesichert werden. Das bedeutet, dass dem IT-Service eine eigene Umgebung, idealerweise inklusive Applikationsserver und Datenbank, hochverfügbar zur Verfügung steht und auf eine hochgradig nebenläufige Verarbeitung optimiert werden kann. Autonome IT- Services existieren weitgehend unabhängig von ihrer Peripherie als eigenständige Konstrukte. Exklusiv und redundanzfrei kapseln sie ein Segment an Geschäftslogik und adressieren damit fachliche Dekomposition eines Inventars, die zuvor erläutert wurde. Ein hoher Autonomiegrad ist vermutlich der wichtigste Wegbereiter für die erstrebenswerten Eigenschaften von IT-Services, über die in der Literatur häufig diskutiert wird, wie beispielsweise die Kontextfreiheit, Wiederverwendbarkeit, Interoperabilität und die lose Kopplung. SANFTE MIGRATION DURCH SKALIERBARE LEGACY-INTEGRATION Legacy-Applikationen, wie das CRM-System aus Abbildung 3, die teilweise nützliche Funktionalitäten anbieten, müssen zuerst aus dem bestehenden Anwendungsgeflecht vertikal entkoppelt und über so genannte Adapter- oder Wrapper-Services gekapselt werden. Die vertikale Entkopplung hat das Ziel, eine beliebige Applikation, inklusive der zu verwaltenden Daten, aus einer Anwendungslandschaft vertikalisiert herauszulösen und in einer eigenen autonomen, hochgradig skalierbaren

9 Umgebung zu betreiben. Dies ist essenziell wichtig für deren Integration in das serviceorientierte Umfeld. Nur so können im Umfeld von Orchestrationen, Kompositionen oder der konkurrierender Benutzung die angestrebte Stabilität, Zuverlässigkeit und Berechenbarkeit zur Laufzeit gewährleistet werden. Die richtige Balance eines Service-Enablements von Legacy-Umgebungen kann eine wahre Herausforderung werden. Welche Teile der Geschäftslogik wie abstrahiert werden sollen, kann meistens nur in Abhängigkeit von darunterliegendem Serviceadapter sowie den damit gekoppelten Legacy- APIs entschieden werden. Beachtet werden sollte dabei, dass vor der Entkopplung und Kapselung alle Funktionalitäten über Jahre hinweg unternehmensweit zur Verfügung standen. Höchstwahrscheinlich existieren komplexe Abhängigkeitsgeflechte transitiv durch die gesamte IT-Anwendungslandschaft, sodass sich eine isolierte Zugriffskontrolle auf die abstrahierten Fähigkeiten über Wrapper-Services höchst anspruchsvoll gestalten kann. Für die korrekte Funktionsweise der abstrahierten Fähigkeiten muss die Datenkonsistenz zu jedem Zeitpunkt sichergestellt sein. Speziell für diesen Fall macht eine gerichtete, ereignisbasierte Replikationsstrategie von selektiven Datenstrukturen zur Gewährleistung der Konsistenz Sinn. In diesem Szenario sind Rückreplikationen strengstens verboten. Dieser Mechanismus ist in Abbildung 3 in der Informationsarchitektur innerhalb der beiden Geschäftsdomänen PRODUCT MANAGE- MENT und CUSTOMER CONTRACT abgebildet. Hier ist es wichtig, ständig abzuwägen, ob es kostengünstiger ist, vorerst eine Legacy-Applikation zu entkoppeln und einen Teil der Funktionalität zu abstrahieren und über Services zu publizieren oder den Service neu zu entwickeln und die Legacy-Applikation abzuschalten. Der hier beschriebene Weg der sanften Migration zur Serviceorientierung, die Neuentwicklung von Services, das Schneiden von Geschäftsdomänen sowie der Rückbau der Legacy-Anwendungen erfolgt in iterativinkrementellen Schritten. Bei jedem Schritt findet in der Regel ein Erkenntnisgewinn statt, der in die nächste Entwicklungsstufe einfließt. Für diesen langwierigen Weg der evolutionären Vervollkommnung der IT-Anwendungslandschaft wird durch die Weiterverwendung der abstrahierten Legacy-Fähigkeiten das nötige Zeitfenster bereitgestellt. Des Weiteren stellt diese Weiterverwendung einen belastbaren Investitionsschutz dar. STRUKTURELLE AUSWIRKUNGEN AUF DIE ORGANISATIONSTRUKTUR DER IT Die IT-Organisationsstruktur basiert häufig auf einer Kombination von Technologien (z. B. Webportalen, JEE- Middleware), Produkten (z. B. SAP, Peoplesoft, Oracle) und Themen (z. B. Rechnungslegung, Kundenservice). Aufgrund der allgegenwärtigen Marktdynamik, der daraus resultierenden kontinuierlichen Weiterentwicklung der IT-Anwendungslandschaft, neuen aufkommenden IT-Trends und Softwareprodukten ist die Verschiebung der ursprünglichen Strukturen ohne Zweifel ein dauerhaftes Thema. Aus dem Beispiel im ersten Teil könnte sich ergeben, dass eine Abteilung für Webportale eine Applikation für externe Callcenter allein deswegen entwickelt, weil es sich um eine browserbasierte Anwendung handelt. Das parallel dazu aufgestellte themenorientierte Team Kundenservice setzt jedoch weiterhin auf den klassischen Rich-Client-Ansatz und entwickelt trotz großer fachlich-inhaltlicher Überschneidungen die Anwendung für das interne Callcenter nahezu unabhängig weiter. Es wäre nun sicher ein einfacher Schritt, die Teamstruktur nach dem altbewährten Verfahren zu korrigieren und sich auch in Zukunft mit einer vielleicht unpassenden Einteilung zu arrangieren. Eine Verbesserung ist damit freilich nicht zu verzeichnen. Eher das Gegenteil ist der Fall, denn man würde bei einer Neustrukturierung möglicherweise eingespielte Teams und wertvolles Knowhow zerschlagen. Obwohl Geschäftsprozesse über viele Fachabteilungen laufen und verteilte IT-Systeme längst an der Tagesordnung sind, wird dies in der IT-Organisationsstruktur häufig unzureichend reflektiert. Für heutige Anwendungslandschaften wird deswegen ein organisatorisches Konzept für verteilte Systeme gesucht. Im Kern steht also die Zusammenarbeit und Kommunikation der Mitarbeiter und Teams. Als wichtigster Beitrag dafür gilt die Stärkung der Projektkultur und Flexibilisierung der Organisationsstruktur. Fachseitig gewünschte neue Funktionalitäten entstehen nicht mehr isoliert in Abteilungen. Vielmehr sind es Projekte, die die gewünschten Fachanforderungen flächendeckend in die Anwendungslandschaft einführen. Sehr zum Unmut der Fachseite sind jedoch IT-Abteilungsgrenzen, mit denen ein solches Projekt zu kämpfen hat, nicht selten der größte Risikotreiber im Projekt und in dessen Budget. Mit einer stärker am Geschäftsmodell ausgerichteten IT- Organisationsstruktur stünden dem Projekt keine künstlich geschaffenen IT-Abteilungsgrenzen mehr entgegen. Die klassische technologie- oder produktspezifische Teamstruktur hat hier offensichtlich keine Zukunft. Doch wie mit Kompetenzteams verfahren? Der Ansatz, mit zentralen Expertenteams (Architekturteam, SOA-Team, IT-Polizei usw.) flächendeckendes Knowhow in die Organisation einzusteuern, wird bei vielen Unternehmen praktiziert und führt häufig zu Verbesserungen. Im Kern einer solchen Initiative steht jedoch ein angestrebter Kulturwandel und nicht die dauerhafte 38 bt

10 Etablierung eines Kompetenzcenters. Die Mission des Expertenteams ist erst erfolgreich abgeschlossen, wenn das Know-how und die gewünschten Prinzipien auf die Arbeitsweise der Organisation übergehen. Eine Dezentralisierung führt dazu, dass Spezialisten quasi embedded, also ganz natürlicher Bestandteil der Organisation, sind. Im Resultat kann sich das Kompetenzteam damit auflösen. Ohne die Unterstützung aus dem Management bleiben jedoch angestammte Fürstentümer, Profitcenter und künstliche IT-Abteilungsgrenzen unverändert bestehen. CEO und CIO/CTO müssen die Strategie und die Implikation einer verteilten IT-Anwendungslandschaft verstanden haben und sie bei ihren Mitarbeitern engagiert vertreten. Die konkrete strukturelle Neuausrichtung stellt sich für jedes Unternehmen anders dar, da sich die Geschäftsfelder und Geschäftsprozesse sehr unterschiedlich gestalten. Deswegen sollte ein abstrakter fachdomänenzentrierter Ansatz im Zentrum der Betrachtung stehen. Implizit hat die Ausrichtung nach Geschäftsdomänen multidimensionale Auswirkungen, die auch vor der Organisationsstruktur den Rollenmodellen und Mitarbeiterprofilen mit neuen Ansprüchen, Erwartungen und Fähigkeiten nicht halt machen. RESÜMEE UND AUSBLICK In den frühen Phasen dominierten die technischen Aspekte bei der Integration von Applikationen. Diese stell ten basierend auf dem Silomodell statische Funktionalitäten über einen Datentopf zur Verfügung. Wiederverwendung fand über maßgeschneiderte Schnittstellen sowie durch Redundanz auf Code- und Da tenebene statt. So entstanden über die Jahre wildwuchs artig hochkomplexe und schwer beherrschbare IT-Anwendungslandschaften. Fachliche Anforderungen konnten kaum noch effizient auf IT-Strukturen projiziert werden. Die IT-Kosten stiegen, der Geschäftsmehrwert sank und der Return on Invest blieb aus. Die hier vorgestellte serviceorientierte Integrationsarchitektur soll die genannten Unzulänglichkeiten durch ihre enge Verzahnung mit dem Geschäft beseitigen und helfen, die Geschäftsprozesse zu flexibilisieren sowie die IT-Kosten zu reduzieren. Hierfür dienen die Geschäftsdomänen als eine Art Ausrichtungsfläche für das so genannte Business-IT-Alignment. Im Kontext eines idealen Referenzmodells einer Unternehmensarchitektur wurde die Verknüpfung der Geschäftsarchitektur mit der IT-Anwendungslandschaft dargestellt. Dabei wurde die Abbildung der Bebauungsartefakte der Geschäftsarchitektur auf die der IT-Servicearchitektur aufgezeigt und Letztere bis auf die essenziellen technischen Attribute der IT-Services weiter aufgefächert. Über die angedeuteten Wege einer sanften Migration kann die IT- Anwendungslandschaft in einer iterativ-inkrementellen Vorgehensweise evolutionär umgestaltet werden. Nicht selten zieht der Gestaltungsprozess eine strukturelle Reorganisierung von Bereichen, Abteilungen und Teams nach sich. Schon allein diese Punkte, aber auch die Übersteuerung kollidierender Interessen von IT-Projekten oder Organisationseinheiten, sind ausschlaggebend für die strategische Einbettung. IT-Anwendungslandschaften strategisch zu gestalten und zu steuern, heißt, höchste Komplexität zu beherrschen. Interaktionen zwischen Strategie, Geschäftsmodell und IT-Anwendungslandschaft müssen detailliert berücksichtigt und in Form eines koordinierten planerischen Prozesses zusammengebracht werden. Im ersten Schritt reicht eine grobe Modellierung der Unternehmensarchitektur zunächst aus, um die notwendige Transparenz zu schaffen. Für das Management der Unternehmensarchitektur sind eine standardisierte Qualität über Modellierungsrichtlinien sowie die Aktualität über entsprechende Governance-Prozesse zu gewährleisten. Nur auf dieser Grundlage kann der Gestaltungsprozess schon in einem frühen Stadium begleitet und die Unternehmensarchitektur mit den Konzepten des Managements geplant, gesteuert und bewertet werden. Kornelius Fuhrer ist bei OPITZ CONSULTING in München als Senior Berater beschäftigt. Als klassischer IT-Architekt verfügt er über mehrjährige Erfahrung in der Konzeption und Entwicklung von hochwertigen serviceorientierten Integrationsarchitekturen. Seine Kernkompetenzen richten sich auf Prozesse zur geschäftsorientierten Gestaltung und der strategischen Steuerung von IT-Anwendungslandschaften. Thomas Havemeister arbeitet als IT-Architekt bei Kabel Deutschland. Er beschäftigt sich mit der Planung, Realisierung und Integration von unternehmensweiten IT-Projekten. Ein Schwerpunkt seiner Arbeit bildet die strategische Weiterentwicklung und Verbesserung der IT-Anwendungslandschaft und IT-Prozesse. bt