SOA-Transformation

Architekturmanagement: Migrationsschritte zur Servicelandschaft

Kornelius Fuhrer
©Shutterstock/aldorado

Entlang der Evolution der Architektur nimmt auch die Komplexität der Anwendungslandschaften zu, mit der Folge, dass Unternehmen diese oft nur noch schwerlich beherrschen. Eine Umgestaltung der Anwendungslandschaften mithilfe von serviceorientierten Architekturen soll für die nötige Flexibilität sorgen. Doch warum sind diese Versuche häufig zum Scheitern verurteilt? Wir nehmen im Folgenden die Fehlerquellen unter die Lupe und stellen auf den Grundlagen einer erfolgreichen SOA-Transformation Methoden und Prozesse des Enterprise Architecture Managements (EAM) vor.

Welche Transformationsansätze sich in der Praxis am besten bewährt haben und was IT-Entscheider bei der Transformation in eine moderne und nachhaltige Servicelandschaft beachten sollten, und zwar während des laufenden Geschäftsbetriebs und unter Gewährleistung der Business Continuity – all das gilt es zu berücksichtigen, wenn man SOA-Transformation ganzheitlich diskutieren möchte.

Evolution der Architektur

In den ersten Jahren der Anwendungsentwicklung konzentrierten sich Architektur und Design immer nur auf die eine Anwendung. Die damals sehr beliebte „Punkt-zu-Punkt“-Integration wurde „on demand“ als Ad-hoc-Lösung eingesetzt. Mit der Zeit stieg die Anzahl der IT-Anwendungen in vielen Großunternehmen und Konzernen rasant und unkontrolliert an, und es entstanden sehr große Anwendungslandschaften. Entwickler duplizierten und erweiterten neue Schnittstellen, anstatt diese zu konsolidieren und zu integrieren. Aus Unwissenheit über deren Funktionalität blieben die alten Schnittstellen mitsamt ihrer Abhängigkeiten zu anderen Schnittstellen erhalten. Das Resultat: Ein nahezu quadratischer Kopplungsgrad, der die Komplexität über ein vom Menschen verstehbares Maß hinauskatapultiert. Auch das unbeliebte Thema Dokumentation vernachlässigten viele Entwickler und Architekten, deren Wissen auf diese Weise nach und nach mit ihnen selbst verschwand. Änderungen dauerten immer länger und erhöhten zudem die Störanfälligkeit dramatisch. Damit wurde der Anspruch an die Wartbarkeit der Systeme für die IT-Verantwortlichen zum Alptraum. So manche IT-Organisation verlor damit ihre Reputation und das Vertrauen des Fachbereichs und des Managements. Aus reinem Selbsterhaltungstrieb postulierten IT-Entscheider das Mantra „Never Change a Running System“.

Mithilfe von Integrationsplattformen wurde in darauffolgenden Epochen der Architekturevolution durch Message-oriented Middleware (MOM) und Enterprise Application Integration (EAI) zwanghaft versucht, die Anwendungen mittels Messaging loser zu koppeln und damit die Spaghettiarchitekturen aufzulösen. Physikalisch entkoppelt, dafür aber an das Nachrichtenformat gekoppelt, handelte es sich im Wesentlichen immer noch um eine Punkt-zu-Punkt-Integration. Schließlich programmierten die Entwickler weiter auf spezifische Endpunkte hin. Datenreplikation zwischen Anwendungen war die kostengünstigste und damit vorherrschende Integrationsmethode. Aus Gründen der Performance und autonomen Verfügbarkeit schuf man erhebliche Redundanzen innerhalb dieser Daten- und Funktionssilos. In der Natur der Sache lag es, dass sich diese Redundanzen innerhalb der Silos autark weiterentwickelten und zu drastischen Inkonsistenzen führten.

Das darauffolgende serviceorientierte Paradigma löste die Punkt-zu-Punkt-Kopplung durch das Servicekonzept auf. Die produktorientierte Beziehung zwischen Serviceanbieter und -nutzer distanzierte sich von der rein technischen Endpunktintegration.

