© Ekaphon maneechot/Shutterstock.com
Architekturmanagement: Migrationsschritte zur Servicelandschaft

Architekturmanagement: Migrationsschritte zur Servicelandschaft


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 bezieht sich für seine Einschätzung auf Anne Thomas Manes: „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 Business­orientierung 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...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang