Der Großteil der SOA-Projekte scheitert

Er hält Vorträge auf Konferenzen und in Universitäten, darunter Cambridge, Harvard und Stanford. Seine bevorzugten Themen sind Plattformen, Business Process Management und Enterprise Architecture Initiatives. silicon.de befragte Howard auf der Catalyst Conference Europe 2007 in Barcelona zur Akzeptanz der serviceorientierten Architektur (SOA) in mittleren und großen Unternehmen.

silicon.de: Herr Howard, lassen Sie uns über SOA sprechen. Über dieses Thema unterhalte ich mich auch regelmäßig mit CIOs von mittelständischen Firmen, aber auch von großen Konzernen wie etwa Siemens…

Chris Howard: Und stellen Sie dabei Unterschiede im Umgang mit dem Thema fest?

silicon.de: Und ob. Das genau ist nämlich meine Frage: Der Mittelstand verhält sich sehr zurückhaltend, was die Akzeptanz des SOA-Paradigmas betrifft. ‘Never touch a running system’ lautet deren Motto. Die wollen keine Architektur-Experimente. Firmen der Enterprise-Klasse dagegen setzen SOA bereits aktiv um.

Howard: Das sehe ich genauso. Ich vermute folgenden Hintergrund: Mittelständische Unternehmen sind einfach keine Software-Firmen, Großkonzerne dagegen schon eher. Die Citigroup etwa ist der viertgrößte Software-Hersteller der Welt! Insofern ist klar, dass sich mittlere Unternehmen nicht so schnell auf SOA einlassen wie die Großen, die das Erstellen von Software für selbstverständlich erachten.

silicon.de: Die Burton Group ist spezialisiert auf die Beratung von Großkonzernen. Auch von großen Mittelständlern?

Howard: Einige gibt es, ja. Aber der Großteil unserer Kunden gehört zu den Fortune 500 Companies.

silicon.de: Dennoch werden Sie den Einblick haben: Bahnt sich das Thema SOA zunehmend den Weg in den Mittelstand?

Howard: Ja das tut es. Der große Unterschied dabei ist: Der Mittelstand sucht viel stärker nach Wegen, seine IT auszulagern. Sie haben einfach nicht die Zeit, sich um all die verschiedenen Aspekte der IT zu kümmern und wollen das von Spezialisten erledigt wissen. Oft haben sie selbst gestrickte Programme am Laufen, dazu viele Standardprogramme – das ist oft so komplex, dass sie einfach die komplette IT outsourcen. Das ändert aber nichts an der Komplexität – sie wurde nur verschoben und vielleicht etwas billiger. ‘Mess for less’ hat das kürzlich ein mir bekannter CIO aus Philadelphia genannt.

Aber zurück zur SOA: Auch in den Großkonzernen ist die Umsetzung nicht so schnell vorangeschritten, wie wir das erwartet haben. Wir haben außerdem festgestellt, dass der Großteil der SOA-Projekte in die Hose geht. Das ist wahrscheinlich nicht gerade das, was der CIO hören will – aber es ist die Wahrheit. Neben der Technik gibt es nämlich so viele Einflussfaktoren, die ein solches Projekt scheitern lassen können. In erster Linie sind das organisatorische Aspekte: SOA bringt einen dazu, die bislang vertikal verlaufenden Prozesse in einem Unternehmen zur Seite zu drehen und sich anzusehen, welche dieser Services man herausnehmen und mit anderen teilen könnte. Das ist zuallererst keine technische, sondern eine geschäftskritische Frage. Zwei oder mehr Abteilungen müssen sich darauf verständigen, die selben Services in Anspruch zu nehmen. Man kann sich nicht sicher sein, ob dieser eine Service wirklich in verschiedene Abteilungen passt. Und um die Skalierung hinzubekommen, müssen diese Abteilungen auch noch miteinander kooperieren, oder sich zumindest abstimmen. Oder nehmen Sie die Frage der Verantwortung: Wer bestimmt über Änderungen an einem verteilt genutzten Service? All diese verschiedenen Aspekte lassen SOA-Projekte oft scheitern.

silicon.de: Man kann also sagen, SOA ist gefährlich. Oder?

Howard: Ich weiß nicht, ob man von gefährlich sprechen kann. Ich denke, SOA hat nur einen längeren Weg vor sich als wir alle – vor allem Großkonzerne – gedacht haben. Da spielt auch hinein, dass IT-Abteilungen immer in jährlichen Budgets denken und die durchschnittliche Amtszeit eines CIO gerade einmal zwei Jahre beträgt. Wird er angesichts dieser Tatsache in etwas investieren, das sich erst in drei bis vier Jahren auszahlen wird? Wahrscheinlich nicht.

silicon.de: Nicht nur Zeit und Geld sind hinderliche Variablen für die SOA – in Ihren Vorträgen erwähnen Sie auch immer wieder die Paradoxien der SOA-Entwicklung. Welche wären das und wie sehen diese aus?

Howard: Das ganze dreht sich um den Gedanken, dass man Kontrolle abgeben muss, um sie wiederzuerlangen. Entwickler in mittelständischen Unternehmen oder auch in großen Konzernen haben mehr oder weniger die Kontrolle über die Sachen, die sie so machen. Sie entwerfen, planen und setzen um. Meist dreht es sich um irgendein bestimmtes Projekt. Und plötzlich wird ihnen gesagt, dass sie sich nur noch um eine bestimmte Komponente kümmern sollen. Die sie möglicherweise gar nicht überblicken können, von der sie nicht wissen, wohin sie gehört und mit wem sie korrespondiert. Sie verlieren die Kontrolle über das, was sie machen. Das ganze aber mit dem Zweck, dass das Unternehmen nach Einführung seiner SOA eine sehr viel größere Kontrolle über die IT hat. Eben weil man sich von den alten monolithischen Applikationen verabschiedet hat. Das ist ziemlich paradox.

silicon.de: OK, also wie sollte der CIO mit der Umsetzung einer SOA-Strategie beginnen?

Howard: Das schlechteste, was ein CIO tun kann, ist ein abstraktes Projekt aufzusetzen und zu sagen: Wir machen jetzt eine SOA. Richtig wäre es, mit einem Brennpunkt im Unternehmen zu beginnen. Nehmen wir ein ganz spezifisches Problem: Sie sind der CIO einer großen Bank und wollen ihren Telefon-Support verbessern. Noch vor Jahren war der Telefon-Support weitgehend separiert vom restlichen Unternehmen – Sie kennen diese typischen Call Center -, aber heutzutage konkurrieren die Banken untereinander in Sachen Kundenfreundlichkeit. Also ist das ein Brennpunkt. Als CIO sollten Sie das zu Ihrem Projekt erklären und ein paar Services hin zum CRM-System aufbauen – natürlich ohne den laufenden Betrieb zu stören. Ihr Schiff muss weitersegeln, während sie es von Grund auf erneuern. Wenn Sie das erfolgreich durchziehen, werden alle Folgeprojekte sehr viel einfacher werden. Der schwierigste Punkt ist es, dem CFO klar zu machen, warum Sie das getan haben und vor allem: DASS Sie das gemacht haben. Weil der Betrieb ja ungestört weitergelaufen ist, kann ein Fachfremder die Veränderung in der Architektur nicht wahrnehmen. Auf keinen Fall dürfen Sie daher ein eher peripheres Problem angehen, denn dann würde erst Recht niemand sehen, dass und was Sie gemacht haben.