Software-orientierte Architekturen

Fujitsu verteidigt SOA-Konzepte

21.04.2009 von Stefan Ueberhorst
Die mangelnde "Wiederverwendung" von SOA-Services stellt einschlägige IT-Modernisierungsprojekte in Frage. Fujitsu Technology Solutions erklärt warum, und wie man eine "Weiterverwendung" etwa von geschäftskritischen Cobol-Komponenten mit BizXML2Cobol und BeanConnect erreichen kann.

Momentan macht sich eine gewisse Ernüchterung über die Wirksamkeit eines Wundermittels breit, das versprach, die IT-Kosten zu senken, die Flexibilität zu erhöhen und die Komplexität zu reduzieren. Tatsächlich jedoch bietet SOA, richtig verstanden und durch eine passende Infrastruktur unterstützt, erhebliche Vorteile, meint Bernhard Westermaier, Senior Product Manager bei Fujitsu Technology Solutions, ehemals Fujitsu Siemens Computers. Dazu zähle auch die viel beschworene Wiederverwendung der Services, wenn auch in einem etwas anderen Sinne als bisher behauptet.

Service-orientierte Architekturen
Stellenwert IT im Unternehmen
IT wird in der Branche Banken und Versicherungen sehr viel stärker als strategische Aufgabe verstanden (64 Prozent versus 36 Prozent). In der Logistik-Branche hat IT einen unterdurchschnittlich ausgeprägten strategischen Charakter. IT wird aber dafür überdurchschnittlich häufig ein „Wertbeitrag“ zugestanden. In der TK-Branche hingegen wird IT stärker als Kostenstelle oder als zeitlich begrenzte Projekte angesehen.
Priorisierung von IT-Themen
Hier unterscheiden sich die drei Branchen sehr grundsätzlich voneinander und auch im Vergleich zu den Gesamtergebnissen gibt es klare Unterschiede. IT-Sicherheit hat für Bankenbranche höchste Priorität. Qualitäts-Management wird überdurchschnittlich häufig in Banken- und TK-Branche genannt. SOA und BPM werden von Banken und Versicherungen überdurchschnittlich priorisiert. Die Branchen Telekommunikation und Logistik liegen hierbei ziemlich genau im Gesamtdurchschnitt.
Stand der SOA-Umsetzung
Banken und Versicherungen sind bei der SOA-Umsetzung viel weiter als andere Branchen, auch viel weiter als beispielsweise die Branchen TK und Logistik & Transport. Besonders augenfällig wird das beim Betrachten der Merkmale "Kein SOA" und "SOA bereits produktiv im Einsatz“.
Bedeutung der IT-Flexibilisierung
Hier biete sich ein entsprechend stringentes Bild. Die Flexibilisierung hat in der Finanzbranche eine deutliche höhere Bedeutung, was sich vor allem in der Anzahl der Nennungen von „sehr große Bedeutung“ widerspiegelt. Auch die Logistik-Branche misst der IT-Flexibilisierung überdurchschnittlich hohe Bedeutung bei. Die TK-Branche hingegen gibt sich sehr verhalten: etwa die Hälfte der Befragten geben geringe oder sogar nur sehr geringe Bedeutung an.
Gibt es eine Roadmap?
Dort, wo die Flexibilisierung der IT-Landschaft große Bedeutung hat, gibt es auch eine Roadmap, und das nicht nur für einzelne Bereichen, sondern unternehmensweit. Banken & Versicherungen und Logistik & Transport sind hier Branchenvorreiter.
Projektverantwortung
Bei IT-Modernisierungsprojekten ist die Projektverantwortung sehr unterschiedlich verteilt. Auffällig hier vor allem, dass die Projektverantwortung in der Telekommunikationsbranche außerordentlich häufig auf Geschäftsführungsebene liegt. Banken und Versicherungen suchen sich hier gerne einen Verantwortlichen auf Vorstandsebene.
Umsetzung der Roadmap
Je größer ein Unternehmen, desto häufiger werden Berater herangezogen. Banken und Versicherungen setzen ebenfalls überdurchschnittlich häufig externe Berater ein (was mit der Größe der Unternehmen zusammen hängen könnte). Banken und TK-Unternehmen liebäugeln überdurchschnittlich häufig mit SaaS-Modellen.
Die wichtigsten Ziele
Letztendlich geht es in allen Branchen darum, für mehr Transparenz und Felxibilität zu sorgen und dabei am besten gleichzeitig noch die IT-Betriebskosten zu senken. Bei der Zielfokussierung kann man aber abhängig von der Branche unterschiedliche Schwerpunkte feststellen.
Bedeutung von IT-Governance
IT-Governance hat für die Finanzbranche eine größere Bedeutung als in anderen Branchen. Dies gilt in ähnlicher Form auch für die Logistik-Branche: zwei Drittel der Befragten messen dem Thema zumindest große Bedeutung zu. Die TK-Unternehmen hingegen schätzen die Sachlage rund um IT-Governance deutlich anders ein.
BPM-Umsetzung
Banken und Versicherungen sind bei der Umsetzung von BPM im Unternehmen schon sehr weit. 32 Prozent sprechen schon von einem vollständigen Prozess-Management. Die TK-Branche ist nicht sonderlich BPM-affin: umgesetzt ist BPM allenfalls für reine IT-Prozesse. Die Branche Logistik & Transport liegt dagegen eher im Branchen-Gesamtdurchschnitt: allerdings scheint die Branche offensichtlich beim BPM für Geschäftsprozesse weiter zu sein als andere Branchen.
SLAs zwischen IT und Fachbereichen
Auch bei SLAs üben Banken und Versicherungen eine Vorreiterrolle aus. In der Logistik-Branche hat man aber ganz offensichtlich die Zeichen der Zeit erkannt: Hier gibt es überdurchschnittlich viele Unternehmen, die bereits SLAs umgesetzt haben, und noch mehr Unternehmen, die sich zumindest in einer konkreten Planungsphase befinden. Zwei Drittel der befragten TK- Unternehmen verneinen die Frage nach vereinbarten SLAs.