Zu dieser Zeit stellten internationale SOA-Experten fest, dass die meisten Transformationen fehlschlugen. Thomas Erl äußerte daraufhin die Ansicht, dass viele Architekten das Paradigma hinter SOA nicht verstanden hätten [1]. Nicolai Josuttis formulierte dazu die Aussage: „SOA ist tot! Lang leben Services!“ [2]. Im „SOA Manifesto“ [3] versuchten siebzehn international anerkannte Autoren, die Priorisierungen, Prinzipien und Zielsetzungen von SOA in prägnanter Form zu kommunizieren. Doch welche Gründe waren für die gescheiterten SOA-Transformationsversuche in der Praxis tatsächlich verantwortlich?

In den ersten Jahren glaubten die IT-Organisationen, SOA einfach wie ein Produkt kaufen oder wie einen Standard einführen zu können. Enterprise-Service-Bus-(ESB-)Technologien und Web-Service-Standards dominierten die Themenfelder. Die relevante Businessorientierung wurde von technisch geprägten SOA-Konzepten überschattet. IT-Verantwortliche setzten die essenziellen Business-Needs sehr selten richtig um. Die Folge waren große Irritationen im Business mit erheblichen Vertrauensverlusten gegenüber der IT-Organisation. Das Management musste den Eindruck gewinnen, dass IT zum Selbstzweck betrieben wird, und kürzte in vielen Fällen das IT-Budget.

Um dem entgegenzuwirken, schufen IT-Manager, unterstützt durch kreative IT-Berater, die Illusion von SOA zur Automatisierung von Businessprozessen. Das Kernproblem dabei war, dass keine fachbereichsübergreifende Businessarchitektur mit einheitlichen symbolischen und semantischen Modellen existierte. Während eine Businesseinheit ihre Konzepte in Word erstellte, arbeiteten andere in Word, PowerPoint, ARIS oder UML. Diese redundant-heterogene Beschreibung der lokalen und zuweilen abgeschotteten Businesssilos macht die Identifikation von unternehmensweiten, wiederverwendbaren und damit rentablen Services für eine prozessorientierte SOA unmöglich.

Eine Kombination aus den zuvor genannten Erkenntnissen gipfelte in blindem Vertrauen der Architekten in einem All-in-one-SOA-Produkt. Sie waren davon überzeugt, dass alles, was man brauche, bereits im SOA-Produkt enthalten sei – und dass das auch für alles gelte, was man nicht brauche. Auf der architektonischen Ebene herrschte das Anti-Entwurfsmuster „Goldener Hammer“ vor, bei dem man nach dem Motto: „Man gebe mir einen Hammer, und alles sieht aus wie ein Nagel“ vorging. Gleichzeitig erwachten Erinnerungen an die EAI-Plattformen.

Über den gesamten Zeitraum hinweg vergaß man in den Konzepten immer wieder den Menschen bzw. den Mitarbeiter. Viele Gestalter von SOA-Transformationen schenkten auch dem wichtigen Thema Veränderungsmanagement zu wenig Beachtung. Hintergrund ist sicherlich, dass durch eine ernstgemeinte SOA-Initiative auch Verantwortlichkeiten und Verantwortlichkeitsbereiche verschoben oder sogar Zuständigkeiten aufgelöst werden. Daher fürchten viele IT-Manager um ihre Befugnisse, wenn sie die Art und Weise ihrer Projektführung verändern. Letztlich erklärt das auch, warum viele Betroffene an dieser Stelle innehalten und sich mit einem Blick auf die Historie unsicher sind, ob sie für SOA vieles von dem riskieren sollen, was sie bisher erreicht haben.

SOA-Transformationsszenarien

Das erste Transformationsszenario beschreibt die Integration von Standardprodukten. Dies kann gestaffelt für Teile oder für die gesamte Servicelandschaft erfolgen. Die vollständige Auslagerung und Nutzung von externen Standardservices (SaaS) ist dabei die extremste Variante. Standardprodukte im Umfeld von Human Resources, Enterprise Resource Planning und Customer Relations Management sind die gängigsten Kandidaten.

In den meisten Unternehmen ist das Kerngeschäft recht speziell. Die Anforderungen an ein Standardprodukt werden dann sehr schnell hoch komplex, und Support und Customizing der Standardprodukte dauern in der Praxis zu lange. Das hemmt Agilität und Flexibilität, die essenziell sind, um mit dem rasanten Tempo auf dem globalisierten Weltmarkt mithalten zu können.

In allen Variationen kann IT-Architektur nicht in einem Rutsch ausgetauscht werden. Standardprodukte müssen integriert oder ausgelagert sowie Altanwendungen sukzessive entkoppelt und abgeschaltet werden. In der Regel übersteigen diese Kosten die ursprünglich kalkulierten Einführungs- und Lizenzkosten um ein Vielfaches!

Das zweite Transformationsszenario beschreibt die Entwicklung der gesamten Servicelandschaft, parallel zur bestehenden Anwendungslandschaft „auf der grünen Wiese“. Dieser Ansatz sieht vor, die gesamte Altanwendungslandschaft mit all ihren Unzulänglichkeiten und veralteten Technologien auf einen Schlag („Big Bang“) zu ersetzen. Dabei müssen folgende Punkte bedacht werden:

  • Bei optimistischer Schätzung kann so ein Projekt fünf Jahre und länger dauern.
  • Während der Entwicklungsphase muss die Organisation zwei IT-Architekturen parallel verwalten. Das betrifft die Konzeption, die Entwicklung, den Test und die Wartung.
  • Alle Geschäftsanforderungen müssen parallel in zwei IT-Architekturen mit unterschiedlichen Architekturen, Methoden, Prinzipien, Technologien und Werkzeugen implementiert werden.
  • Auf den Projekten lastet ein enormer Druck, da mehrere Jahre Stillstand für das Business auch aus Kostensicht eine Katastrophe sein können.

Eine Variante der „Grüne-Wiese“-Transformation ist die forcierte Transformation, die eine Transformationsdauer von weniger als zwei Jahren vorsieht. Diese erfordert einen sehr hohen Kosten- und Ressourceneinsatz. Doch nur sehr wenige Konzerne haben diesen Ansatz erprobt und erfolgreich durchgeführt. Managed Evolution stellt hingegen den Königsweg der Transformationsszenarios dar und folgt dabei diesen Grundsätzen:

  1. Die bestehenden Systeme sind das investierte Vermögen eines Unternehmens.
  2. Geschäftlicher Mehrwert wird kontinuierlich geliefert.
  3. Agilität und Qualität der Architektur werden durch jedes IT-Projekt gesteigert.
  4. Der Managed-Evolution-Transformationsprozess endet nie.

Abbildung 1 zeigt die Entwicklung einer Architektur im Istzustand hin zur Zielarchitektur im Sollzustand. Demzufolge muss jedes Projekt etwas zur Qualität der Architektur beitragen und einen geschäftlichen Mehrwert erbringen. In der Praxis hat sich ein Verhältnis von 70:30 als sehr sinnvoll erwiesen. Der Evolutionskorridor begrenzt dabei den Werteraum der beiden Indikatoren. Damit sind keine radikalen Änderungen durch risikoreiche Projekte notwendig, um die Servicelandschaft in einen qualitativ hochwertigen Zustand zu befördern.

Abb. 1: Managed-Evolution-Transformation

Die Pfeile im Koordinatensystem, die leicht nach oben gerichtet sind, machen deutlich, dass ein Projekt einen Beitrag zur Qualität der Architektur in Richtung Zielarchitektur liefert und die erforderlichen Geschäftsanforderungen innerhalb des eigenen Projekt-Scopes umsetzt. Nach unten gerichtete Pfeile sind hingegen ein Indikator für massive Störungen. Diese Projekte verschlechtern die Qualität der Architektur. Architekturprogramme und -projekte können über Pfeile, die senkrecht nach oben zeigen, dargestellt werden.

Die Zielarchitektur beschreibt einen sehr beweglichen Sollzustand und lässt den Transformationsprozess praktisch nie enden. Projekte müssen dem Strategy- und Value-Management in einem sehr frühen Stadium Planarchitekturen zum Review zur Verfügung stellen, sodass die Konformität zur Zielarchitektur gewährleistet ist. Zusätzliche Governance-Prozesse zu unterschiedlichen Phasen im Projektlebenszyklus überprüfen fortlaufend die Konformität zur Zielarchitektur und sichern somit die Qualität und Nachhaltigkeit der Lösungen.

Der essenzielle Erfolgsfaktor für jedes Transformationsszenario sind passgenaue Architekturmanagementprozesse. Sie stellen fortlaufende Agilität und Qualität der Architektur sowie die Konformität zu strategischen Zielen bei der Erbringung von geschäftlichem Mehrwert sicher. Welche Strukturen, Methoden und Prozesse dazu im Detail erforderlich sind, veranschaulichen die folgenden Abschnitte.

Aufmacherbild: Service with a Smile von Shutterstock / Urheberrecht: aldorado

[ header = Architekturmanagement ]

Architekturmanagement

Jedes Unternehmen verfügt über eine Architektur, die entweder implizit oder explizit vorhanden ist. Eine implizite Architektur, die den Stakeholdern nicht wirklich bewusst ist, macht Kontrolle, Kommunikation und strategische Weiterentwicklung schwierig. Gelingt es, die Architektur in unternehmensweit abgestimmte Strukturen aufzuteilen, entstehen Transparenz und Verständnis. Darauf aufbauend helfen die folgenden Methoden und Prozesse bei der zielgerichteten Steuerung der SOA-Transformation.

IT-Bebauungsmanagement – Die strategische Planung der SOA-Transformation

Langfristige Ziele erfordern grobgranulare Bebauungspläne. Für Anforderungen und Maßnahmen, die über Projekte umgesetzt werden, ist jedoch eine feinere Granularität der Perspektive zweckmäßig. Aus diesem Grund findet eine Unterscheidung in operative, taktische und strategische Bebauungspläne statt. Während der operative Bebauungsplan die Istarchitektur visualisiert, beschreibt der strategische Bebauungsplan die Zielarchitektur in drei bis fünf Jahren. Über viele feingranulare, konsistente und projektspezifische Planarchitekturen steuert und dokumentiert der taktische Bebauungsplan die Transformation zur Zielarchitektur in Form einer Jahres- oder Halbjahresplanung.

Im oberen Kasten in Abbildung 2 sind drei Klassen von Bebauungsplänen zu sehen. Die vertikale Achse beschreibt grobgranulare Business Capabilities für Architekturen im Ist- und Sollzustand. Zusätzlich werden die dekomponierten fachlichen Funktionen für feingranulare Planarchitekturen angezeigt. Analog dazu stellt die horizontale Achse diese Angaben für Businessprozesse und feinere Subprozesse dar. Während die Achsen Architekturelemente aus der Businessarchitektur zeigen, benutzt der Fülltyp Anwendungen, Komponenten und Services, die der Anwendungs- bzw. Servicearchitektur zugeordnet sind.

Abb. 2: Strategische Planung der SOA-Transformation

Der untere Kasten in Abbildung 2 zeigt eine strategische Roadmap für die gesamte SOA-Transformation. Die Roadmap gewährleistet, dass Projektplanarchitekturen nachverfolgt und gesteuert werden können. Nur so lassen sich Auswirkungen der Planarchitekturen auf die Zielarchitektur effektiv abbilden. Kurzum: Die strategische Roadmap ist ein wichtiges analytisches Instrument für jede SOA-Transformation. In Kombination mit Bebauungsplänen werden die Abhängigkeiten von jedem strategischen Ziel auf der höchsten Ebene über operationalisierte Ziele der Projekte und Anforderungen bis auf die tiefste Ebene der betroffenen Anwendungen und Services transparent.

