SOA 2.0 - zu schnell für die Anwender?

19.06.2006
Während die IT-Branche mit SOA 2.0 schon den nächsten Hype herbeiredet, entdecken Anwender, wie schwer sich Service-orientierte Architekturen verwalten lassen.
Gartner bringt das neueste IT-Buzzword auf eine einfache Formel: SOA 2.0 kombiniert herkömmliche Ansätze der Serviceorientierung mit einer ereignisorientierten Verarbeitung (Event Driven Architecture).
Gartner bringt das neueste IT-Buzzword auf eine einfache Formel: SOA 2.0 kombiniert herkömmliche Ansätze der Serviceorientierung mit einer ereignisorientierten Verarbeitung (Event Driven Architecture).

Von "Real World SOA" oder "SOA in Action" ist auf einschlägigen Veranstaltungen oft zu hören, wenn es um konkrete Vorhaben geht. Dass dabei eher dröge Projektpläne, Roadmaps oder Milestones eine zentrale Rolle spielen, liegt in der Natur der Sache, ist für die Veranstalter aber doch nur die halbe Miete. Sie wollen mehr bieten und lassen deshalb stets Experten einen Blick in die Zukunft werfen. Auch die Gartner-Konferenz zum Thema Application Integration und Web-Services vergangene Woche folgte diesem Muster. Bevor die aus ganz Europa nach Barcelona angereisten Fachbesucher der ersten SOA-Fallstudie lauschen durften, präsentierten Analysten schon mal die nächste Generation des Designkonzepts: "SOA 2.0" oder auch "Advanced SOA".

Hier lesen Sie …

Mehr zum Thema

www.computerwoche.de/

576477: Oracle beschreibt The Next Application Platform;

574943: SOA treibt das intelligente Unternehmen;

574933: Die besten Tools zur SOA-Verwaltung.

In der Diktion der Gartner-Experten verbirgt sich dahinter eine Kombination aus Service-orientierten Designkonzepten und einer Softwarearchitektur, die Ereignisse (Events) in Echtzeit entdeckt. Letzteres erfordere eine Event Driven Architecture (EDA), erläuterte Gartner-Analyst Paolo Malinverno. Sie soll nicht nur einzelne Events wie beispielsweise einen Auftrags- oder Zahlungseingang erkennen sondern ganze Ereignisströme erfassen und interpretieren können. Möglich werde dies durch Softwarewerkzeuge für das Complex Event Processing (CEP). Mit ihrer Hilfe könnten Unternehmen eine Art Radarsystem aufbauen und mit Regeln versehen. Auf eine einfache Formel gebracht, lautet die Definition des neuen Paradigmas: SOA 1.0 + EDA = SOA 2.0 (siehe Grafik "SOA im Kontext der IT-Gechichte").

Ganz neu ist die Idee nicht. Unter dem Schlagwort "The Next Application Platform" hatte auch Oracle kürzlich seine Vorstellung von SOA 2.0 präsentiert. Demnach muss sich zur Serviceorientierung derzeitiger Lösungen eine ausgeprägte Ereignisfähigkeit in Form von Realtime-Komponenten gesellen. Die zeitnahe Reaktion auf Ereignisse habe in einer SOA oberste Priorität, erklärte Oracle-Manager Thomas Kurian auf Suns Entwicklerkonferenz JavaOne im Mai. Als Anwendungsbeispiel nannte er unter anderem die Überwachung von Lieferketten, wo Störungen im Warenfluss eine sehr schnelle Reaktion erforderten.

Killerapplikationen

Gartner zählt zu den potenziellen Killerapplikationen für SOA 2.0 unter anderem den Echtzeithandel in der Finanzbranche, die Verwaltung von RFID-Netzen oder auch die Betrugserkennung. Anhand typischer Transaktionsmuster ließen sich mit Hilfe von CEP beispielsweise Kreditkartenbetrüger aufspüren. Herkömmliche Werkzeuge für Business Intelligence (BI) griffen in solchen Szenarien zu kurz, erläuterte Gartner-Analyst Roy Schulte: "Event-Processing-Tools können Muster erkennen, die traditionelle Werkzeuge nicht sehen." Insofern sei Complex Event Processing auch als natürliche Erweiterung von BI zu verstehen.

Standards fehlen

Doch der Weg dorthin ist weit. Im Gegensatz zur klassischen Sicht auf Geschäftsprozesse, wo sich BPEL als Standard durchgesetzt hat, existiert für Event Processing noch keine einheitliche Sprache, wie Schulte einräumte (BPEL = Business Process Execution Language). Einschlägige Web-Services-Standards wie WS-Eventing sind Mangelware. Vor diesem Hintergrund verwundert es nicht, dass ereignisgetriebene Verarbeitung in den SOA-Projekten von Unternehmen kaum eine Rolle spielt. Vielmehr kristallisiert sich in größeren Installationen ein ganz anderes Problem heraus: Mit jedem zusätzlichen Softwareservice steigt die Komplexität des Gesamtsystems und damit die Notwendigkeit, Governance-Strukturen einzuziehen.

