Evolution der Integrationsarchitektur

Transkript

1 Whitepaper Evolution der Integrationsarchitektur IT-Anwendungslandschaften geschäftsorientiert und nachhaltig wertschöpfend gestalten

2 Evolution der Integrationsarchitektur IT-Anwendungslandschaften geschäftsorientiert und nachhaltig wertschöpfend gestalten Autoren: Kornelius Fuhrer und Thomas Havemeister für OPITZ CONSULTING Haben Sie Fragen zu diesem Thema? Dann sprechen Sie uns gerne an! Ihr Ansprechpartner: Torsten Winterberg, Business Development & Innovation OPITZ CONSULTING Inhaltsübersicht 1. Ad-hoc-Integrationsarchitekturen mit sternförmigem Kommunikationsmodell 2. Enterprise Application Integration (EAI) die replizierte Anwendungslandschaft Vorwort Infolge unterschiedlicher Integrationsstrategien sind viele unternehmensweite IT-Anwendungslandschaften über die Jahre komplexer geworden. Dabei generieren sie zunehmend weniger Geschäftswert. In diesem schwierigen Umfeld lassen sich Strategien, Ziele, Anforderungen und Maßnahmen über IT-Projekte weder umfassend planen noch effizient umsetzen. Trotz steigendender IT-Kosten können diese Organisationen immer weniger Einfluss auf ihr Wettbewerbsumfeld nehmen. 3. Serviceorientierte Integrationsarchitektur mit Geschäftsausrichtung 4. Auswirkungen auf die IT-Organisationsstruktur 5. Resümee und Ausblick Wie ist es dazu gekommen? Diese Frage wird im ersten Teil des Whitepapers auf Basis eines praktischen Beispiels erörtert. Auf der Grundlage eines ganzheitlichen und strategischen Ansatzes zur Gestaltung von IT-Anwendungslandschaften wird im zweiten Teil des Whitepapers ein vollständig klassifiziertes Referenzmodell für eine serviceorientierte Integrationsarchitektur mit Geschäftsausrichtung diskutiert. Mögliche strukturelle Implikationen des Gestaltungsprozesses für die Organisation der IT werden im letzten Teil behandelt. Texte und Abbildungen wurden mit größter Sorgfalt erarbeitet. OPITZ CONSULTING kann jedoch für eventuell verbleibende fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Das Recht an dargestellten Verfahren, Showcases, Implementierungsbeispielen und Sourcecodes liegt ausschließlich bei OPITZ CONSULTING. Titelbild: Birgit Meyke Fotolia.com Seite 2

3 Ad-hoc-Integrationsarchitekturen mit sternförmigem Kommunikationsmodell In Unternehmen beginnt die IT-Unterstützung oftmals mit einem Customer-Relationship-Management-System (CRM). Mit diesem System werden Kunden- und Vertragsdaten gepflegt, es ist gleichzeitig Produktmodell und Grundlage für die Rechnungsstellung. Eine einfache Web-Präsenz dient der Kontaktdatenpflege. Sie enthält ein Content Management System und einen Formular Download 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 vielen Unternehmen eine ähnliche Symptomatik festzustellen. Durch den starken Zuwachs der Kundenanzahl nimmt der Wunsch nach einer höheren Automatisierungsquote zu. Damit nähern wir uns dem ersten Integrationsszenario, das in Abbildung 1 dargestellt wird: der Ad-hoc-Integration mit einem sternförmigen Kommunikationsmodell. Dieses stützt sich im Wesentlichen auf Code- Redundanz und Schnittstellenvielfalt. Im ersten Schritt wurde die Web- Prä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 Web-Präsenz zusätzlich ein Kundenportal bereitgestellt. Was passiert jetzt? Das abstrakte Ziel ist die automatisierte Auftragsannahme und -abwicklung. Es bestehen große Ähnlichkeiten zwischen den Order Komponente K der Web-Präsenz und Order-Komponente K1 im Kundenportal. Daher wird die Komponente um eine Schnittstelle sowie der entsprechenden Logik erweitert und beiden Applikationen durch Code-Duplikation 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 der anderen. Ein Portal für Handelsvertreter und Service-Mitarbeiter mit ähnlichen Automatisierungsintensionen bekommt seine eigene Order-Komponente, die sich zweckmäßig und autark erweitern lässt. Zur Entlastung des Service Centers werden externe Dienstleister hinzugenommen, die in Hinblick auf Sicherheit und Vertraulichkeit wiederum eine eigene Applikation erforderlich machen. Technisch wird analog zur Web-Präsenz und dem Kundenportal verfahren. Im selben Zeitraum, in dem Applikationsvarianten die Automatisierung zum Ziel haben, wie Pilze aus dem 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. Abbildung 1: Integrationsszenario: Ad-hoc-Integration mit sternförmigem Kommunikationsmodell Seite 3

4 Diese Quick & 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 das zu einer Variante des nächsten Integrationsszenarios: Enterprise Application Integration (EAI) die replizierte Anwendungslandschaft Strategien zur Datenreplikation sind nichts Neues. Datenbank und ETL-/ Warehouse-Hersteller bieten zu diesen 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 Re-Design der IT-Anwendungslandschaft. Ferner würde ein kostenintensives Re-Design 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 scheint ungefährlich, denn eigentlich ändere sich ja gar nichts... In den meisten Fällen ist dies anfangs ja 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 sogenannter Replicator repliziert die Masterdaten in alle anderen applikationslokalen Datenbanken und umgekehrt. Nun wird mithilfe des Tools der Teil der Masterdaten, der für die Auftragsannahme relevant ist, in die neue "Order-Datenbank" dupliziert. Da Service-Center und externes Call-Center einen anderen Schwerpunkt setzen, erhalten diese 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 Call-Center-Applikationen einen Datentopf teilen. Wenn das Masterdaten-System jetzt nicht verfügbar sein sollte, wären nicht mehr alle Applikationen gleichzeitig betroffen. Kurzfristig scheint also das Ziel der Skalierbarkeit erreicht. Doch ist dies auch wirklich der Fall? Der schöne Schein trügt Die Skalierbarkeit sinkt mit der Anzahl der Systeme. Werden replizierte Masterdaten in einer applikationslokalen Datenbank verändert, muss das Masterdaten-System aktualisiert werden und damit ebenfalls alle anderen applikationslokalen Datenbanken. Verkomplizierend wirkt dabei, dass sich Applikationen langfristig spezifisch und autark weiterentwickeln. Um die Kompatibilität zu erhalten, müssten die Daten jedes Mal entsprechend 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 Call-Center 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 zu gewährleisten: Die geänderten Daten müssen in allen applikationslokalen Datenbanken stets 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. Für 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 zu selten aus, um die Änderungen am Masterdaten-System und in allen peripheren Applikationsdatenbanken vorzunehmen. Zusehends verschwimmt die Kenntnis darüber, welche Applikation die Hoheit über welche Daten hat, und so schwindet auch mehr und mehr die Kontrolle über die Daten. 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übergreifendem 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 Masterdaten-System muss Geschäftsund 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 Masterdaten-System, müssen nun in alle peripheren Applikationen, die die ursprünglich gleiche Geschäfts- und Zugrifflogik spezifisch erweitert haben, migriert und dort getestet werden. Nicht selten erfordert diese Änderung einen erheblichen Round-trip durch die IT-Anwendungslandschaft. Seite 4

5 Abbildung 2: EAI und Datenreplikation 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 nicht planbar. Die Agilität und Flexibilität des Unternehmens nimmt immer mehr ab. Die Komplexität erhöht sich weiter, wenn für Applikationen bereits replizierte Daten erneut repliziert werden. Am Beispiel des externen Call- Centers in Abbildung 2 zeigt sich die sogenannte zweistufige Replikation. Klar ist, dass auch hier wieder die Geschäfts- und Zugriffslogik mitgeliefert wird, die sich diesmal nur nicht direkt vom Masterdaten-System ableitet. 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 werden und aus diesen Anforderung entstehen, die von IT-Projekten umgesetzt werden müssen, 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 von Hochverfügbarkeit, Reporting oder auch bei der später diskutierten Legacy-Entkopplung. Serviceorientierte Integrationsarchitektur mit Geschäftsausrichtung Während das Geschäftsmodell die Geschäftstätigkeit der Organisation in der Gegenwart beschreibt, definiert die Strategie das koordinierte Vorgehen zur Erreichung von Zielen eines zukünftigen Geschäftsmodells. Konsequenz 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 Seite 5

6 der IT-Anwendungslandschaft abbildet und im Rahmen eines sogenannten Business-IT-Alignments fortlaufend aufeinander ausrichtet. Einerseits verschafft dies dem Unternehmen die Fähigkeit, seine Wettbewerbsumgebung mit innovativen Impulsen 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- Produktes oder einer Technologie, noch kann dieser Ansatz auf eine IT- Strategie reduziert werden. Nein. 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 von kurzfristigen IT- Projekten zu übersteuern. Dieses Integrationsszenario adressiert einen ganzheitlichen Ansatz zur geschäftsorientieren Gestaltung 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 Ge-schäftsund 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 Teilarchitekturen macht dabei Vorgaben zu den Architekturelementen, mit denen sie bebaut werden darf. Geschäftsarchitektur Die Geschäftsarchitektur betrachtet die Fachlichkeit der Organisation. Die elementaren Bebauungsartefakte der Geschäftsarchitektur sind die Produkte, die Geschäftsprozesse mit den Akteuren und den unterschiedlichen Rollen, den Geschäftsdomänen inklusive Geschäftsfunktionen und - services sowie den Geschäftsobjekten. 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 redundanzfrei. Letztes adressiert die Normalisierung der Fachlichkeit und postuliert 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 Zielstand dar und bilden die Schnittfläche zum Business-IT- Alignment. Eine Geschäftsfunktion ist eine grobgranulare, kontextfreie unterteilbare fachliche Funktionalität. Eine Geschäftsfunktion zeichnet sich durch ihre Unabhängigkeit vom Kontext eines Geschäftsprozesses aus und kann dadurch über verschiedene Geschäftsprozesse hinweg anwendbar sein. 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 wie z. B. der Auftragsabwicklung bei Produktbestellungen erforderlich sind. Informationsarchitektur In der Informationsarchitektur werden die Geschäftsdaten mit ihren Beziehungen identifiziert und beschrieben. Durch die Modellierung von Informationsflüssen verbindet sie 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 Betriebsinfrastrukturbestandteile, die für Aufbau und 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 Seite 6

7 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 diese zunächst einmal unabhängig von der konkreten IT-Anwendungslandschaft existiert, bildet die Geschäftsarchitektur den Ausgangspunkt für die geschäftsorientierte Ausrichtung einer Ziel-Anwendungslandschaft. 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 notwendige Maß an Innovationen und Flexibilität ermöglicht. In vielen Teams lässt sich ein domänenspezifischer Best-of-bread-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. Die effektive Wiederverwendung von Laufzeitkomponenten ist ein wesentlicher Unterschied zu den zuvor vorgestellten Integrationsarchitekturen, die sich höchstens auf die Wiederverwendung zur Entwurfszeit beschränken und dadurch erhebliche Redundanzen erzeugen. Für die effektive Wiederverwendbarkeit der IT-Services ist es zwingend erforderlich, dass eine zuverlässige Performance zu jedem Zeitpunkt gewährleistet ist. Die Performance kann nur durch die absolute Kontrolle über alle beteiligten Software- und Hardwarebausteine und durch eine sogenannte 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. In Abbildung 3 werden die wichtigsten Variationen dargestellt. In der Geschäftsdomäne CUSTOMER CONTRACT gibt es zwei vollständig autonome IT-Services in einer eigenen Laufzeitumgebung und Datenbank. Damit die fachliche Integrität des IT-Services sichergestellt wird, erhalten die aggregierten Geschäftsobjektbausteine die exklusive Datenhoheit. Es findet eine sogenannte Zugriffsvertikalisierung statt. Bei den anderen Varianten teilen sich entweder alle Services innerhalb der Geschäftsdomäne PRODUCT MANAGEMENT eine Laufzeitumgebung, oder die Services aus der Geschäftsdomäne ORDER MANAGEMENT segmentieren sich nach ihren Geschäftsfunktionen in Sub-Geschäftsdomänen, und diese teilen sich dann eine Laufzeitumgebung. Dabei ist es erforderlich, dass ein Service exklusive Zugriffsrechte auf die ihm zugeordneten Datenbankobjekte besitzt. Bei hoch konkurrierendem Datenzugriff und dem damit verbundenen Sperren von Datensätzen oder Seiten, kann somit gewährleistet werden, dass die Antwortzeiten von Datenbankabfragen konsistent, konstant performant und vorhersehbar bleiben. Dabei korreliert der Autonomiegrad immer mit dem Grad der Skalierbarkeit. Einerseits sind Unternehmensstandards zum Entwurf von wiederverwendbaren Unternehmensressourcen erforderlich, anderseits müssen Richtlinien den offiziellen und singulären Zugriffspunkt auf die Geschäftslogik, der von ihnen gekapselt ist, über ein zentral verfügbares, fachlich normalisiertes IT-Service-Inventar 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äftslogikbausteine noch weiter verfeinert wird. Analog hierzu 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. 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 die fachliche Dekomposition eines Inventars, wie 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 sogenannte Adapteroder Wrapper-Services gekapselt werden. Die vertikale Entkopplung hat das Ziel, eine beliebige Applikation aus einer Anwendungslandschaft inklusive der zu verwaltenden Daten vertikalisiert herauszulösen und in einer eigenen autonomen, hochgradig skalierbaren Umgebung zu betreiben. Dies ist essentiell wichtig für deren Integration in das serviceorientierte Umfeld. Nur so kann im Umfeld von Orchestrationen, Kompositionen oder der konkurrierenden Benutzung die Seite 7

