Service-Oriented Architecture: SOA - ein Konzept ist noch nicht begraben Detail - Computerwelt

Computerwelt: Aktuelle IT-News Österreich


02.06.2011 Dr. Peter Mandl*

Service-Oriented Architecture: SOA - ein Konzept ist noch nicht begraben

Um den Begriff Service-orientierte Architektur ist es ruhig geworden, nicht zuletzt wegen des Scheiterns einiger allzu ganzheitlich angelegter Großprojekte. Lesen Sie fünf Thesen, weshalb ein Vorgehen in kleinen Schritten sinnvoll ist.

SOA wurde in den letzten Jahren zum Inbegriff wohldefinierter verteilter Architekturen und als die Lösung für die Entwicklung und Weiterentwicklung komplexer IT-Architekturen gehandelt. Zahlreiche Unternehmen haben SOA-Projekte initiiert und dabei teilweise gute, aber auch weniger gute Ergebnisse beziehungsweise Zwischenergebnisse erzielt. Im jüngsten Gartner Hype Cycle für Emerging Technologies ist der Begriff SOA nicht mehr zu finden. Hat sich das Konzept nun etabliert oder nicht? In der Gartner-Terminologie würde man fragen, ob sich SOA auf dem "Plateau of Productivity" befindet, oder ob das Konzept als "obsolete before Plateau" einzustufen ist.

Eines ist jedenfalls sicher: Es gibt keinen Königsweg für SOA, jedes Unternehmen muss unter Berücksichtigung der eigenen Anwendungslandschaft einen individuellen Weg finden, Service-orientierte Prinzipien einzuführen. Zwei Ansätze werden dabei diskutiert.

Die radikalste Einführungsvariante setzt eine umfassende Dekomposition der bestehenden Anwendungssysteme voraus. Services, die in verschiedenen Anwendungssystemen genutzt werden, stellt man zentral bereit und entwickelt sie in einer zentralen Organisationsinstanz weiter. Jedes einzelne Anwendungssystem muss dafür unter Beachtung einer Gesamtarchitektursicht genau analysiert werden. Das erwartete Ergebnis dieser sehr langwierigen Vorge-hensweise ist ein zentraler Service-Pool im Unternehmen sowie Anwendungssysteme, die weitgehend redundanzfrei sind und zentrale Services in der Regel über einen Service-Bus nutzen. Aufgrund des enormen Aufwands stellen sich natürlich mehrere Fragen zur Sinnhaftigkeit eines derart rigorosen Ansatzes: Kann man so lange im Voraus planen? Wie lässt sich eine Dekomposition alter Anwendungen am besten angehen? Wie soll der Service-Pool innerhalb des Unternehmens organisiert werden? Sind ein neuer Engpass und noch komplexere Abhängigkeiten zu befürchten? Fragen, die sich nicht ohne weiteres beantworten lassen.

Eine gemäßigtere Vorgehensweise ist die Einführung einer partiellen SOA. Hierbei erfolgt keine komplette Zerlegung der Anwendungssysteme in Komponenten, sondern nur eine partielle "Absenkung" von Services in einen zentralen Service-Pool. Nur die wichtigsten Services werden aus den Anwendungssystemen herausgezogen. Letztere bieten zudem bei Bedarf eine eigene Serviceschnittstelle für Funktionen, die nur wenige andere Anwendungssysteme benötigen. Die technische Kommunikation könnte ebenfalls auf einen Service-Bus umgestellt werden. Doch auch hier treten ähnliche Fragen wie in der ersten Variante auf, allerdings scheint das Ziel einer partiellen SOA-Einführung im Rahmen einer sanfteren Migration eher erreichbar zu sein.

ÜBERTRIEBENE ERWARTUNG UND KRITIK Nicht zuletzt aufgrund dieser Fragen löst der Begriff SOA inzwischen oft kritische Reaktionen aus, die genauso übertrieben sind wie die ursprünglichen Erwartungen. Erkenntnisse und Erfahrungen aus SOA-Projekten sollten hinterfragt werden, um festzustellen, ob das Konzept weiter empfohlen werden kann. Dabei können fünf Thesen helfen, die wir aus der Beobachtung mehrerer Projekte abgeleitet haben.

These 1: Die komplette Dekomposition bestehender Anwendungssysteme im Sinne von SOA ist für die meisten Unternehmen so gut wie unmöglich. Diese Behauptung zielt vor allem auf die oben beschriebene erste SOA-Umsetzungsvariante ab. Sie ist vor allem für größere Anwendungslandschaften nicht realisierbar. Eine vollständige Dekomposition von Anwendungssystemen würde einen immensen Aufwand verursachen, der nicht im Verhältnis zum Nutzen steht. Der Grund liegt in erster Linie darin, dass manche Altsysteme nur noch sehr schwer zerlegbar sind. Sie müssten mit riesigem Aufwand in Komponenten strukturiert werden, zentrale Services müssten identifiziert und über einen Service-Bus wieder in die bestehenden Systeme integriert werden, ohne dass dies funktionale Verbesserungen zur Folge hätte. In einer typischen Anwendungslandschaft eines größeren Unternehmens oder einer größeren Organisation würden die IT-Abteilung und auch die zuarbeitenden Fachabteilungen über Jahre stark belastet.

