Nach einer Studie von Wily Technology gewinnen Serviceorientierte Architekturen (SOA) immer mehr an Bedeutung. So setzen 65 Prozent der befragten Unternehmen bereits eine SOA-Lösung ein oder planen eine Implementierung noch für dieses Jahr. Einerseits soll eine SOA die Implementierung und den Betrieb von Software erleichtern und einen möglichen Weg darstellen, um die Integration komplexer IT-Landschaften voranzutreiben. Andererseits bringt eine SOA jedoch auch eine Reihe von Problemen mit sich. Was ist also dran am ungebrochenen SOA-Hype? Für welche Unternehmen eignet sich diese Strategie überhaupt und welche Voraussetzungen müssen diese erfüllen? Wir führten mit Wilys SOA-Spezialistin Karen Jaworski ein Gespräch rund um diese Fragen.
Seit wann arbeiten Sie für Wily und welche Rolle haben Sie dort inne?
Karen Jaworski: Ich arbeite seit zwei Jahren für Wily und konzentriere mich darauf, Wilys Präsenz auf dem SOA-Markt zu etablieren. Vorher war ich als Produktmanagerin verantwortlich für BEAs AquaLogic Service Bus Management-Lösung. Die Entwicklung dieser Lösung erforderte eine eingehende Beratung mit den größten Finanzdienstleistern, Telekommunikationsunternehmen und Retail-Organisationen der Welt in Hinblick auf ihre SOA-Implementierungen. Davon profitiert jetzt auch Wily.
Serviceorientierte Architekturen (SOA) werden auf Seiten der Anwendungsentwicklung innerhalb der IT-Industrie häufig und ziemlich kontrovers diskutiert. Nach Meinung von nicht wenigen Analysten erreicht die Debatte dabei schon ungesunde Ausmaße. Trotzdem behaupten die britischen Analysten der Butler Group z.B, dass eine SOA, die als Architektur zum Erreichen von loser Kopplung auf interagierenden Agenten-Services basiert, an Boden gewinne – und für Verwirrung sorge. Hier steht dann auch oft die Wahrnehmung, dass SOA einfach nur als Implementierung einer Reihe von Web Services verstanden wird. Wie sehen Sie das?
Jaworski: Der Begriff SOA wird tatsächlich oft als Implementierung einer Reihe von Web Services verstanden. Aber SOA ist keine Technologie. Es erfordert nicht die Implementierung bestimmter Technologien. SOA ist ein Design-Pattern, eine Methodologie, um Applikationen lose zu koppeln. Der entscheidende Punkt, ob man nun eine SOA implementiert hat, liegt im "Rip and Replace"-Test. Wenn man ein Teilstück der Technologie-Infrastruktur herausnehmen und es unter Beibehaltung der externen Interfaces austauschen kann, ohne dass irgendeine andere Komponente der Infrastruktur geändert werden muss, dann handelt es sich um eine SOA. Es gibt eine nahezu unbegrenzte Zahl an Technologien, Web Services sind nur eine davon.
Was sind Ihrer Meinung nach die Hauptgründe für ein Unternehmen, eine SOA zu implementieren?
Jaworski: Unternehmen implementieren eine SOA aus einer ganzen Reihe von Gründen. Eine Technologie-Firma wollte zum Beispiel die Kosten für die Pflege seiner TPF (Transaction Processing Facilility) [ein Echtzeitbetriebssystem für die IBM Mainframes der System/360- und der zSeriesFamilie; Red.] verringern, indem sie eine Migration nach Java und Linux vorgenommen hat. Ein Finanzdienstleister wollte Service Provider für die SLA-Performance verantwortlich machen, indem er in der Lage versetzt wurde, die Kommunikation mit solchen Partnern, die die Vertragsbedingungen nicht einhielten, dynamisch aufzulösen und sie durch bessere Verkäufer zu ersetzen. Eine Fortune 50-Firma mit Sitz in den Staaten musste kundenorientierte Anwendungen von Informations-Ratifizierungen isolieren, die für zahlreiche Technologien benötigt wurden. Diese waren durch eine Reihe von Akquisitionen in den Besitz des Unternehmen gekommen.
Welches sind die wichtigsten Fragen, die ein Kunde sich selbst stellen muss, bevor er eine SOA implementiert?
Jaworski: Zuallererst muss ein Kunde die Business-Berechtigung hinter der Implementierung der SOA verstehen. Der Prozess der Implementierung kann mehrere Jahre in Anspruch nehmen und Millionen von Dollar kosten; eine große Firma hat zum Beispiel über fünf Jahre damit verbracht und 100 Millionen US-Dollar für die Implementierung dieser neuen Architektur ausgegeben. Oftmals wird ein Projekt von dieser Größe abgebrochen, bevor es überhaupt richtig anfängt. Erst wenn diese Hürde überwunden ist, sollte ein Kunde mit einer gründlichen Einschätzung der Technologien und Fähigkeiten beginnen.
Jeder SOA-Erfolgsgeschichte entspricht ungefähr ein aufgegebenes SOA-Projekt, das in irgendeinem Stadium des Deployments stecken geblieben ist. Dennoch sind SOAs noch immer an der Spitze der Agenda von Verantwortlichen und der IT allgemein. Der Grund hierin liegt sicherlich, dass Technologien näher mit den Geschäftsbedürfnissen verbunden werden. Was benötigt SOA Ihrer Meinung nach, um Erfolg zu haben?
Jaworski: Zusätzlich zu einem klaren Geschäftsmodell von SOA müssen Firmen sicherstellen, dass sie eine SOA in zeitlichen Phasen angehen. Man muss klein anfangen. Erziele einen Erfolg, der die ganze Organisation dafür begeistert. Arbeite mit der Business-Seite, um zuerst die eher schmerzhaften Seiten in Angriff zu nehmen. Organisiere dir ein Super-IT-Talent, um eine SOA-Vision zu entwickeln und für eine geschlossene Führung sorgt. Wenn genug Geld und Köpfe hinter der SOA-Initiative stehen, ist die Aussicht auf einen Misserfolg schon wesentlich geringer.
Wie wichtig ist SOA für kleinere und mittelgroße Unternehmen? Können Sie uns einige spezifische Beispiele geben, wie SOA einem kleinen und mittelgroßen Unternehmen (Small and Middle Enterprises = SME) dabei geholfen hat, seine IT auf ein höheres Level zu bringen?
Jaworski: SOA ermöglicht SMEs, ihr Business weit über das Unternehmen hinaus auszudehnen. Sie haben dann die Möglichkeit, ihre ganze Supply Chain zu überdenken und neu zu gestalten. Truelink, eine kleine Zweigstelle der TransUnion in den USA war in der Lage, SOA so einzusetzen, dass sie über Kreditgesellschaften hinweg sich etablieren und Kunden Kreditwarnungs-Services anbieten konnten. Das Internet und SOA haben sie in die Lage versetzt, ihr Inventar auszugliedern und sich auf die Lösung weitverbreiteter Kundenprobleme zu konzentrieren.
Mit dem Aufkommen von Web 2.0 werden neue leichtgewichtige Technologien propagiert. Stellen diese eine Gefahr für SOA dar?
Jaworski: SOA hat nicht nur mit einer Technologie zu tun und auch nicht nur mit einer Reihe von Technologien. Es ist ein Design Pattern. Die leichtgewichtigen Web 2.0-Technologien verlassen sich ziemlich auf die lose gekoppelten, standardbasierten Konzepte, die SOA in die IT-Welt eingeführt hat.
Welche Rolle spielen Portale im SOA-Kontext?
Jaworski: Portale sind ein Technologie-Framework, das diese Erfahrung vereinfacht. Sie agieren als Service-Konsolidatoren, um eine einheitliche Sicht in das Unternehmen zur Verfügung zu stellen. Viele Portale sind mit einer Identität ausgestattet und einem Zugriffsmanagement-Modul. Und oft bieten sie auch ein Flow-Framework für die Ermächtigung von Geschäftsprozessen an.
Wird das klassische Konzept der Portal-Technologie immer noch existieren, wenn es um SOAs geht? Oder wird die Zukunft nach einer leichteren Mash-up-Version verlangen, die keinen Standard für Java-Portale hat?
Jaworski: Portal-Frameworks bieten zu viele wertvolle Services, um sie vollständig verschwinden zu lassen. Ich glaube aber, dass die Existenz von Mash-ups die IT dazu zwingen wird, strategischer darüber nachzudenken, wann eine volle Portal-Infrastruktur deployt und wann eine leichtgewichtigere Version genutzt werden sollte. Auf der anderen Seite der Gleichung vermute ich, dass die Verkäufer ihre Portal-Produkte wieder zusammenführen werden, damit sie auch Mash-up-Fähigkeiten enthalten, und dadurch auch weiterhin ihre Relevanz in diesem Bereich sicherstellen werden.
Unternehmen haben SOA aufgrund technischer Vorteile übernommen. Aber die Übernahme und der Übergang hin zu einer SOA erfordert organisatorische wie auch technische Veränderungen. Wo sehen Sie die wichtigsten Implikationen?
Jaworski: Einer der Hauptvorteile von SOA ist die Fähigkeit, Funktionalitäten zu zentralisieren, die innerhalb der Organisations-Silos dupliziert sind. IT-Abteilungen, die sich hin zu einer Silo-artigen Struktur entwickelt haben, haben das aus realen Geschäftsgründen getan. Aber mit dem Ziel, Zentralisierung zu erreichen, werden diese Teams ihre Kommunikationsbarrieren einreißen müssen, um cross-organisierte Teams für die SOA-Leitung und -Aufsicht zu bilden. Wenn man SOA richtig macht, erfordert das möglicherweise keine Neuorganisation, aber eine Umstrukturierung von IT-Prozessen ist mit ziemlicher Sicherheit gefordert.
Wenn der Hype mal vorbei ist, was wird dann von SOA bleiben?
Jaworski: Echter Geschäftswert. Dieser Markt ist mittlerweile so over-hyped, dass viele Firmen durcheinander sind. Was ist SOA? Handelt es sich um ein spezifisches Set von Technologien? Benötige ich all die Software, die heute auf dem Markt ist? Wenn der Hype vorbei ist, werden eine Menge von IT-Abteilungen in der Lage sein, diese Frage sehr viel einfacher zu beantworten. Eine Reihe gut etablierter Best Practices wird leicht verfügbar sein, ebenso die erforderlichen Skillsets im Hiring-Pool. Die IT wird besser positioniert und besser für den SOA-Handel vorbereitet sein, um echte Lösungen für echte Geschäftsprobleme anzubieten.
Zum Abschluss: Gibt es eine spezielle Wily-Strategie im Hinblick auf SOA? Wie möchte man sich bei Wily vom Markt abgrenzen?
Jaworski: Wenn wir mit Kunden über die Herausforderungen sprechen, die ihnen im Zusammenhang mit SOA begegnen, sehen wir einen neuen Bereich an Komplexität, der zur Infrastruktur hinzukommt. Wily hat Unternehmen immer dabei geholfen, die Komplexität innerhalb der IT herunterzufahren, indem wir die Applikationstransaktionen entmystifiziert haben und dadurch das Blame Game vermieden werden konnte. Der entscheidende Auftrag, den wir von Kunden zu hören bekommen, ist, diese Fähigkeit in der SOA-Welt zur Verfügung zu stellen. Wily bietet eine umfassende Suite an SOA-Lösungen für das End-to-End-Transaktionsmanagement, um der IT-Branche dabei zu helfen, Einblick in die SLA-Erfüllung und End-User-Erfahrung zu bekommen, die proaktiven Warnungen zu erleichtern sowie Sichtungen und Diagnosen von Service-Ausfällen durchzuführen.
Wir bedanken uns für das Gespräch.
Die Fragen stellte Java Magazin-Redakteur Alexander Neumann.
Kommentare