Workshop auf dem "Value Chain Forum" der Hochschule St. Gallen

Service-orientierte Architektur - aber wie?

11.06.2004
ST. GALLEN (qua) - Mit der Ankündigung ihrer "Enterprise Service Architecture" (ESA) hat die SAP nun auch ihren Beitrag zum Thema "Service-orientierte Architektur" geleistet. Kaum ein IT-Verantwortlicher kommt mehr um eine Auseinandersetzung damit herum. Den Stand der Diskussionen dokumentierte ein Workshop auf dem "Value Chain Forum" der Hochschule St. Gallen (HSG).

"Konkrete Anforderungen an die System- und Prozessarchitekturen der nächsten Jahre erarbeiten und mit den Plänen der Softwareanbieter abgleichen" - mit solcher Zielsetzung hatte sich eine Handvoll Tagungsteilnehmer zum Workshop "Architekturen" zusammengefunden. Allerdings ließ sich dieses Anliegen nur teilweise verwirklichen. Denn die Workshop-Moderatoren - HSG-Professor Hubert Österle und die am Institut für Informations-Management (IWI) tätige Projektleiterin Christine Legner - stellten ihr Konzept schon bald zurück: Da sich unter den Workshop-Teilnehmern das SAP-Vorstandsmitglied Peter Zencke befand, drehte sich die Diskussion zumindest zeitweilig vor allem um das ESA-Konzept und die "Netweaver"-Produkte des größten deutschen Softwareanbieters.

Kombinierbare Funktionsbausteine

Eine Service-orientierte Architektur, kurz SOA, zeichnet sich dadurch aus, dass sie die Aufteilung der bislang monolithischen Applikationen in unterschiedlich kombinierbare Funktionsbausteine ("Services") erlaubt. Auf der technischen Seite ist dazu eine Integrationsplattform notwendig, die zumeist einen Web Application Server, ein Werkzeug für die Enterprise-Application-Integration (EAI) und eine Portalsoftware umfasst. Sinnvolle Ergänzungen sind Tools für ein übergreifendes Daten-Management sowie für die Modellierung und die Ablaufunterstützung von Geschäftsprozessen.

Eine solche Architektur lässt sich selbstverständlich auch anders als auf der gerade angekündigten und erst ansatzweise konkretisierten SAP-Plattform (siehe www.computerwoche.de/go/80115061) erstellen. Beispielsweise streben IBM unter dem Titel "Webspere" und Microsoft mit der .NET-Plattform beziehungsweise dem "Biztalk"-Server ebenfalls danach, die neuralgischen Punkte der Unternehmens-IT unter Kontrolle zu bringen. Auch Infrastrukturspezialisten wie Bea Systems und Sun Microsystems sowie die Anbieter von EAI-Systemen, darunter Tibco, Seebeyond und Vitria, mischen in diesem Markt mit.

Effizienz gegen Integrationsaufwand

Den Anwenderunternehmen verspricht diese neue Art von IT-Architektur - dank der wieder verwendbaren Services - ein Mehr an Effizienz. Es wird jedoch durch einen höheren Integrationsaufwand erkauft. Wie die St. Gallener Wirtschaftswissenschaftler in einem jüngsten Forschungsprojekt feststellen mussten, nimmt die Zahl der Schnittstellen innerhalb einer SOA nicht ab, sondern zu.

Auch deshalb zögern viele Unternehmen, auf den SOA-Zug aufzuspringen - zumal die Produktankündigungen der Anbieter häufig noch wenig Konkretes zu Tage fördern. Doch ignorieren lässt sich das Thema auch nicht mehr. Zumindest die Teilnehmer des St. Gallener Workshops hatten sich bereits intensiv damit auseinandergesetzt. Dabei waren ihr Erfahrungsstand und ihre grundsätzliche Strategie erwartungsgemäß sehr unterschiedlich. Die Spannbreite reichte von der bewussten Entscheidung, wo immer möglich auf SAP-Technik zu bauen, bis zum expliziten Bemühen, SAP-eigene, also proprietäre Bausteine weitestgehend zu vermeiden.