These 2: Der Ansatz der Zentralisierung von Services erhöht die Abhängigkeiten im Unternehmen oder bringt zumindest neue mit sich. Wenn man es schafft, in einer IT-Anwendungslandschaft einen zentralen Service-Pool einzurichten, muss dieser auch weiterentwickelt werden. Änderungen in zentralen Services haben aber möglicherweise weitreichende Folgen, weil davon gegebenenfalls viele Anwendungssysteme betroffen sind. Schließlich ist ja die Verwendung zentraler Services von vielen Anwendungen das Ziel. Damit hat die Änderung an der Schnittstelle eines Service eine Anpassung aller nutzenden Anwendungssysteme zur Folge. Erst nach dieser Anpassung kann eine Änderung in Betrieb gehen. Das setzt aber zwangsweise einen hohen Testaufwand voraus. Der Preis einer übertriebenen Zentralisierung ist also eine erhöhte Komplexität bei Änderungen in den Services. Die Auswirkungen sind unter Umständen immens.

These 3: Eine komplette SOA-Einführung in großen Unternehmen dauert zu lange und führt deshalb nicht zum Erfolg. SOA-Einführungen im großen Stil dauern sehr lange. Zehn bis 20 Jahre sind gerade in umfangreichen Anwendungslandschaften nicht ungewöhnlich. Echte Erfahrungswerte für eine SOA-Komplettumstellung kann es deshalb heute noch gar nicht geben. IT-Projekte über eine derart lange Laufzeit sind unsicher, ihre Planung fast unmöglich. Selbst ein überzeugter CIO stößt hier auf große Widerstände. Die Wahrscheinlichkeit ist groß, dass er das Projekt nach einiger Zeit an die nächste Manager-Generation übergeben muss, welche die bisherige Strategie grundsätzlich in Frage stellt und verändert.

Vor allem die Fachabteilungen profitieren zunächst gar nicht von SOA, da die funktionale Weiterentwicklung zunächst in den Hintergrund rückt. Sobald der Druck der Kunden beziehungsweise Anwender steigt, verliert die Idee einer sauberen Architektur wieder an Bedeutung. In vielen Unternehmen, die ihren Kunden kontinuierliche Fortschritte in der Anwendungsfunktionalität versprechen, ist es schon heute schwierig, technische ohne fachliche Verbesserungen durchzusetzen.

These 4: Im Unternehmen auf eine SOA-Organisation umzustellen ist schwer und wird enorme interne Widerstände auslösen. Die Einführung von zentralisierten Services erfordert eine Neustrukturierung im Unternehmen. Eine neue Unternehmensinstanz (Abteilung, Bereich) muss für die Entwicklung und Pflege des Service-Pools verantwortlich sein. Diese Aufgabe erfordert sowohl fachliche als auch technische Fertigkeiten. Änderungen in den Services müssten immer mit der neuen Instanz abgestimmt werden und ließen sich nur umsetzen, wenn die Anwendungssysteme die neuen Serviceversionen auch einbinden. Für die Verantwortlichen der Anwendungssysteme geht diese Maßnahme möglicherweise mit einem Kompetenzverlust einher, was zu schwerwiegenden Akzeptanzproblemen führen kann.

Hinzu kommt, dass neue Stabsinstanzen in der klassischen Art oft mehr Probleme mit sich bringen, als sie lösen. Einige oft missglückte Ansätze der Vergangenheit wie die Einrichtung übergreifender Architektur-Boards und Datenmodellierungsinstanzen (Stichwort: unternehmensweites Datenmodell) bestätigen dies.

Diesen Artikel

Bewertung:

Übermittlung Ihrer Stimme...
Noch nicht bewertet. Seien Sie der Erste, der diesen Artikel bewertet!
Klicken Sie auf den Bewertungsbalken, um diesen Artikel zu bewerten.
  Sponsored Links:

IT-News täglich per Newsletter

E-Mail:
Weitere CW-Newsletter

CW Premium Zugang

Whitepaper und Printausgabe lesen.  

kostenlos registrieren

Aktuelle Praxisreports

(c) FotoliaHunderte Berichte über IKT Projekte aus Österreich. Suchen Sie nach Unternehmen oder Lösungen.

Service

Acceptance Testing: Trotz knapper Ressourcen

Zum Thema

  • customer care solutions - Call Center Betriebs GmbH

    customer care solutions - Call Center Betriebs GmbH B2C Dienste und Lösungen, B2B Dienste und Lösungen, User Helpdesk-Systeme und Hotlines, Systempflege- und Wartung, Outsourcing, IKT-Consulting, Facility Management,... mehr
  • MIC – managing international customs & trade compliance

    MIC – managing international customs & trade compliance Supply Chain Management, Kaufmännische Software (ERP), Expertensysteme, E-Procurement und Supply Chain Management, B2B Dienste und Lösungen mehr
  • Rittal GmbH

    Rittal GmbH Netzwerk-Management, Netzkomponenten, Zugangs- und Zutrittskontrolle, Unterbrechungsfreie Stromversorgung (USV), Überwachungssysteme, Notfalls-Rechenzentren, Netzwerk- und Systemüberwachung,... mehr
  • HATAHET productivity solutions GmbH

    HATAHET productivity solutions GmbH Individual-Softwareentwicklung, Migrations-Management, Programmierung, System- und Netzwerk-Tuning, Systemintegration und Systemmanagement, Übernahme von Softwareprojekten, User Helpdesk-Systeme und Hotlines,... mehr

Hosted by:    Security Monitoring by: