Ein Großteil der Kernanwendungen in Unternehmen und öffentlichen Verwaltungen basiert noch immer auf Programmiersprachen wie Cobol, PL/1 oder Assembler. Die Wartung dieser oft mehr als 20 Jahre alten Legacy-Systeme ist aufwändig und teuer, schlimmer noch: Anpassungen geraten zu komplexen Projekten und halten mit den immer häufiger wechselnden Anforderungen der Fachabteilungen nicht mehr Schritt. Ob SOA-Konzepte die Probleme lösen können, diskutiert der Expertenrat in einem virtuellen Roundtable.

"Keine SOA-Vorteile ohne Prozesswissen"

Florian Mösch, Head of Enterprise Integration, T-Mobile Deutschland

SOA ist technisch prinzipiell nichts Neues, sondern vereinfacht und standardisiert Konzepte wie den "Software-Bus" der 80er und Client-Server Architekturen der 90er Jahre. Ein zusätzlicher Mehrwert ist die Zusammenführung moderner Java- und Web-Technologien mit klassischen Host-Architekturen. Dies alleine wäre zwar eine sehr hilfreiche Weiterentwicklung, würde aber den Wirbel nicht wert sein, der um SOA stattfindet. Erst die Modularisierung der Anwendungslandschaft, das Begreifen von Abläufen als Prozesse und die darauf fußende fachliche Modellierung von Services machen SOA wirklich interessant. Dadurch können - nicht nur theoretisch - Funktionen wiederverwendet werden, so dass der IT und dem Business geholfen ist.

Die meisten Anbieter konzentrieren sich aber hauptsächlich auf die technischen Aspekte von SOA und lassen Unternehmen hinsichtlich der fachlichen Methodik meist mit Allgemeinplätzen auf sich gestellt. Insbesondere bei der konkreten Nutzenbetrachtung, zum Beispiel auf Basis eines realen Business Case, sind die von den meisten Anbietern geweckten Erwartungen nur schwer substantiierbar. Das Know-how über die betrieblichen Prozesse und deren Abbildung in Applikationen muss also in der IT vorhanden sein, käuflich ist dies nur - wenn überhaupt - selten und teuer. Ohne dieses Wissen wird der Umstieg auf SOA zur reinen Technikübung, und die versprochenen Vorteile lassen sich nur ansatzweise realisieren.

"Wiederverwendung auf hohem Niveau"

Daniel Liebhart, Solution Manager, Trivadis

Der SOA-Blueprint sieht die Integration bestehender Systeme explizit vor. Legacy-Software wird durch Service-Interfaces gekapselt, um einzelne funktionale Blöcke als Dienst auf hoher Ebene wiederzuverwenden. Im Unterschied zu den Ansätzen der objektorientierten Programmierung und der Komponententechnik erfolgt die Wiederverwendung auf eine sehr viel pragmatischere Art und Weise. So kann ein Host-System mit einfachen Services ausgestattet werden, die keine Änderung des Legacy-Systems erfordern. Der Service selbst muss nicht einmal auf dem Host-System ablaufen, er kann über bestehende Schnittstellen (zum Beispiel FTP) interagieren. Dieser Ansatz widerspricht selbstverständlich dem Bedürfnis vieler Hersteller, Bridges oder EAI-Infrastruktur zu verkaufen oder ein Host-System in verschiedene Komponenten aufzubrechen. Voraussetzung ist jedoch eine funktionale Schneidung des bestehenden Systems, die sehr nahe an seiner bestehenden Struktur erfolgt.

SOA ist die ideale Reengineering-Zielplattform

Soll ein Legacy-System abgelöst werden, so ist SOA geradezu als Zielplattform für das Reengineering prädestiniert. Die einzelnen funktionalen Blöcke des Legacy-Systems werden als Services abgebildet. Die Aufrufsequenzen, wie sie nutzende Systeme oder Batch-Prozesse ausführen, werden als Business-Prozesse modelliert und sind dank BPEL automatisch ausführbar. Aufrufe von Subprogrammen können als Business Rules modelliert werden. Damit wird ein Legacy System in Teilsysteme aufgeteilt. Diese Teilsysteme können entweder als neue Services realisiert oder aber direkt weiterverwendet werden.

"SOA beginnt bei der Business-Integration"

Alexander Scherdin, Senior Professional

für IT-Service Design, Deutsche Post

