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 Funk-tionen mit denen von Closed-Source-Systemen vergleichbar sind. Auch mittelgroße Unternehmen experimentieren mit Open-Source-Produkten.

Support- und Produktreife

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-Dis-tributor damit aber nur Teilberei-che einer SOA-Infrastruktur ab.

SOA-Projekte 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 Deutsche Post übergab ihren eigenentwickelten ESB der Eclipse Foundation. 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 quell-offene und Closed-Source-Komponenten mischen. Auf drei Kriterien sollten IT-Verantwortliche achten, wenn sie Open-Source-Software in einer SOA einsetzen, resümieren die Analysten: 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.

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 Lizenzaufwendun-gen 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 Anpassbarkeitdes 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 kommerziellen 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 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.u