Architekturprozesse

Architekturprozesse adressieren die strategische Steuerung der SOA-Transformation, die operativ über feingranulare Planarchitekturen aller Projekte und Programme zur Zielarchitektur führen. Das Verzahnen der dargestellten Prozesse geschieht über das umfassende Architekturmanagement. Auf dieser Basis wird die SOA-Transformation so gesteuert, dass beispielsweise nur Altanwendungen in Services transformiert werden, die zukunftsfähige oder geschäftskritische Business Capabilities und Businessfunktionen unterstützen.

Abb. 3: Architekturprozesse

Abbildung 3 illustriert das Zusammenspiel der elementaren EAM-Prozesse, das folgendermaßen beschrieben werden kann:

  • Prozesse wie das Demand Management helfen beim fachbereichsübergreifenden Erfassen, Analysieren, Priorisieren und Bewerten der Anforderungen sowie deren Ausrichtung an der Business- und IT-Strategie.
  • Das Project Portfolio Management gewährleistet die überschneidungsfreie Bündelung dieser Anforderungen und die Zuordnung zu klar definierten Projekten sowie die termingerechte Einhaltung des Projektplans. Die Klassifizierung der Projekte entlang der Indikatoren geschäftlicher Mehrwert, Strategiekonformität, Compliance und Betriebsrisiken sowie deren Beitrag zur Zielarchitektur helfen Entscheidern, die zu steuernden Projekte zu evaluieren und zu managen und die daraus gezogenen Schlussfolgerungen zu kommunizieren.
  • Das Strategy und Value Management prüft die eingereichten Planarchitekturen der Projekte entsprechend ihrer Konformität zur Zielarchitektur bzw. der Vorgabe der aktuellen Transformationsphase. Dabei wird auch die Einhaltung von Architekturprinzipien, -standards und -mustern genau verifiziert.
  • Das Solution Architecture Management ermöglicht sowohl detaillierte Analysen der Ist- und Planarchitekturen als auch den Vergleich von Lösungsszenarien und Business-Cases für definierte Projekte sowie die Bereitstellung von bewährten Architekturmustern und Referenzarchitekturen.
  • Ausgerichtet an den strategischen Architekturstandards macht das Architecture Management Vorgaben für die Lösungsentwicklung. Hier werden Architekturelemente wie Capabilities, Service-Eco-Systeme und Standardplattformen über den gesamten Lebenszyklus verwaltet.

Die größten Zielkonflikte bestehen zwischen dem operativen Projektmanagement mit Fokus auf geringen Kosten und dem strategischen Architekturmanagement mit Fokus auf Qualität und Nachhaltigkeit. Die Transformationsmethode „Managed Evolution“ berücksichtigt diesen Umstand und transformiert die Projekte entlang des strategischen Evolutionskorridors in Richtung Zielarchitektur. In der Praxis bewährte Governance-Institutionen, wie das Project Review Board, bewerten die erzielten Projektergebnisse hinsichtlich ihrer Architekturqualität und ihres Beitrags zum Erreichen der Zielarchitektur jeder Lebenszyklusphase.

Die definierten Architekturstandards und -prinzipien aus dem Strategy- und Value-Management werden mittels Governance über Rollen, Policies, Prozesse etc. weiter verfeinert und in den Projektmanagementprozess integriert. In der Praxis führen Governance-Verantwortliche frühzeitig und fortlaufend Reviews und Messungen entlang des Projektmanagements durch, um die Standardkonformität in Projektergebnissen zu prüfen und nachzuhalten.

Um die Ziele der SOA-Transformation zu erreichen, wie beispielsweise die businessorientierte Gestaltung der Architektur, werden projektspezifische Planarchitekturen im Architekturmanagement immer wieder mit den Vorgaben zum Erreichen der Zielarchitektur im Sollzustand abgeglichen. In der Praxis steigt dabei die Sicherheit in der Projektplanung, denn deren Planungskontext umfasst neben den Informationen der Istarchitektur auch die der Planarchitekturen aller Projekte. Businessanalysten und Projektleiter können Inkonsistenzen oder Kollisionen von Anforderungen paralleler Projekte schon zu einem sehr frühen Zeitpunkt, nämlich bereits im Demand-Management-Prozess, identifizieren und korrigieren.

