Gegenwärtig nutzen insbesondere Behörden in Westeuropa, Bildungseinrichtungen und Organisationen aus dem Gesundheitswesen Open-Source-Komponenten in ihren SOA-Vorhaben, beobachtet Gartner-Analyst Paolo Malinverno. In einigen Fällen ist der Einsatz quelloffener Software sogar vorgeschrieben, wenn die Funktionen mit denen von Cloused-Source-Systemen vergleichbar sind. Auch mittelgroße Untenehmen experimentieren mit Open-Source-Produkten.
Dennoch setzen Projektverantwortliche derzeit überwiegend konventionelle Techniken für den Aufbau einer SOA ein. Die Gründe dafür sieht Gartner vor allem in der Verfügbarkeit von Supportdiensten sowie dem Reifegrad und der Funktionsvielfalt kommerzieller Produkte. So betrachteten die meisten Organisationen zwar quelloffene Application Server als ausgereift. Für andere Teile der Infrastruktur hingegen, beispielsweise Business-Process-Management-Systeme (BPM), gelte dies nur bedingt. Hinzu kommen Bedenken hinsichtlich der langfristigen Überlebensfähigkeit bestimmter Open-Source-Techniken. Mit seinen jüngsten Ankündigungen in den Bereichen Enterprise Service Bus (ESB) und BPM reagierte beispielsweise Red Hat JBoss auf solche Einwände. Nach Malinvernos Einschätzung deckt der Linux-Distributor damit aber nur Teilbereiche einer SOA-Infrastruktur ab.
SOA-Projekten starten klein
In der Regel beginnen Unternehmen mit eher kleinen SOA-Projekten und weiten die Architektur schrittweise aus, so eine weitere Beobachtung der Gartner-Experten. Die Verantwortlichen wählen dabei unterschiedliche Einstiegspunkte in der IT-Infrastruktur. Einige implementieren zunächst einen ESB, um die meist noch kleine Anzahl von Web-Services zu steuern. Andere ziehen es vor, Services und andere mehrfach verwendbare SOA-Komponenten gleich zu Beginn in einer Registry oder einem Repository zu katalogisieren. Andere Komponenten einer SOA, beispielsweise ein ausgefeiltes Policy Management oder eine BPM-Suite, fügen sie nach Bedarf hinzu. Erst im Lauf der Zeit entsteht daraus eine voll ausgebaute SOA-Infrastruktur.
Open-Source-Einsatz wächst
Mit der zunehmenden allgemeinen Akzeptanz von Open Source und der Verfügbarkeit zuverlässiger Supportdienste werden in den kommenden zwei bis drei Jahren immer mehr quelloffene Techniken in SOA-Projekte Einzug halten, prognostiziert Gartner. Viele Bedenken hinsichtlich eines Open-Source-Einsatzes zerstreuten sich allmählich; der Wandel vollziehe sich langsam, aber stetig. Insbesondere die wachsende Reife von quelloffenen ESBs, die viele Unternehmen als Kernstück ihres SOA-Backplanes betrachteten, trage diese Entwicklung.
Tatsächlich tummelt sich mittlerweile eine ganze Reihe von Open-Source-Anbietern im ESB-Segment. Dazu gehören neben Red Hat auch die Community-Projekte Mule ESB oder der von Iona unterstützte FUSE ESB. Die Deutschen Post übergab ihren eigenentwickelten ESB der Eclipse Foundation (siehe: Eclipse mischt den SOA-Markt auf). Unter dem Codenamen Swordfish entsteht dort ein komplettes SOA Runtime Framework. Wartung und Support für das System offeriert der eigens dazu gegründete Dienstleister Sopera. Gartner geht davon aus, dass Unternehmen immer öfter quelloffene und Closed-Source-Komponenten mischen.
Open Source versus Closed Source
Wer sich für Open-Source-Software in der SOA interessiert, sollte sich einige grundsätzliche Unterschiede zu Closed-Source-Systemen vor Augen führen, empfiehlt Gartner. Die Marktforscher zählen dazu folgende Punkte:
-
Keine Lizenzkosten zu Beginn des Projekts
Unternehmen sollten angesichts dieses offensichtlichen Vorteils bedenken, dass Sie einen Teil der eingesparten Lizenzaufwendungen in Form von Wartungs- und Supportkosten für quelloffene Software aufbringen müssen.
-
Längere Lernkurve für Open Source
Die Dokumentation für reifere Open-Source-Systeme sei in der Regel gut, erläutert Gartner. Weniger populäre oder jüngere Techniken verlangten von Anwendern und IT-Experten aber nicht selten eine längere Einarbeitungszeit.
-
Einfache Anpassbarkeit des Open-Source-Codes
Unternehmen können je nach Bedarf eigene Features für ihre Open-Source-Plattform entwickeln. Sie müssen dazu nicht auf einen Softwarehersteller warten. Voraussetzung ist allerdings ein entsprechendes Know-how. -
Funktionale Erweiterungen für die Community
Einmal erstellte zusätzliche Funktionen oder Verbesserungen können Unternehmen der Open-Source-Gemeinde zurückgeben. Nach Einschätzung von Gartner bringt dies einerseits den Vorteil, dass sich die Community um die weitere Pflege kümmert. Andererseits aber könnten Unternehmen damit aber auch mögliche Wettbewerbsvorteile aus der Hand geben. -
Informelle Support-Vereinbarungen
Wird der Support für ein Open-Source-System nicht von einem kommerziellen Anbieter gewährleistet, sind Unternehmen auf die informelle Unterstützung der Community angewiesen, warnt Gartner. Diese sei in der Regel zwar effektiv, für geschäftskritische Anwendungen aber häufig nicht adäquat.
-
Einfachere Interoperabilität
Weil Open-Source-Techniken stark auf akzeptierten Standards aufsetzen, gestaltet sich das Zusammenspiel mit anderen Komponenten meist relativ einfach. Anbieter von Closed-Source-Produkten nehmen es damit oft nicht so genau. Nicht selten verändern sie Standards oder setzen sie nur unvollständig um.
-
Unvorhersehbare Produktentwicklung
Ein klarer Nachteil von Open-Source-Systemen ist aus Sicht von Gartner, dass sich Unternehmen nicht auf eine Roadmap für die künftige Entwicklung verlassen können. Allerdings stehe ihnen die Möglichkeit offen, selbst Einfluss zu nehmen.
Was Gartner Unternehmen rät
Auf drei Kriterien sollten IT-Verantwortliche achten, wenn sie Open-Source-Software in einer SOA einsetzen, resümiert Gartner: die Reife der Software, das Angebot an Supportdiensten und das verfügbare interne Know-how. Sind diese Voraussetzungen erfüllt, stehe auch einem Einsatz in geschäftskritischen Umgebungen grundsätzlich nichts im Weg.
Mehr zu den Themen Service-orientierte Architektur und Business-Process-Management finden Sie im Experten-Blog SOA meets BPM. (wh)