SOA wird von der Deutschen Post seit 1999 als zentrales Architekturparadigma genutzt. Zielsetzung war und ist die verbesserte Integration von Business und IT. Die Post nutzt SOA dabei als Management-Werkzeug, um statische Verflechtungen von Prozessen und IT auf wirkungsvolle Weise aufzulösen.

Ein gezieltes Service-Portfolio-Management ist dabei ein Schlüsselfaktor. Es sorgt für Integration, die bereits auf der fachlichen und semantischen Ebene beginnt. Dieses Business-getriebene Vorgehen bereitet den Boden für eine weitere technische Integration der Anwendungslandschaften durch SOA.

Legacy-Anwendungen, aber auch moderne Applikationen können so erfolgreich durch SOA integriert werden. Die technische Integration ist indes Folge, nicht der Ausgangspunkt einer fachlich getriebenen SOA-Strategie. Und genau hier liegt der Unterschied von SOA zu vermeintlichen "Silver Bullets" der Vergangenheit.

Die Reduzierung von SOA auf einen - technisch motivierten - Königsweg zur Legacy-Integration zäumt das Pferd von hinten auf. Denn eine SOA lässt sich nicht kaufen, sondern verlangt nachhaltiges Management. Zudem bleiben auch mit SOA moderne Anwendungslandschaften komplex - wenn auch mit steigender Beherrschbarkeit.

"Ursachen der Legacy-Falle bedenken!"

Norbert Schaedler, Executive Software Architect, IBM Deutschland

Einleitend muss ich, aus vielen persönlichen Erfahrungen schmerzhaft gelernt, sagen, dass wenn jemand mit Königswegen, Patentrezepten oder Ähnlichem aufwartet, höchstes Misstrauen angebracht ist. Um die Aussage nun in diesem Kontext zu bewerten, müssen wir zunächst einige Gedanken an die Gründe für das Zuschnappen der Legacy-Falle verschwenden. Dies hat überhaupt nichts mit den genannten Programmiersprachen zu tun, sondern lediglich mit mangelnder Disziplin in Bezug auf alles, was wir seit langem über Software-Engineering wissen. Schlecht dokumentierter Spaghetti-Code, der die Ursache für die genannten Probleme darstellt, entsteht nicht durch die Verwendung einer bestimmten Programmiersprache, sondern durch schlechtes Programmieren und fehlende Qualitätskontrolle bezogen auf Regeln (heute auch gerne Governance genannt), die ja meist durchaus existieren.

Der Service-orientierte Ansatz baut in den meisten Bereichen auf bewährten Software-Engineering-Regeln auf und stellt keine neuen revolutionären Konzepte bereit. Allein durch SOA wird also die Falle weder verlassen noch entschärft werden können!

Trotzdem glaube ich, dass der Service-orientierte Ansatz einen wertvollen Beitrag zum Vermeiden des Legacy-Dilemmas leisten kann. Er führt, ausgelöst durch den Zwang, künftige Systeme leichter veränderbar zu bauen, hoffentlich zu einem tief greifenden Umdenken bei der Konzeption und Implementierung von Softwarelösungen. Oberste Voraussetzung ist dabei dann aber, dass ein Unternehmen ein für sich relevantes Regelwerk rund um eine SOA festlegt und die Einhaltung konsequent erzwingt.

"Was ist eigentlich Legacy?"

Wolfgang Beinhauer, Fraunhofer-Institut

Arbeitswirtschaft und Organisation (IAO)

Zur Beantwortung der Frage, ob SOAs den Königsweg aus der Legacy-Falle darstellen, muss man sich zunächst einmal darüber im Klaren sein, was Legacy eigentlich ist. Tatsächlich wird ja jede neue Software im Augenblick ihrer Indienststellung zu Legacy. Dieser Terminus ist also zu Unrecht mit einem negativen Beigeschmack behaftet - handelt es sich doch tatsächlich zumeist um bewährte Softwaresysteme, die ihre Aufgaben in der Regel gut erfüllen.

Was sich geändert hat, sind die Anforderungen, die an die bestehenden Systeme gerichtet sind. Erweiterte Funktionalität, Unterstützung neuer Oberflächen - vor allem aber eine stärkere Vernetzung der Anwendungen mit Drittsystemen, womöglich jenseits der Unternehmensgrenzen, sind neue Anforderungen. Die Frage ist nun: Wie kann hier Serviceorientierung helfen?

