Die Implementierung einer SOA auf Unternehmensebene ist eine strategische Entscheidung. Sie hat das Ziel zu der überlebenswichtigen Flexibilität beizutragen, die dynamische Märkte in der heutigen Zeit erfordern. Viele Unternehmen entscheiden, eine SOA zunächst in bestimmten Bereichen oder für bestimmte Prozesse einzuführen. Damit sammeln sie die notwendige Erfahrung um eine unternehmensweite Implementierung ins Auge zu fassen. Unabhängig vom Umfang einer SOA-Initiative ist es jedoch immer erforderlich nachzuweisen, dass sich die finanzielle Investition in ein solches Vorhaben innerhalb weniger Monate auch wieder für das Unternehmen auszahlt. Der “Break-Even-Point” muss schnell erreicht sein. Genau diese Betrachtung vermisse ich in der aktuellen Diskussion um dieses viel versprechende Architekturkonzept. Dabei geht es doch um die Schließung der Lücke zwischen Geschäft und IT.
Wie kann eine SOA positiven Einfluss auf den ROI einer Unternehmung nehmen?
In vielen Publikationen wird als wesentlicher Vorteil einer SOA zu Recht die Möglichkeit beschrieben, neue Geschäftsprozesse durch Rekombination existierender Service Operationen zu unterstützen. Diese Flexibilität wird im Wesentlichen dadurch erreicht, dass eine geschäftsorientierte Kapselung von Service Operationen angestrebt wird. Außerdem wird auf weitere bewährte Entwurfprinzipien, wie “Information Hiding”, gebaut. Das alles sagt aber nichts über den Einfluss einer SOA auf den ROI.
Continue reading ‘Wie SOA den ROI beeinflusst’
Der Abschluß des Beitrags von Wolfgang Herrmann “Mit der Marktkonsolidierung steigt auch im SOA-Zeitalter wieder die Gefahr der Herstellerabhängigkeit” provoziert geradezu eine Gegenposition.
Es ist zwar das große Versprechen der Hersteller, dass mit SOA alles besser wird. Das bezieht sich auch auf vermeintliche Herstellerunabhängigkeit beim Einsatz von Software-Produkten (und ggfs. auch bei Hardware). Dabei soll hier nicht das Grundsätzliche SOA-Konzept in Frage gestellt werden. Aus meiner Sicht gibt es mittel- bis langfristig keine wirkliche Alternative - vielmehr meine ich, dass sich das Konzept auch auf allgemeine Unternehmenssteuerungskonzepte übertragen wird.
Allerdings wird es eine Herstellerunabhängigkeit nicht automatisch mit der Einführung von SOA geben. Die Abhängigkeiten werden - wie heute - erhalten bleiben. Es mag zwar im Einzelfall einfacher werden, eine Komponente von einem Hersteller gegen eine Komponente eines anderen Herstellers auszutauschen (zB. im Commodity-Office-Bereich). Aber ein komplexe Systemlandschaft wird sich nicht beliebig durch eine andere ersetzen lassen. Man könnte vielmehr vermuten, dass die Abhängigkeit sogar noch ansteigt. Denn wenn eine komplexe IT-Systemlandschaft, die sich auf Komponenten mehrerer Hersteller abstützt und auf der Basis einer SOA aufgebaut ist, erst einmal getestet ist (ja, das wird ein drängenden Problem!) und im Einsatz ist, wird der Ersatz von Teilkomponenten eher schwieriger als einfacher. Insofern nimmt die Herstellerabhängigkeit mitnichten ab.
Vielmehr bleibt es in Zukunft weiterhin keinem erspart, “am Beginn über das Ende” nachzudenken. Will heissen, dass das beste Architektur- und Implementierungskonzept auch immer eine Exit-Strategie umfassen sollte. Diese kann greifen, wenn ein Lieferant insolvent wird oder aus anderen Gründen eine Geschäftsbeziehung mehr aufrecht erhalten werden soll. Die Erhöhung der Flexibilität, die viele Unternehmen mit SOAs erreichen wollen, setzt auch voraus, die potentielle Flexibilität auch mit Leben zu füllen. Das wiederum bedeutet das Management von Optionen, die zwar derzeit nicht ausgeübt werden, die aber als Backup, Fall Back oder einfach als Alternativstrategie zu 80% einsatzfertig durchdacht sein sollte.
Die Empfehlung an Anwenderunternehmen lautet also, beim Einsatz von Komponenten (nicht nur) für eine SOA parallel eine Exitstrategie mitzuentwerfen. Diese “Denken mit doppeltem Boden” passt den Herstellern sicher überhaupt nicht, aber es schützt vor zu hoher Abhängigkeit.
Wie sind IT-Architektur und Unternehmensarchitektur miteinander verknüpft? Was ist Service-orientierte Architektur (SOA) wirklich und welche Aspekte sind für die Gestaltung von Unternehmensarchitekturen besonders relevant? Welche Ansätze zur “Service-orientierten” Architekturentwicklung setzen sich aktuell in der Praxis durch?
Wie das Marktforschungs- und Beratungshaus Gartner diese Fragen beantwortet lesen hier.
Ohne ausgefeilte Governance-Mechanismen und -Tools können SOA-Projekte schnell außer Kontrolle geraten. Diese Mahnung von IT-Beratern und Analysten schienen lange Zeit vor allem kleine Spezialanbieter ernst zu nehmen. Softwareschmieden wie Infravio oder Flashline machten sich mit Registry- und Repository-Systemen für die Verwaltung von Softwareservices einen Namen; in Produktvergleichen schnitten sie oft besser ab als die großen Plattformanbieter. Doch inzwischen haben die mächtigeren Player den Bedarf erkannt und schließen Lücken in ihrem Portfolio: Die Übernahme des Repository-Anbieters Infravio durch Webmethods ist nur das jüngste Beispiel für die anhaltende Konsolidierung in diesem Marktsegment. Schon im August hatte Bea Systems das US-Softwarehaus Flashline gekauft. Dessen Metadaten-Repository wird künftig als Teil der Aqualogic-Produktfamilie vermarktet. Die letzten beiden Spezialanbieter für Registry/Repository-Systeme verloren damit ihre Unabhängigkeit.
Dass immer mehr kleine Hersteller von mächtigen Allroundanbietern gefressen werden, zeigte schon die Übernahme von Systinet durch den Hersteller Mercury Interactive, der später von HP geschluckt wurde. Kunden dürften von dieser Entwicklung kaum profitieren, denn die Plattformanbieter betonen stets die enge Integration der Tools in ihre breiter angelegten SOA-Stacks und versuchen naturgemäß, das ganze Paket zu verkaufen. Auch die Software AG geht mit ihrer SOA-Suite Crossvision und dem darin enthaltenen Registry/Repository-System CentraSite diesen Weg. IBM hat ein ähnliches Produkt für Oktober angekündigt und wird dieses als Teil der Websphere-Produktfamilie vermarkten. Die alte Frage “Best of Breed oder integriertes Paket?” könnte sich aus Anwendersicht damit schon bald erledigt haben. Mit der Marktkonsolidierung steigt auch im SOA-Zeitalter wieder die Gefahr der Herstellerabhängigkeit.
Wie grenzt sich SOA gegenüber EAI, ESB und dem von SAP getriebenen Begriff ESA ab?
Diese Frage an den Expertenrat beantworten Florian Mösch von T-Mobile und Karin Sondermann von Microsoft.
Florian Mösch:
EAI ist im Wesentlichen ein rein technischer Ansatz zur Integration von Anwendungssystemen. Die verschiedenen Hersteller haben hauptsächlich proprietäre Produktsuiten herausgebracht, deren Einsatz ein sehr hohes Spezialistenwissen erfordert. Zu SOA hingegen gibt es durchaus erkennbare Standardisierungsbemühungen, beispielsweise:
• JMS (Java Message Service) als Backbone
• JBI (Java Business Integration) als Integrationsschicht
• WSDL / XSD als Servicespezifikation
• SOAP als Transport
• BPEL (Business Process Execution Language) als Workflow-Standard
Aus architektureller Sich kann man durchaus sagen, dass die Infrastruktur einer SOA eine Weiterentwicklung von EAI ist. In der neuesten Ausgabe des “SOA Magazine” gibt Cyrille Thilloy einen recht guten Überblick über die Historie von Enterprise Integration und die Entwicklung über EAI zu SOA. Bestandteil des Architektur-Blueprints einer SOA ist der Enterprise Service Bus (ESB), der allerdings mehr umfasst als der EAI Backbone. Zum ESB zählen auch die Protokoll-Adapter (z.B. Webservices, ebXML,…), das Service Registry, Mapper, Business Process Management und Service Orchestration Engine.
ESA ist die SOA-Geschmacksrichtung von SAP, die sich im Grunde nur dadurch differenziert, dass der Blueprint rund um NetWeaver aufgebaut ist und man dort hauptsächlich SAP-Komponenten als Service-Backends findet.
Continue reading ‘SOA, ESA, ESB, EAI - eine Frage der Definition’
Beiträge (Atom)
Letzte Kommentare
RSSBenjamin Hötzel
Uwe Feddern, Falke, F. Delonge [...]
B. A. Schön, Jakob Freund
Daniel Craig, Tobias Thiel, Sascha Körner