Allen gemeinsam war eine grundsätzliche Skepsis gegenüber den Versprechen und Motiven der Herstellerseite. Auf breite Zustimmung stießen Aussage wie: Die viel zitierte Offenheit der Systeme sei zumindest fragwürdig, und die Anbieter verfolgten eine "Lock-in"-Strategie. Das Verdienst der originellsten Formulierung gebührte Thomas Vogel, zuständig für Anwendungsinfrastruktur und -architektur beim Pharmakonzern Novartis in Basel: Aus seiner Sicht stellen die Architekturangebote einiger Softwareunternehmen - hier sprach er den SAP-Vorstand Zencke direkt an - "Hummerfallen" dar: "Man kommt leicht hinein, aber nicht mehr hinaus."

Als Beleg für diese These mag das Beispiel des Flughafenbetreibers Fraport AG dienen. Eigentlich hatte das Unternehmen keinen Bedarf für einen Web Application Server angemeldet, sondern eine Lösung für ein drängendes Problem gesucht: die zuverlässige Wartung der Brandschutz-Klappen auf dem Frankfurter Flughafengelände. Das von SAP vorgeschlagene und als tauglich befundene System basiert auf der mobilen Erfassung von Funkfrequenz-Signalen sowie einer Auswertungs-Infrastruktur, die mit den aktuellsten Produkten des Anbieters - darunter dem "Web AS" - operiert (siehe www.computerwoche.de/go/80113206). Auf diese Weise kam Fraport zum ersten Netweaver-Produkt.

Will die Fraport AG ihre künftige IT-Architektur nicht voll und ganz auf SAP-Software aufbauen, so muss ihr IT-Management demnächst eine herstellerunabhängige Architektur definieren. Darin sollten sich die vorhandenen und die angekündigten Produkte der SAP, aber auch die Tools anderer Anbieter integrieren lassen. Die Hoffnung, auf dem zweitägigen Workshop den Stein der Weisen zu finden, musste Ulrich Kipper, stellvertretender CIO des Flughafenbetreibers, bald begraben. Doch immerhin gelang es ihm und seinen Mitdiskutanten, einige der hauptsächlichen Problemstellen zu identifizieren:

- Auf welche Weise lässt sich die Komplexität einer Service-orientierten Umgebung bewältigen? Selbst SAP-Vorstand Zencke bekannte: "Ich habe einen Mordsrespekt vor der Komplexitätsfalle." Deshalb rate er seinen Kunden, "nicht gleichzeitig jedes Fass aufzumachen". Und Kipper bestätigte: "Ich muss die Services begrenzen, sonst öffne ich die Büchse der Pandora."

- Welche Granularität sollten die Services aufweisen? Die Frage, ob ein Tool beziehungsweise eine Applikation als Ganzes eingestöpselt oder in einzelne Bestandteile zerlegt werden soll, lässt sich nicht generell beantworten. Effizienzgewinn und Integrationsaufwand müssen in jedem Fall gegeneinander aufgewogen werden.

- Wieviel Flexibilität darf das IT-Management zulassen? Einer der Vorteile einer Service-orientierten Architektur besteht darin, dass sie die Anpassung der Applikationen erleichtert. "Das Problem ist nun, die Wasserlinie zu definieren, unterhalb der nichts verändert werden darf", stellt Novartis-Manager Vogel fest.

- Wie wird die Migration aussehen? Zuerst einmal muss geklärt werden, wohin überhaupt migriert werden soll, gab Österle zu bedenken. "Wir dürfen nicht von den Powerpoint-Slides der Anbieter ausgehen", warnte der Hochschullehrer, der auch als Geschäftsführer der Unternehmensberatung The Information Management Group (IMG) fungiert. Zencke stellte klar, dass es von der SAP-Seite keinen "Big Bang" geben werde. Jedes Unternehmen müsse den Einstiegspunkt dort wählen, wo es einen Payback erwarte.

- Wann ist der richtige Zeitpunkt, um in die neue Technik einzusteigen? Allzu große Eile könnte sich als kontraproduktiv herausstellen, erinnerte Vogel seine Kollegen: "Es sind schon Firmen kaputt gegangen, weil sie SAP zu früh eingeführt haben". Wer unerprobte Technik "auf Hauen und Stechen" ins Haus hole, setze sich der Gefahr aus, Werte zu vernichten, anstatt sie zu schaffen. Der Universitätsdozent und Unternehmensberater Andreas Hunziker dagegen mahnte, nur ja nicht die Hände in den Schoß zu legen. Wer überhaupt keine Vorbereitungen treffe, stehe in zwei Jahren möglicherweise als Business-Verhinderer da.

- Wie lassen sich Unternehmensstandards einhalten, wenn die neue Technik mit den aktuellen ERP-Modulen ausliefert wird? Diese Frage spielte vor allem bei der Diskussion um Benutzerverwaltung und Berechtigungskonzepte eine Rolle. Hier sei es notwendig, unmissverständlich klarzustellen, was wie realisiert werden solle, so der Tenor. "Prinzipielle Architekturentscheidungen sind jetzt zu treffen, sonst laufen die Systeme in Inkonsistenzen", konstatierte Vogel. Wie Kipper ergänzte, erfordert das Disziplin: "Es erinnert an einen frisch gekochten Pudding, der erst in drei Tagen gegessen werden darf."

- Mit welchen Argumenten lässt sich die neue Architektur der Business-Seite vermitteln? "Es gibt keine Kundenanforderung nach Web-Services", so Georg Friedrich Henke, Abteilungs-Manager IT-Anwendungen bei der Beiersdorf Shared Services GmbH in Hamburg. "Die werden auch nicht kommen", entgegnete Vogel. Was die Anwender wollten, seien integrierte Prozesse. Und die IT sollte auf dieser sachlichen Ebene kommunizieren.

- Wo liegt der Return on Investment einer SOA? Über diesen Punkt sollten sich die Unternehmen nur ja keine Illusionen machen, stellte Hunziker klar: "Es wird zunächst eher teurer". Schließlich müsse die Infrastruktur erst einmal aufgebaut werden.

- Welche Fähigkeiten und Organisationsformen erfordert eine SOA innerhalb des IT-Bereichs? "Wir müssen unsere Hausaufgaben machen", feuerte Beiersdorf-Manager Henke sich selbst und die anderen Workshop-Teilnehmer an. Dazu gehöre vor allem ein angemessenes Skill-Mangement. Unternehmensberater Hunziker fasste das Problem in einer rhetorischen Frage zusammen: "Ist unsere interne IT-Organisation eigentlich Web-Service-fähig?" Seiner Erfahrung nach herrscht heute noch eine technikorientierte Struktur vor. Eine Organisation anhand von Business-Objekten sei eher die Ausnahme.

Was also ist hier und heute zu tun? - Einig waren sich die Diskussionsteilnehmer nur darin, dass sie sich proaktiv mit den den Möglichkeiten der SOA auseinandersetzen müssen. Gern hätten sie eine "Roadmap" oder zumindest eine Auswahl von Einstiegszenarien mitgenommen. Doch solche Ergebnisse lassen sich nicht über Nacht erzielen. Einige der vertretenen Unternehmen erwägen deshalb die Einrichtung einer ständigen Arbeitsgruppe, an der laut Oesterle auch Allianz, Audi, BMW, Migros und ZF ihr Interesse bekundet haben.

Hier lesen Sie ...

- warum sich Architektur-Verantwortliche baldmöglichst mit dem Thema SOA auseinandersetzen müssen,

- welchen Einfluss die ESA-Ankündigung der SAP auf die Diskussion nimmt,

- was die Anwender unter der "Hummerfalle" verstehen,

- welche Fragen und Probleme die architektonische Evolution Richtung SOA im IT-Management auslöst.

Value Chain Forum

Wenige Keynote-Vorträge und viel Zeit für intensive Kleingruppen-Arbeit - darin unterschied sich das Konzept des "Value Chain Forum" von dem gängiger Konferenzen und Symposien. Die Arbeitsgruppen bildeten sich aufgrund bestimmter Interessenschwerpunkte - "Seamless Customer Service", IT-Architektur, Sourcing in der Finanzindustrie oder Wehrbeschaffung - beziehungsweise aus Unternehmen einer ganz konkreten Wertschöpfungskette. Beispiele für letzteres sind der von BMW initiierte "Automotive"-Kreis und der Workshop "Repair Logistics" um den Schweizer Transport-Dienstleister Setz. Moderiert wurden die Arbeitsgruppen von Forschungskräften der Hochschule St. Gallen (HSG). Als Sponsoren des Forums engagierten sich die von HSG-Professoren gegründete Unternehmensberatung The Information Management Group (IMG) sowie der Softwareanbieter SAP AG.