Denn die Herausforderung bleibt: Unternehmen müssen ihre IT flexibler gestalten, um sie schneller an sich ändernde Geschäftsanforderungen anpassen zu können. Insofern ist das Konzept von SOA, einzelne Anwendungen in modulare Softwarekomponenten (Services) zu kapseln, die sich nach Bedarf neu kombinieren lassen, auf den ersten Blick einleuchtend. Die Orchestrierung, das heißt die Zusammensetzung der einzelnen Bausteine zu durchgängigen Abläufen und Verfahren, muss dabei auf der fachlichen Ebene der Geschäftsprozesse erfolgen. Diese Anforderung relativiert allerdings laut Westermaier die Möglichkeit, die Services in einem großen Maßstab wiederzuverwenden. Damit stehe einer der großen, von vielen Anbietern bislang postulierten SOA-Vorteile auf dem Prüfstand.

SOA-Services oft zu komplex für Wiederverwendung

Auf der Geschäftsebene geben nur grob granulare Services mit umfangreichen Funktionen Sinn, die für den Anwender relevant und handhabbar sein müssen. Ihn interessiert beim Anlegen neuer Kundendaten beispielsweise nicht, welche Detailfunktionen dabei zu berücksichtigen sind, ob die Namen mit beliebigen Zeichen geschrieben werden können, die EU-Richtlinien eingehalten sind etc. Das ist alles vorausgesetzt und muss automatisiert ablaufen. Insofern sind die Services in der Regel zu komplex für einen hohen Grad an Wiederverwendung. Sie kann besser auf einer Ebene unterhalb von SOA stattfinden, da sich bestimmte Bausteine bei der Implementierung eines Service öfter nutzen lassen.

Wiederverwendung wird auch dann zum Thema, wenn man aufgrund von Fusionen oder neuen Verfahren Änderungen in den Geschäftsprozessen vornehmen muss. Dann ist es nicht notwendig, den ganzen Prozess neu aufzusetzen, sondern einzelne Services lassen sich in die neuen Prozesse "mitnehmen". Hier werden auch Kosten eingespart, so der Fujitsu-Experte, allerdings als Wechsel auf die Zukunft und nicht im Moment der Implementierung einer SOA. Insofern solle man eigentlich eher von Weiter- statt von Wiederverwendung sprechen.

SOA-Mehrwert liegt in der Analyse

Es ist also kein Wunder, dass die Ernüchterung über SOA viel damit zu tun hat, dass die erhoffte Wiederverwendung der Services und damit auch die innerhalb der IT prognostizierte Kostensenkung weitgehend ausgeblieben sind. Hier sollte man laut Westermaier jedoch nicht den entscheidenden Mehrwert der neuen Architektur suchen. Dieser liege vielmehr darin, dass jedem vernünftigen SOA-Projekt die Analyse und kritische Bewertung der bestehenden Geschäftsprozesse vorausgeht, und zwar vollkommen getrennt von der IT. Dann würden sich sehr schnell die wirklichen Optimierungspotenziale des Konzepts zeigen, da erst der Blick "von oben" ein klares Bild über Sinn und Unsinn eingefahrener Abläufe, die nicht mehr hinterfragt wurden, ergibt. In einem nächsten Schritt werden dann die verbesserten Prozesse in der IT abgebildet. Das Ergebnis seien geschäftsorientierte Anwendungslandschaften, die auf Services basieren, die nicht von der IT, sondern von den Notwendigkeiten des Business vorgegeben, also fachlich begründet sind. Nur so seien Services effektive Bausteine zur Modellierung und Orchestrierung.

