SOA als Unternehmensaufgabe

Zukunftsmusik

20.09.2008
Noch sind Service-orientierte Architekturen für viele Unternehmen Zukunftsmusik. Aber Prof. Walter Brenner von der Universität St. Gallen und Mathias Kaldenhoff von Oracle sind sich einig: Die Partituren werden jetzt geschrieben.

CIO: Die Modernisierung der IT ist eine Daueraufgabe. Wo fängt dabei SOA an?

Prof. Walter Brenner, Direktor des Instituts für Wirtschaftsinformatik an der Universität St. Gallen: "SOA befindet sich heute noch in einem frühen Stadium der Entwicklung: Im Moment geht es noch um den Beweis der Machbarkeit..."

Prof. Walter Brenner: Modernisierung gehört zu den Grundaufgaben der IT. Und dabei ist es dem Benutzer egal, ob eine Anwendung auf SOA als technischer Infrastruktur läuft oder nicht. Er will einen bestimmten
Service, mit einer bestimmten Qualität zu einem tragbaren Preis. SOA kommt ins Spiel, wenn es darum geht, Flexibilität zu erzielen oder externe Services einzubinden. Aber es ist nicht zwingend, dass jede IT-Modernisierung mit SOA zu tun hat.
Mathias Kaldenhoff: SOA ist ein probates Mittel, um das Business Execution Gap aufzulösen. Dafür muss ich jedoch zunächst die Infrastruktur modernisieren und bereitstellen.
CIO: In seinem Artikel skizziert Mathias Kaldenhoff ein Vier-Phasen-Modell für die Einführung von SOA. Ist das, Herr Prof. Brenner, auch Ihr Modell?
Brenner: Ich halte das Modell für geeignet, um grundlegende Zusammenhänge auf dem Weg in eine andere Infrastruktur-Welt, in eine SOA-Welt, aufzuzeigen. Ich finde vor allem die Phase vier bemerkenswert, denn Kaldenhoffs Modell basiert ja darauf, dass es heterogene Softwarelandschaften geben wird. Ist das wirklich in Ihrem Sinne?
Kaldenhoff: Wir verschließen uns nicht der Tatsache, dass wir kein grünes Feld beackern. Und in Deutschland können wir auch in SAP-dominierten Unternehmen eine Verbindung zu Best-of-Breed-Lösungen schaffen, die nicht von SAP kommen.
Brenner: Es ist nicht nur die Frage, dass SAP-Shops auch andere Module brauchen könnten. Gerade über das Internet kommt eine ganze Reihe neuer Services und Module. Ich glaube, neben dem internen Treiber, der Schere zwischen dem Wunsch nach schneller Produkteinführung und Altsystemen, die genau das behindern, gibt es einen zweiten: die wachsende Anzahl von Softwarelösungen und Services aus dem Internet, die Unternehmen fortschrittlich in ihre Landschaft einbinden.
Kaldenhoff: Dabei spielt Oracle eine wichtige Rolle: Wir sorgen über die Verbindung dieser heterogenen
Welten für mehr Business, also letztendlich für agilere Unternehmen. Oracles Philosophie ist es zudem, dem Markt Industriereferenzmodelle – wir haben über 268 Stück – zu bieten; wir nennen das Application Integration Architecture und bieten damit PreBuild-SOA – vorgefertigte SOA-Konzepte, die für verschiedene Branchen passen und quasi modular verwendet werden können.
CIO: Welche Rolle wird Software-as-a-Service in diesen heterogenen Märkten spielen?
Brenner: Ich glaube, dass SaaS eines der mächtigsten Modelle ist, an dem wir im Moment arbeiten, und dass ein Teil der Potenziale der Serviceorientierung erst mit SaaS umgesetzt werden kann. Ich glaube aber auch, dass die Heterogenität der Softwarelandschaft eher noch zunehmen wird, wenn wir immer mehr Saas haben.
Kaldenhoff: Oracle geht davon aus, dass die Entwicklung zu Software-as-a-Service noch mindestens zehn
Jahre andauern wird. Aber wir sind schon heute darauf vorbereitet: Wir haben über Akquisitionen in den vergangenen Jahren ein umfassendes Infrastruktur-Portfolio geschaffen, aber auch gleichzeitig die für uns relevanten Industrieprozesse eingekauft.

CIO: Oracle bereitet sich also jetzt auf einen Zukunftsmarkt vor. Heißt das umgekehrt, dass die Unternehmen sich im Moment wenig mit SOA oder SaaS auseinandersetzen?
Brenner: Die Unternehmen sind von dem Konzept SOA überzeugt und wissen, dass das „here to stay“ ist.
Gleichzeitig haben sie noch enorme Probleme, tatsächlich Lösungskomponenten SOA-gerecht einzubinden.

