Was ist eigentlich eine serviceorientierte Architektur (SOA)?

Tipps vom SOA-Experten Daniel Liebhart

tecChannel: Die Vorteile einer SOA mögen vielfältig sein, aber dennoch fragen sich viele IT-Manager, ob eine SOA in ihrem Fall überhaupt angeraten ist. Welche Bedingungen müssen erfüllt sein, damit eine SOA-Strategie sinnvoll und erfolgversprechend ist?

Daniel Liebhart: Meiner Ansicht nach ist eine SOA-Strategie für jedes Unternehmen, welches nicht nur ein betriebliches Informationssystem im Einsatz hat, sinnvoll. Die möglichen Vorteile – Standardisierung, Kostenersparnis und Flexibilität – sind bestechend. Im Weiteren werden alle Hersteller von Standardsoftware wie beispielsweise IBM, Oracle, Microsoft und SAP ihre Produktpalette in Richtung SOA umgestalten. Um nicht einfach dem Diktat eines Herstellers unterworfen zu sein, ist es sinnvoll, dass ein Unternehmen eigene Überlegungen zum Thema SOA anstellt und entsprechende Vorstellungen entwickelt. Erfolg versprechend ist eine SOA für ein Unternehmen dann, wenn ein pragmatischer Ansatz gewählt wird, der auf das Unternehmen und seine bestehenden Systeme und Bedürfnisse abgestimmt ist und auf den drei wichtigsten Standards Web Services, BPEL und XML basiert

tecChannel: Eignen sich manche Unternehmen und Einsatzgebiete besser für eine serviceorientierte Architektur als andere? Von welchen Faktoren hängt dies ab?

Daniel Liebhart: Im Prinzip eignen sich SOA für jedes betriebliche Informationssystem. SOA ist vor allem für größere Unternehmen geeignet, die mehr als einen Hersteller und mehr als eine einzige Technologie einsetzen. SOA ist geradezu prädestiniert für die Lösung von komplexen Aufgabenstellungen wie beispielsweise die Modernisierung bestehender Systeme, die Migration großer Legacy-Systeme, die Lösung des leidigen Schnittstellenproblems in einem heterogenen Umfeld und für die Realisierung unternehmensweiter Lösungen, wie beispielsweise die Stammdatenverwaltung oder das Output-Management. In jedem Fall sollten neu zu erstellende Individuallösungen mit moderner Technologie (Java oder .NET) so gestaltet werden, dass eine Integration der Lösung in eine SOA nicht verhindert wird.

tecChannel: Die Unternehmens-IT steht heute unter großem Kostendruck, daher hinterfragen Verantwortliche natürlich auch den Nutzen neuer Investitionen. Lässt sich berechnen, wie viel eine Implementierung kostet und wann sich die Einführung lohnt?

Daniel Liebhart: SOA hat offensichtliche Kostenvorteile und solche, die erst zur Laufzeit eines Systems sichtbar werden. Selbstverständlich versuchen die großen Hersteller und die Hersteller von Middleware SOA als investitionsintensiv darzustellen, um Ihre neuen Produkte verkaufen zu können. Dies ist berechtigt und der Einsatz der angebotenen Instrumente ist in vielen Fällen sinnvoll, jedoch oftmals überdimensioniert. So ist beispielsweise der Einsatz eines ESB in einer SOA keineswegs zwingend. In vielen Fällen genügt eine BPEL-Engine. Ein Unternehmen sollte ein pragmatisches SOA-Modell nutzen, um Kosten zu sparen.

Auf jeden Fall lohnt sich die Einführung im Falle einer zwingenden Weiterverwendung bestehender Systeme. So kann die Lebenszeit und damit die Amortisation vorhandener Assets verlängert werden. Für neue Systeme gilt: Die Investitionskosten für den Neubau eines Systems bleiben gleich, ob das System nun basierend auf SOA oder basierend auf einer anderen Architektur realisiert wird. Zur Laufzeit gilt jedoch: je änderungsresistenter eine Anwendung ist, desto teuerer ist der Betrieb. Da ist SOA klar im Vorteil. Selbstverständlich lässt sich eine Implementierung rechnen, so wie jedes Informationssystem gerechnet wird. Die Einführung lohnt dann, wenn mehr als eine Technologie zum Einsatz kommt, wenn Standardprodukte mit Individuallösungen kombiniert werden oder wenn unter-nehmensübergreifend Services angeboten werden sollen.

tecChannel: Können Sie sich auch Konstellationen vorstellen, in denen Sie Unternehmen von der Einführung einer SOA abraten würden?

Daniel Liebhart: SOA ist nicht geeignet für Real-Time-Systeme, Dies gilt jedoch auch für andere Standard-Architekturen. Falls ein Unternehmen nur und ausschließlich Standardpro-dukte eines Herstellers einsetzt, ist eine Einführung nicht zwingend. Das wird der Hersteller in zukünftigen Versionen so oder so erledigen.