Resümee

Die IT-Evolution hat in allen Epochen ohne businessorientierte Selektion stattgefunden. Bei den meisten SOA-Transformationsversuchen umfasste die Evolution ausschließlich das Ökosystem der IT. Immer wieder überschatteten technische Strategien die konsequente Lieferung des geschäftlichen Mehrwerts. Die IT-Organisation hat sich mit dem Ziel, die gesamte Architektur von unten heraus zu transformieren, maßlos überschätzt.

Die bestehende Architektur mit der über Jahre angereicherten Funktionalität repräsentiert die Investitionen vom Business in die IT. Diese Investitionen dürfen ebenso wenig als Altlast angesehen werden wie das Know-how der Mitarbeiter. Die Transformationsmethode „Managed Evolution“ berücksichtigt diesen Umstand mit ihrem kontinuierlichen Vorgehen und verhindert dabei die Erosion der Architektur. Projektweise werden dabei neben dem wichtigen geschäftlichen Mehrwert auch die Qualität und Agilität der Architektur erhöht.

Der strategische Evolutionskorridor stellt die nötigen Leitplanken für die SOA-Transformation bereit. Mithilfe von Roadmaps und Bebauungsplänen werden sowohl die Vorgaben als auch der Status der Umsetzung transparent gemacht und nachgehalten. Des Weiteren sind sie ein zuverlässiges Ergebnis für das IT-Projekt. Auswirkungen und Zusammenhänge zwischen Business- und IT-Architektur werden durch Bebauungspläne ebenso transparent wie Beziehungen zu den entsprechenden Projekten. Entscheidungen können auf dieser Basis aus aktuellen, zuverlässigen Informationen schnell und valide getroffen und abgesichert werden. So wird mehr Sicherheit in der strategischen und operativen Planung der SOA-Transformation geschaffen, und gravierende Planungsfehler mit gegebenenfalls großer Tragweite können vermieden werden.

In diesem Kontext bedeutet Effektivität, dass nur die richtigen Projekte umgesetzt werden. Mithilfe der Prozesse des Enterprise-Architecture-Management sind Unternehmen in der Lage, strategische Transformationsziele entlang der Strategy-, Value-, Projektportfolio- und Managementprozesse zu operationalisieren. Effizienz hingegen bedeutet, dass die Projekte richtig umgesetzt werden. Hier greifen die Prozesse des Demand-, Architektur- und Projektmanagements sowie Governance-Prozesse nahtlos ineinander und stellen sicher, dass die Projektergebnisse den Geschäftsanforderungen entsprechen, dabei die Architekturstandards und -prinzipien zur Bewahrung der Agilität eingehalten werden und die Zielarchitektur erreicht wird.

Das Architekturmanagement dient als Fundament für die nächsten Schritte: die „Business SOA“ und die „Technische Integration“ der SOA-Transformation. Lesen Sie zu diesen einen weiterführenden Beitrag in der nächsten Ausgabe.

Geschrieben von
Kornelius Fuhrer
Kornelius Fuhrer
Kornelius Fuhrer ist Senior Consultant bei OPITZ CONSULTING und unterstützt Kunden bei der IT-Planung und der Umsetzung von Strategien und Initiativen. Er verfügt über Erfahrungen in klassischen Integrationsprojekten und im Aufbau komplexer SOA. Besonders interessiert ihn die Konzeption von rentablen, nachhaltigen Referenzarchitekturen und die geschäftsorientierte Gestaltung von IT-Anwendungslandschaften. Als Speaker auf Konferenzen und Autor von Artikeln berichtet er regelmäßig zu Themenkomplexen aus IT-Governance, Business IT Alignment, EAM und SOA.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.