Mathias Kaldenhoff (Oracle): "Ich werde niemals durch reine Infrastruktur-maßnahmen ein Unternehmen SOAfizieren. Genauso wenig werde ich allein durch marktgerechte Strategiebildung eine Infrastruktur- maßnahme auslösen."

Kaldenhoff: Oft genug heißt es: Mache SOA, dann machst du es richtig. Das stimmt so aber nicht. SOAGovernance heißt, dass ich in kleinen Schritten meine Infrastruktur modernisiere, Kompetenzen aufbaue, Services dazu kaufe, Refinanzierungsmodelle entwickle.
Brenner: Es ist eine Aufgabe, die auf der einen Seite betriebswirtschaftlich konzeptionell anzugehen ist – die Services zu identifizieren, zu beschreiben, sie auch mit Komponenten, die auf dem Markt zur Verfügung stehen, zu vergleichen – und auf der anderen Seite die entsprechenden infrastrukturellen Voraussetzungen schafft. Man muss von Anfang an auf die Potenziale, Flexibilität, Standardisierung und Harmonisierung von Prozessen und Services losgehen und darstellen, dass man auf Zeit weitere Dienste aus den Internetmärkten einbauen kann.
CIO: Bedeutet SOAfizierung, dass ein Unternehmen seine Prozesse an vorhandene Services anpasst oder dass es sich die Services sucht, die zu seinen Prozessen passen?
Kaldenhoff: Beides. Ich werde niemals durch reine Infrastrukturmaßnahmen ein Unternehmen SOAfizieren,
so wie ich nicht allein durch marktgerechte Strategiebildung eine Infrastrukturmaßnahme auslöse. Aber
ich glaube, es ist die Aufgabe der IT – und wir sind nun mal auch ein Infrastrukturanbieter – sich näher zur
Strategie zu bewegen.
Brenner: CIOs stehen unter Druck: Das Geschäft fordert immer mehr Flexibilität, Innovationskraft, und
Kostenbewusstsein. Und entsprechend muss sich der CIO sehr viel mehr um die Anwender aus der Fachbereichen kümmern. Er muss Services sowie flexible und kostengünstige Dienstleistungen bieten. Wie er seine Infrastruktur regelt – so wichtig das für einen effizienten Betrieb ist – ist dem nachgeordnet.
CIO: Wer ist denn zuständig für SOA: der CIO oder der Fachbereich?
Kaldenhoff: In dem Moment, in dem ein Fachbereich die Darstellung eines Services fordert, fordert er eigentlich dessen Implementierung. Der CIO muss vor allem die Infrastruktur bereitstellen, damit der Fachbereich diese Implementierungen anstossen kann. Beide Bereiche sind involviert, aber der Auslöser kommt von der Fachabteilung.
CIO: Aber der CIO definiert die Regeln und übernimmt die Verantwortung für deren Einhaltung?
Brenner: Der CIO trägt entscheidende Verantwortung dafür, dass der Prozess in Richtung SOA zum richtigen Zeitpunkt eingeleitet wird und geordnet abläuft. Es geht darum, Prozesse anders zu dokumentieren, zu modellieren und Services zu beschreiben; festzustellen, ob man Services selber macht oder ob man sie von außen bezieht. Das sind Fragen, die der CIO für den Fachbereich zu beantworten hat. Auf der anderen Seite muss er eine Architektur durchsetzen, die für eine flexible Weiterentwicklung der Infrastruktur sorgen kann.
CIO: Diskutieren wir zum jetzigen Zeitpunkt eigentlich mehr über Serviceorientierung oder mehr über Architekturen?
Brenner: SOA fordert den Aufbau eigener Architekturkompetenz. Sie können am Ende in dieser potenziell
heterogenen SOA-Welt nur dann erfolgreich sein, wenn Sie Architekturen als Rückgrat haben. Leider haben
projektgetriebene IT-Abteilungen eher wenig Freude an Architekturaufgaben. Und genau hier liegt eine zentrale Herausforderung für SOA-Governance: Architekturen und Architekturteams aufzubauen, Architekturen zu definieren, Managementprozesse einzurichten, die diese Architekturen kontinuierlich am Leben erhalten. Ich stelle in meiner Praxis fest, dass die Bereitschaft zugenommen hat, über Architekturen zu reden. Man kriegt das Thema wieder unter, und es hören wieder mehr Menschen zu als noch vor ein paar Jahren.
CIO: Wer ist der Architekt für SOA?
Brenner: Die Business-Architektur muss sehr stark vom Fachbereich kommen, die Infrastruktur-Architekturen liefert die IT.
Kaldenhoff: Glauben Sie, dass CIOs SOA heute für ein probates Mittel halten, um ihre IT langfristig zu
modernisieren?
Brenner: Nein. Ich glaube, dass sich SOA heute noch in einem frühen Stadium der Entwicklung befindet. Ich positioniere SOA eher in der Phase des Beweises der Machbarkeit und nicht im Bereich des flächendeckenden Roll-outs.