"Mangelnde Governance ist der Hauptgrund für Fehler in SOA-Projekten", fasste Malinverno seine Erfahrungen aus Beratungsgesprächen zusammen. Ohne Governance sei die vielzitierte Wiederverwendbarkeit (Reuse) von in Software gegosssenen Business-Services nicht zu erreichen. Ohne Reuse wiederum blieben die eigentlichen SOA-Vorteile wie Flexibilität, Agilität und Kostenreduzierung aus. Malinvernos Kollege Michael Barnes verwies in diesem Zusammenhang auf eine ganze Reihe von Problemen, die erst nach dem Aufbau einer SOA zutage träten. So bereite es häufig Schwierigkeiten, die im Unternehmen verstreuten Softwareservices zu finden und Duplikate zu vermeiden. Ohne eine ausgefeilte Versionskontrolle der Komponenten könnten schnell "Legacy SOA Systems" entstehen. Zudem stellten sich in SOA-Projekten auch klassische IT-Governance-Probleme: Wem gehört eine Transaktion oder ein entsprechender Service? Wer ist für deren Funktionsfähigkeit - Stichwort Quality of Service (QoS) - verantwortlich? Zu den zahlreichen Hürden zählt Barnes auch die unzureichende Kompetenz vieler Mitarbeiter in Sachen Integration.

SOA Competence Center

Unternehmen mit größer angelegten SOA-Plänen sollten derartige Probleme auf zwei Wegen angehen, empfehlen die Gartner-Experten. Zum einen gelte es, die Verwaltung über dedizierte Organisationen wie ein Integration Center oder ein SOA Competence Center zu institutionalisieren. Zum anderen erforderten SOA-Projekte, wenn sie sich auf mehr als einige wenige Services ausdehnten, Governance-Tools in Form einer zentralen Registry. Nach Einschätzung von Gartner-Analyst Frank Kenney bilden solche Tools den Kern einer jeden SOA-Installation: "Ohne Registry wird die SOA scheitern." IT-Hersteller hätten diesen Bedarf erkannt und präsentierten mittlerweile eine breite Palette von "Independent" Registries. Damit entstehe ein neuer Markt, in dem sich kleine Spezialanbieter wie Infravio, Flashline oder Systinet ebenso Chancen ausrechneten wie die Branchengrößen.

Wie sich umfangreiche SOA-Projekte organisatorisch stemmen lassen, veranschaulichte der italienische Autofinanzierer Fiatsava. Als Spinoff des Fiat-Konzerns nutzt das Unternehmen Cobol-Awendungen für seine Kernprozesse, insgesamt rund 3,4 Millionen Codezeilen.

SOA in der Finanzbranche

Ziel des SOA-Vorhaben sei es einerseits gewesen, Produkte schneller auf den Markt zu bringen, verschiedene Vertriebskanäle zu bedienen und Kosten zu senken. Andererseits wollten die Verantwortlichen Investitionen in die bewährte Legacy-Software schützen. Unter diesen Prämissen entstand eine Kombination aus gekapselten Services der Altsysteme und neu entwickelten Komponenten. Die so entstandenen rund 70 Business Services würden mehrfach von bis zu vier Anwendungen genutzt, so IT-Managerin Antonia Casamassima. Das Governance-Problem wollen die Italiener mit zwei Gremien in den Griff bekommen: einem Analysis-Pool, in dem ausschließlich Buiness-Analysten sitzen, und einem SOA-Management-Pool. Letzterer kümmert sich beispielsweise um die Verwaltung der Services Registry, so Casamassima. Erfolgsentscheidend sei auch gewesen, dass das Softwareentwicklungs-Team von der Verwaltungseinheit getrennt arbeite.

Governance braucht Disziplin

"Beim Thema Governance geht es um Disziplin", kommentierte Gartner-Analyst Massimo Pezzini. "Es kann keine völlige Freiheit für Softwareentwickler geben." Andernfalls drohe eine Art Wildwest-SOA, die niemand mehr kontrollieren könne. Nach seiner Einschätzung wird bis zum Jahr 2010 nur ein Viertel der Betriebe die technischen und organisatorischen Fähigkeiten besitzen, um eine unternehmensweite SOA aufzubauen. Die Vorstellung einer einzigen großen SOA hält er ohnehin für unrealistisch: In der "Real World SOA" der Zukunft interagierten mehrere SOA-Inseln über ein gemeinsames Enterprise Backplane.