SOA, BPM und Enterprise Architecture

oder: erfolgreiche IT ist zu 50% Politik

Trotz aller Verheißungen – etwa einer renommierten Unternehmensberatung „30% Kostenerspanis durch Einsatz von SOA“ – sind die Segnungen von SOA in den meisten Unternehmen noch nicht angekommen. Und damit erlebt SOA das gleiche Schicksal wie all die anderen IT-Paradigmen der Vergangenheit. Tatsache ist leider, dass der Begriff “Software-Krise” bereits 40 Jahre alt ist und es seitdem zu keinen substanziellen Verbesserungen gekommen ist. Viele internationale Studien zeigen, dass weiterhin 30% aller Projekte scheitern.

Wenn es also trotz der neuen Methoden und Technologien immer noch keine substanzielle Verbesserung in der Software-Entwicklung gibt, läuft etwas grundsätzlich falsch. In der Regel wird ein kritischer Erfolgsfaktor außer Acht gelassen: der Mensch. Bereits 1994 untersuchte die Standish Group die wesentlichen Erfolgsfaktoren von IT-Projekten und zeigte, dass über 80% organisatorischer Art sind.Die Frage lautet also nicht nur, „Wie implementiere ich SOA?“, sondern auch „Wie schaffe ich eine Organisation, in der SOA erfolgreich implementiert werden kann?“.

Beispielsweise scheiterte der Aufbau einer zentralen Architekturabteilung eines großen Konzerns gerade daran, dass die erstrebte Kostentransparenz von den einzelnen Produktverantwortlichen gar nicht gewünscht war. Notwendig ist also eine Best Practice, welche SOA um organisatorische und insbesondere politische Aspekte erweitert. Da von oben verordnete Ansätze häufig in großen Organisationen versanden, hat sich als ein weiteres Verfahren die sogenannte Guerilla-Taktik als ein „Angriff von unten“ bewährt. Dieses Vorgehen sollte damit zum Survival Kit von Technologieprojektleitern gehören, die sich nicht auf den Support vom Management verlassen wollen:
- kurze Laufzeit: bei zu langen Laufzeiten ist die Gefahr von Kritik und damit des Scheiterns zu groß. Daher sollte das Projekt gegebenenfalls in kleinere Projekte aufgeteilt werden, damit es zeitnah bereit für den Abnahmetest ist und einen echten geschäftlichen Nutzen bringt.
- geeigneten Business Case auswählen: kann es dann nicht mehr als eine „Mickey-Mouse“-Anwendung vorweisen (typisches Beispiel: Reisekostenabrechnung!), fragt sich jeder Außenstehende, was dies bringt.
- niedrige Komplexität: wird es zu kompliziert, versteht es keiner – insbesondere das Management – nicht mehr.
- Abhängigkeiten reduzieren: je höher die Abhängigkeiten zu anderen Projekten, desto größer ist die Wahrscheinlichkeit von Terminüberschreitungen, Interessens-konflikten und anderen potentiellen Show-Stoppern.
- Reifegrad: es dürfen nur ausgereifte Technologien ohne Kinderkrankheiten eingesetzt werden
- Und nach dem erfolgreichem Launch: Erfolge messen: der ROI sollte durch einen Vorher/Nachher-Vergleich gemessen und ausgewiesen werden
- Erfolg vermarkten: Aktivieren von Multiplikatoren im eigenem Netzwerk und „Akquirierung“ neuer Projekte
Anstelle lang dauernder Strategiedebatten mit einer hohen Gefahr des Versandens, erzeugt ein solches Vorgehen eine sich selbst tragende Dynamik. Erfolge werden schnell messbar und der produktive Einsatz verhindert, dass die Arbeit als „Schrank-Ware“ endet.
Auch für den Projektleiter sind die Vorteile direkt spürbar: er ist Pionier erfolgreicher Technologien, die das Unternehmen und damit auch ihn nach vorne bringen.

Michael Krusche
evolving systems consulting GmbH