Mit beißender Ironie listet Gartner-Analyst Frank Kenney die häufigsten Gründe für gescheiterte SOA-Vorhaben auf. In einem Blog-Eintrag formuliert er einen fiktiven Entschuldigungsbrief, den Projektverantwortlichen nur kopieren und ihrem Management zu senden bräuchten. Mit dem Hintergrundwissen aus zahlreichen groß angelegten SOA-Projekten legt Kenney den Finger in die Wunde:
- “Ich habe es versäumt, unsere SOA-Initiativen mit unseren geschäftlichen Anforderungen in Einklang zu bringen”, steht in dem Brief. “Deshalb kann ich den vielen hundert Services, die wir entwickelt haben, keinerlei Wert zumessen.”
Weitere Kosproben:
- “Ich habe es versäumt, (…) ein SOA Center of Excellence, Steering Commitee oder Competence Center einzurichten.”
- “Ich habe es versäumt, das Topmanagement als Unterstützer und Evangelist für unsere SOA-Vorhaben ins Boot zu holen.”
- “Ich habe einen ESB gekauft, ohne unsere Anforderungen an eine SOA-Infrastruktur wirklich zu verstehen. (In Wahrheit war es nicht mein Fehler: Der Softwarehersteller sagte, das sei super duper wichtig)”
- “Ich habe es versäumt, meinen Entwicklern Anreize für eine Wiederverwendung von Softwareartefakten zu geben.”
- “Ich war nicht dafür zuständig, die Aktivitäten des BPM-Teams von nebenan mitzuverfolgen (…) Das sind doch zwei verschiedene Initiativen.”
- “Ich glaube fest daran, dass SOA nichts anderes als Corba oder COM ist.”
Die gute Nachricht, so lässt Kenney den imaginären Briefeschreiber formulieren, sei, dass ohnehin 70 Prozent der IT-Vorhaben scheiterten. Schuld an den Problemen sei nicht er, sondern das SOA-Konzept als solches. Das Schreiben endet mit der Bemerkung: “Im voraus möchte ich erklären, dass Cloud Computing, Virtualisierung und SaaS unter meiner Führung ebenfalls scheitern werden.”
Ich möchte Herrn Kenney nur in einem Punkt widersprechen : Er spricht von “SOA-Projekten”.
Bedauerlicherweise muss ich generell feststellen, dass häufig Projekte initiiert und gestartet werden ohne das diese mit den Unternehmenszielen und / oder der Unternehmensstrategie abgestimmt wurden.
Dann erfolgt irgendwann der Abbruch des Projektes und eigentlich weiß niemand genau warum eigentlich das Projekt nicht erfolgreich werden konnte. Es lief doch eigentlich alles ganz gut. Mitunter wird versucht solche Fehler durch gaaaaanz viel Geld noch nachträglich irgendwie wieder zu korrigieren.
Das das nicht funktionieren kann, dürfte jedem klar sein.
Jede Initiative oder jedes Projekt, dass die ganze Informatik umkrempeln will und dabei jahrelang nichts Praktisches liefert, aber dau horrende Mittel, oberste Managementaufmerksamkeit und eine neue zwanghafte Einschwörung der Fachmitarbeiter auf noch komplette unklare Nutzfunktionen fordert … also welcher Dummlack ist jetzt der Meinung, dass so etwas gut gehen kann.
Auf welchem Mond leben denn die SOA/BPM Befürworter???
SOA und Cloud Computing ist mit herkömmlichen Software Architekturen nicht sinnvoll zu begegnen. Aber ist deswegen der Ansatz von vornherein falsch? Viele Anwendungen wollen nun mal 24/7 ausfallsicher betrieben werden und müssen beliebig skalierbar sein, ohne dass operative Betriebskosten entstehen, die jeden Controller das Projekt sofort einstampfen lassen.
Wir standen vor Jahren vor exakt derselben Frage, als es um die Architektur einer komplexen Anwendung im Bereich „financial banking and exchange trading systems“ ging, und wir beschäftigten uns jahrelang intensiv mit allen erdenklichen frameworks, ohne dort eine wirkliche Lösung zu finden.
Resoa.org ist ein Open Source Architektur Ansatz, der die entscheidende Rahmenbedingungen schaffen kann, dass SOA und Cloud Computing zukünftig zusammenwachsen. Resoa erfindet nicht das Rad neu, sondern ergänzt und kombiniert vorhandene frameworks, primär aus dem Bereich Rest/JSON.
Wir benutzen ihn erfolgreich für unsere Applikationen und stellen ihn nun public mit der Überzeugung, dass sich eine größere community finden wird, die diese Idee weiterentwickeln will.