Bei der Bewältigung der technischen Integrationsaufgabe können SOA-Produkte wie etwa ein Enterprise Service Bus (ESB) sicher helfen. Die Unterschiede zu herkömmlichen EAI-Produkten sind jedoch nicht groß. Einen deutlicheren Fortschritt bringt hier die mit der SOA-Einführung einhergehende Standardisierung und bessere Dokumentation der Schnittstellen und Services.

Die eigentlichen Neuerungen von SOAs liegen jedoch auf der Anwendungsebene: Serviceorientierung in der IT bedeutet Prozessorientierung auf der Fachseite. Hier müssen SOAs ihre Investitionskosten wieder einspielen. Dies ist nur mit auf Flexibilität zugeschnittenen Services möglich - andernfalls schnappt die Legacy-Falle auch mit SOAs wieder zu.

"SOA alleine reicht nicht"

Rolf Schumann, Director SAP Netweaver,

SAP Deutschland

Eine realistische Einschätzung der Möglichkeiten von SOA als Königsweg aus der "Legacy-Falle" setzt voraus, den rein technischen Blick auf SOA um die zugrunde liegende Geschäftslogik zu erweitern. SOA ist eine mächtige Architektur - reicht alleine jedoch nicht aus. Es gab zu viele Konzepte ähnlicher Argumentation, die alle an dem gleichen Punkt scheiterten: der Geschäftssemantik. Nur wenn im Rahmen der SOA sichergestellt ist, dass die betriebswirtschaftlich notwendige Geschäftssemantik ausreichend Berücksichtigung findet, wird man den Versprechungen der SOA-Protagonisten gerecht.

SOA muss als Enterprise SOA, sprich Architektur mit der unabdingbar verknüpften Geschäftslogik, gesehen und verstanden werden. Das heißt, die ersten Gedanken liegen bei den Unternehmensanforderungen der Legacy-Anwendung sowie den dahinter liegenden Prozessen und Daten. Dieses Wissen führt in die Diskussion der benötigten Services und deren Granularität und Wiederverwendungsgrad. Der Gedanke, dass man diese Diskussion einheitlich in einer Service-orientierten Geschäftsprozessplattform führt, stellt meines Erachtens einen möglichen "Königsweg" dar. Alles andere ist zu kurz gedacht und wird nicht den erhofften Mehrwert liefern.

"Legacy-Ablösung bedeutet einen Paradigmenwechsel"

Axel Jacobs, Vice President Gartner Consulting, Gartner Deutschland

Es klingt wirklich verlockend und erfolgversprechend: die Ablösung von Applikationen, die in die Jahre gekommen sind - und eine stetige Quelle von ungeplanten Folgekosten sind - durch neue Standardapplikationen, die nach dem SOA-Ansatz konzeptioniert sind. Viele Anbieter erklären, dass in der Umstellung auf SOA-basierende und sowohl modular als auch adaptiv aufgebaute Geschäftsprozess-Plattformen (Business Process Platforms = BPP) die ideale Lösung zur Flucht aus der "Legacy-Falle" zu sehen ist.

Allerdings sollte bei aller (Hersteller-) Euphorie berücksichtigt werden, dass nur sehr wenige der angebotenen Produkte eine hinreichende Vollständigkeit in Bezug auf die funktionalen und technischen Anforderungen einer BPP/SOA-Vision besitzen. Ferner ist der Übergang von Legacy-Systemen zu Service-orientierten Geschäftsprozess-Plattformen keineswegs so unkompliziert, wie beispielsweise die Einführung der ERP-Systeme der ersten Generation, sondern definitiv mit einem Paradigmenwechsel verbunden. Trotzdem gibt es technologisch und betriebswirtschaftlich gesehen keine Alternative, wenn die Ablösung von Legacy-Systemen auf der Basis eines perfekten Business/IT-Alignments und im Bestreben einer Professionalisierung der IT stattfinden soll. Nachhaltigen Erfolg werden sicher nur diejenigen Unternehmen haben, die diese Herausforderung auf der Basis eines ganzheitlichen Architektur- und Serviceverständnisses annehmen.

"Ohne Governance keine Legacy-Migration"

Rainer Berbner, Technische Universität

Darmstadt, E-Finance Lab

Wie unsere Erfahrungen im Rahmen von Projekten im SOA-Umfeld gezeigt haben, ist die Migration von monolithischen Legacy-Systemen hin zu einer Service-orientierten Architektur (SOA) kein Selbstläufer. Die immer wieder von den SOA-Protagonisten genannten Vorteile, beispielsweise Wiederverwendung von Services, kürzere Time-to-Market, Kostensenkungen und Investitionsschutz, können nur dann auch tatsächlich realisiert werden, wenn Governance-Aspekte für SOA-basierende Geschäftsprozesse berücksichtigt werden.

Governance zielt hierbei zum einen auf Management-Funktionalität, die die Dienstgüte (Quality of Service = QoS) der beteiligten Services steuert. Unter Dienstgüte werden hierbei die nichtfunktionalen Serviceeigenschaften wie Verfügbarkeit, Antwortzeit und Fehlerrate verstanden. Diese können zwischen Service-Provider und Service Consumer in einem Service-Level-Agreement (SLA) verbindlich festgelegt werden. Zum anderen ist im Rahmen einer Corporate Governance sicherzustellen, dass die SOA-basierenden Geschäftsprozesse konform mit Unternehmensstrategie, Geschäftsmodell und rechtlichen Rahmenbedingungen sind.

Ein weiterer entscheidender Faktor bei der Ablösung von proprietären Legacy-Anwendungen ist die erfolgreiche Standardisierung von Technologien im SOA-Umfeld wie zum Beispiel der Web-Services.

"Legacy-Modernisierung erhöht die Reaktionsfähigkeit"

Karin Sondermann, Platform Business Development Manager, Microsoft Deutschland

Service-Orientierung steht bei IT-Vorständen und CIOs derzeit hoch im Kurs - und das aus gutem Grund. So besteht bei traditionellen, monolithischen Anwendungen das Problem, dass jede Änderung eines Prozesses ein mehr oder weniger aufwändiges Redesign des Gesamtsystems erfordert. Einer der wichtigsten Treiber für SOA-Projekte ist die Verkürzung der Time-to-Market, die wiederum zu einer schnelleren Time-to-Value beiträgt. So prognostizieren namhafte Analysten, dass Wettbewerbsfähigkeit der Unternehmen künftig über Reaktionsfähigkeit entschieden wird. Somit rückt folgende Frage immer mehr in den Mittelpunkt: "Wie schnell ist Ihr Unternehmen in der Lage, innovative Ideen in marktreife Produkte oder Services umzusetzen?"

Service-orientierte Architekturen vereinfachen organisatorische Veränderungen, indem sie Funktionen kapseln und in lose gekoppelten Einheiten zur Verfügung stellen. Auf diese Art und Weise können auch Legacy-Anwendungen modernisiert oder teilweise sukzessive ersetzt werden und erhöhen somit die Reaktionsfähigkeit der Unternehmen. Die Grundidee, diverse Unternehmensfunktionen zu ordnen und sie als unabhängige Dienste intern sowie extern zur Verfügung zu stellen, setzt voraus, dass Anwendungen servicefähig sind. Legacy-Anwendungen erfüllen diese Eigenschaft in der Regel nicht, somit müssen die Systeme zunächst unter dem Serviceaspekt aufbereitet und anschließend SOA-gerecht integriert werden.

"SOA-Pläne bis zum Jahr 2015"

Armin Büttner, CTO Audi-Markengruppe

im VW-Konzern, Audi AG

SOA - Königsweg aus der Legacy-Falle ? - Diese Fragestellung ist eindeutig zu trivial. Hat etwa Herr Klinsmann einen Königsweg aus dem "Rumpelfußball" gefunden? Die Antwort lautet wohl "Ja und Nein": Halbfinale erreicht, Weltmeistertitel leider verpasst. Wir lieben jetzt alle diese Nationalmannschaft. Leidenschaft, Risikofreude und auch Enthusiasmus sind Attribute, die diese Mannschaft prägen. Warum sollen diese Attribute nicht in hochkomplexe Aufgabenstellungen der Informationstechnologie transformiert werden können?

Wir bei Audi haben uns ein sehr anspruchsvolles Volumenwachstum vorgenommen. Diese Wachstumsziele reflektieren sich natürlich auch in unseren zukünftigen IT-Landschaften und unserem dazugehörigen IT-Projektportfolio. Unsere IT-Strategiepläne reichen bis in das Jahr 2015. Und hier spielen zukünftig Service-orientierte Architekturen (SOA) eine große Rolle.

Ich sehe große Chancen für unser Business, dieses geplante Wachstum in neuen, innovativen (SOA)-Lösungen abbilden und managen zu können. Wir müssen unsere Lösungen viel schneller den Fachbereichen zur Verfügung stellen können. Man kann nicht mehr monatelang ins Trainingslager gehen und Lastenheft- und Pflichtenheft-Diskussionen führen, wenn sich an anderer Stelle die Zeit nicht mehr hereinholen lässt.

Eine der (SOA-) Chancen liegt eben in der Wiederverwendbarkeit und der Qualität von entwickelten Services. Mit einem gemeinsamen SOA-Verständnis im Unternehmen, in den Fachbereichen und in den IT-Abteilungen werden sich Wege aus der Legacy-Falle finden lassen.

"SOA - ein Königsweg für die Hersteller"

Rüdiger Spies, Executive Advisor,

Experton Group

Service-orientierte Architekturen sind im Moment vor allem für Hersteller Königswege aus den unterschiedlichsten Motivationen. Für IBM ist es die Bindekraft und das einheitliche Leitbild, das bisher E-Business eingenommen hat. Für SAP ist es der Weg aus der eigenen Vergangenheit, die entwicklungstechnisch nur noch schwer zu beherrschen war. Für Oracle und andere Technologiezukäufer ist es die Chance, alle Teillösungen unter ein einheitliches Erscheinungsbild zu bekommen. Für Microsoft ist es sowohl die Chance, die eigene Produktentwicklung von Komplexität zu befreien, als auch weiterhin Technologieglaubwürdigkeit zu behalten.

Anwender sollten das "A" in SOA besonders betonen. Es ist der wichtigste Begriff. Die Architektur muss im eigenen Hause entwickelt und den individuellen Gegebenheiten angepasst sein. Hier wird der zukünftige Grundstein für erfolgreiche IT-Business-Integration gelegt. Diese nächste Abstraktionswelle der IT - nach der Mainframe-Ära und den Client-Server-Architekturen - ist eine langfristige Umstellung in der Art, wie IT-Lösungen das Kerngeschäft der Unternehmen unterstützen. Kurzfristige Erfolge werden eher die Ausnahme bleiben. Insofern ist der SOA-Weg eher ein langer Königsmarsch als ein einfacher Königweg aus der Legacy-Falle.

"Altsysteme in die SOA einbinden"

Simone Frömming, Vice President Sales,

Oracle Deutschland

Service-orientierte Architekturen (SOA) beschreiben, wie Unternehmen eine Middleware nutzen können, um lose gekoppelte, verteilte Services zu erreichen. Diese Services zeichnen sich aus Sicht einer SOA unter anderem dadurch aus, dass sie grob-granularer als Komponentenschnittstellen sind sowie stärker hinsichtlich ihrer Geschäftsrelevanz strukturiert sind als Komponenten.

Die hier genannten Eigenschaften können auch mit komponentenorientierten Architekturen wie Corba oder DCOM erreicht werden, denn das Konzept der "Service-Orientierung" ist im Bereich dieser Middleware-Systeme entstanden. Die Ziele von SOA gehen jedoch weiter und ermöglichen neben der Orchestrierung von Services auch das Einbinden bestehender Systeme. Erreicht wird die Umsetzung des SOA-Konzepts durch Maßnahmen wie Standardisierung und die Nutzung von unterstützenden Komponenten. Zum Beispiel stellen Web-Services eine mögliche - standardisierte - Realisierung einer SOA dar.

Eine zentrale Weiterentwicklung des Konzepts aus technischer Sicht ist eine Architekturstruktur, die als Enterprise Service Bus (ESB) bezeichnet wird und nicht nur eine Laufzeitumgebung für Services bereitstellt, sondern auch der Integration unternehmensweiter Informationssysteme dient. Diese Einbindung bestehender "Altsysteme" ist nötig, damit diese an systemübergreifenden Geschäftsprozessen teilnehmen können, um die Ziele einer SOA wie "verbesserte Geschäftsagilität" zu erreichen. Berücksichtigt man weiterhin, dass hier auch ein Paradigmenwechsel für die Unternehmensorganisation vorliegt, so werden SOA-Projekte in den nächsten Jahren eher die Regel als die Ausnahme sein.