8 Abbildung 3: Referenzarchitektur für ein serviceorientiertes Integrationsszenario mit Geschäftsausrichtung angestrebte Stabilität, Zuverlässigkeit und Berechenbarkeit zur Laufzeit gewährleistet werden. Die richtige Balance der Service-Enablements von Legacy-Umgebungen kann zu einer wahren Herausforderung werden. Welche Teile der Geschäftslogik wie abstrahiert werden sollen, kann meistens nur in Abhängigkeit von dem darunterliegendem Service-Adapter sowie der damit gekoppelten Legacy-APIs entschieden werden. Dabei ist zu beachten, 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, so dass sich eine isolierte Zugriffskontrolle auf die abstrahierten Fähigkeiten über Wrapper-Services höchst anspruchsvoll gestalten kann. In vielen Fällen erfordert es eine aufwendige, aber lohnende, Entkopplung des gesamten Software-Lebenszyklus, so dass der gesamte Build- und Deploymentprozess einzig für diese Applikationen neu entwickelt werden muss. Aber damit die herauszulösende Applikation überhaupt erst separat gebaut und deployt werden kann, müssen alle direkten und transitiven Abhängigkeiten im Quellcode aufgelöst werden. Das betrifft selbstverständlich auch die Lokalisierung und Auflösung der Zugriffe auf externe Datenbanken und den damit verbundenen Abhängigkeiten auf Datenobjekte sowie die der jeweiligen Daten untereinander. Seite 8