Dabei muss und kann man nicht alles neu erfinden. Vielmehr kommt es darauf an, vorhandene Applikationen, die sich bewährt haben und hohe Investitionen repräsentieren, im Sinn der neuen Architektur weiterzunutzen. Oft sind das Kernanwendungen, die wichtige Prozesse eines Unternehmens oder einer Behörde unterstützen. In der aktuellen Diskussion wird diese Art von Wieder- beziehungsweise Weiterverwendung im Rahmen eines SOA-Konzepts oft vernachlässigt, so die Erfahrung von Westermaier.

Mehr zu SOA

Werkzeuge für die Cobol-SOA-Integration

BeanConnect ist ein Adapter zwischen J2EE-konformen Applikations-Servern und Enterprise-Informations-Systemen (EIS).
Foto: Fujitsu

Für solche Aufgaben stellen Unternehmen wie Fujitsu Technology Solutions Werkzeuge zur Verfügung, mit denen sich existierende Cobol-Anwendungen beziehungsweise einzelne Bausteine in ein vorgegebenes XML-Schema ohne Funktionalitätsverluste einbinden lassen. Mit der Adapterfamilie "BeanConnect" wiederum lassen sich Anwendungen, die auf den Transaktionsmonitoren openUTM (Fujitsu) und CISC (IBM) basieren, standardkonform an Applikations-Server für die SOA-Architektur anbinden. Damit können bestehende Applikationen an neue Anforderungen angepasst und existierende Codes plattformübergreifend genutzt werden.

Dieser Investitionsschutz ist eine Form der Wieder- oder Weiterverwendung, die sich sofort auszahlt, meint Westermaier. Klar ist für den Fujitsu-Mann aber auch, dass passgenaue Applikationen und flexibelste Services wenig nützen, wenn sie nicht von einer entsprechend ausfallsicheren und dynamischen Infrastruktur unterstützt werden. Aufgrund der zentralen Organisation einer SOA-Architektur seien die Anforderungen an Stabilität und Verfügbarkeit sehr hoch, schließlich werde die Güte eines Prozesses vom schwächsten der dafür verwendeten Services bestimmt. Westermaier nimmt dies zu einem Plädoyer für Mainframes zum Anlass, da diese Plattform mit ihrer Skalierbarkeit und Zuverlässigkeit die Voraussetzungen für einen effektiven und wirtschaftlichen SOA-Betrieb biete.

Konverter BizXML2Cobol

Laut Fujitsu Technology Solutions gibt es zwar etliche Tools, die Cobol in XML überführen, aber aufgrund der unterschiedlichen Sprachmächtigkeit keines, das Cobol in ein vorgegebenes XML-Schema umsetzt. Dadurch ist beispielsweise der volle Sprachumfang von XML nicht automatisch nutzbar. Manuelle Eingriffe sind sowohl bei der Erstimplementierung als auch bei Änderungen der Cobol-Applikation sowie der Servicedefinition notwendig.

Einen anderen Ansatz verfolgt Fujitsu Technology Solutions mit "BizXML2Cobol", das voraussichtlich im Mai oder Juni freigegeben wird. Das Tool geht von einem XML-Schema aus und erzeugt daraus Cobol. Das geschieht über eine Zwischenstufe, in der einmalig mit manuellen Eingriffen die Abbildung applikationsspezifisch angepasst wird. Da hierbei die Ergebnisse der manuellen Schritte festgehalten werden und im Fall einer Änderung auf der Service- beziehungsweise der Cobol-Seite wieder automatisch eingespielt werden können, ist das Resultat besonders wartungsfreundlich.

Die Top-down-Vorgehensweise unterstützt auch weitgehend die Sprachmächtigkeit von XML. Außerdem wird sie dem Anspruch von SOA, dass Services beziehungsweise deren Definitionen auf der fachlichen Seite Sinn haben müssen, besser gerecht, heißt es von Fujitsu.

Adapter BeanConnect

Enterprise-Informations-Systeme (EIS) lassen sich mit der Adapterfamilie "BeanConnect" von Fujitsu Technology Solutions in einer Umgebung mit Standard-Applikations-Servern zugänglich machen. BeanConnect ist eine Implementierung nach der Java EE Connector Architecture (JCA) und vermittelt zwischen Application Server und den Enterprise-Informations-Systemen. Damit lassen sich bestehende Applikationen an neue Anforderungen anpassen und existierende Codes plattformübergreifend nutzen.

Auf der EIS-Seite verträgt sich BeanConnect mit transaktionalen wie nicht transaktionalen Applikationen. Die unterstützten Transaktionsmonitore sind openUTM und CICS. Der Vorteil der Bereitstellung solcher Adapter ist das Gegenstück zur J2EE-Standardisierung der Application Server. Beide reduzieren die Schnittstellenkomplexität erheblich. Die JCA stellt das Verständnis mit einem J2EE-Application-Service sicher. Umgekehrt gewährleistet ein J2EE-Application-Server, dass er mit JCA-konformen Adaptern klarkommt.