9 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 Sinn für die Gewährleistung der Konsistenz. In diesem Szenario sind Rückreplikationen strengstens verboten. Dieser Mechanismus wurde in Abbildung 3, in der Informationsarchitektur innerhalb der beiden Geschäftsdomänen PRODUCT MANAGEMENT und CUSTOMER CONTRACT, abgebildet. Es ist immer wichtig, 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. Auswirkungen auf die IT- Organisationsstruktur Die IT-Organisationsstruktur basiert häufig auf einer Kombination von Technologien (z. B. Web-Portalen, 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 und neuen aufkommenden IT-Trends und Softwareprodukten ist die Verschiebung der ursprünglichen Strukturen ohne Zweifel ein dauerhaftes Thema. Beispielsweise könnte sich in einem Unternehmen ergeben, dass eine Abteilung für Web-Portale eine Applikation für externe Call-Center 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 Call-Center 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 Know-how zerschlagen. Obwohl Geschäftsprozesse über viele Fachabteilungen laufen und verteilte IT-Systeme längst auf der Tagesordnung stehen, 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 Fokus steht dabei 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 für dessen Budget. Mit einer stärker am Geschäftsmodell ausgerichteten IT-Organisationsstruktur stünden dem Projekt keine künstlich geschaffene IT-Abteilungsgrenzen mehr entgegen. Die klassische technologie- oder produktspezifische Teamstruktur hätte hier keine Zukunft. Doch wie mit Kompetenzteams verfahren? Der Ansatz, mit zentralen Expertenteams (Architekturteam, SOA-Team, IT-Polizei usw.) flächendeckendes Know-how in die Organisation einzusteuern, wird bei vielen Unternehmen praktiziert und führt auch häufig zu Verbesserungen. Im Kern einer solchen Initiative steht jedoch ein angestrebter Kulturwandel und nicht die dauerhafte Etablierung eines Competence Centers. 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 ein 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, Profit-Center 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 diese 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. Im Folgenden werden die in Abbildung 3 vorgestellten Rollen in näher beschrieben: Seite 9

10 Der Process Owner erstellt den eigentlichen Geschäftsprozess. Aus Teilen des Geschäftsprozesses lassen sich IT-Prozesse ableiten, die zusammen mit dem Domain Architect erstellt werden. Der Service Owner ist seitens der Fachabteilung verantwortlich für einen oder mehrere IT-Dienste. Anforderungen an diese IT-Dienstleistungen werden vom Service Owner gesteuert, da nur er weiß, in welchen Prozessen sein IT-Dienst Verwendung findet. Der Service Designer besitzt fachliches und IT-technisches Know-how in seiner Domäne. Dort wird ein konkretes Design angestrebt, das die Grundlage für die Implementierung darstellt. Der Service Designer arbeitet eng mit dem Domain Architect zusammen, der den Überblick über die gesamte IT-Landschaft seiner Domäne besitzt. Vor Abnahme der IT-Prozesse durch den Process Owner ist ein Test notwendig. Für dessen Durchführung ist der Test Manager verantwortlich. Die Domain Architects sind in der Lage, neue Anforderungen der Processund Service Owner zu strukturieren und miteinander abzugleichen. Mit ihrem Domänen-Wissen unterstützen sie den Service Designer und beurteilen die Analyse- und Design-Konzepte inhaltlich und hinsichtlich der Einhaltung von Vorgehensmodellen und Standards. Der Enterprise Architect ist domänenübergreifend aufgestellt und verantwortlich für die Definition und Einhaltung von Standards, Regeln und dem Service-Portfolio der IT. Er konstruiert die strategische Technologie- Roadmap in Zusammenarbeit mit den jeweiligen Domain Architects. Der Governance-Verantwortliche kontrolliert operativ die Einhaltung der Standards, Leitlinien und Prinzipien sowie der daraus abgeleiteten Rollen, Prozesse und Vorgehensmodelle für die Beteiligten. Er ist verantwortlich für die Weiterentwicklung und Pflege der Governance-Prinzipien sowie der daraus abgeleiteten Prozesse und Modelle. Resümee und Ausblick In den frühen Phasen dominierten die technischen Aspekte bei der Integration von Applikationen. Diese stellten basierend auf dem Silomodell statische Funktionalitäten über einem Datentopf zur Verfügung. Wiederverwendung fand über maßgeschneiderte Schnittstellen sowie durch Redundanz auf Code- und Datenebene statt. So entstanden über die Jahre wildwuchsartig 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 sogenannte Business-IT-Alignment. Im Kontext des 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 essentiellen 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 Reorganisation 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 ist 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. Über OPITZ CONSULTING Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Unser Leistungsspektrum umfasst IT- Strategieberatung, individuelle Anwendungsentwicklung, System- Integration, Prozessautomatisierung, Business Intelligence, Betriebsunterstützung der laufenden Systeme sowie Aus- und Weiterbildung im hauseigenen Schulungszentrum. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen. OPITZ CONSULTING wurde 1990 gegründet und beschäftigt heute an acht Standorten mehr als 400 Mitarbeiter. Zu unserem Kundenkreis zählen ¾ der DAX30-Unternehmen sowie branchenübergreifend mehr als 600 bedeutende Mittelstandunternehmen. Seite 10

11 Abbildung 4: Strukturelle Auswirkungen Seite 11