Implodiert der SOA-Stern aufgrund von Überfrachtung mit Erwartungen bald? Endet er als schwarzes Loch und reißt viele Investitionen mit sich? Hm... Solange SOA als eine Sache von Technologien angesehen wird, kann ich mir solche eine dunkle Zukunft durchaus vorstellen.
Ich habe natürlich nichts gegen Technologien wie Web Services, ESB und Standards wie SOAP, WSDL. Alles ganz wunderbar. Dass die sich nicht alle in gleicher Weise durchsetzen und jetzt zum Beispiel REST und POX in aller Munde sind, macht ja nichts. So läuft halt die Evolution. Sie lässt sich nicht am Reißbrett planen. Nur weil SOAP eine gute Idee war, heißt das nicht, dass es auch alle glücklich macht.
Wenn SOA scheitern sollte - wobei zunächst zu klären wäre, wie "Scheitern" eigentlich erkannt werden kann, was es bedeutet -, dann liegt das meiner Meinung nach nicht an diesen Technologien und Konzepten. Ein Messer ist nicht schuld, wenn ich mich mit ihm schneide. Meine unsachgemäße Nutzung des Messers ist dann mein Problem. Dasselbe gilt für die ESB, SOAP, WCF & Co. Ein Messer kann ich richtig und falsch nutzen. Genauso die SOA Technologien/Konzepte. Und ein Messer macht noch keine "Ente a l'orange". Für ein leckeres Mahl muss man Kochen können und nicht nur Werkzeuge haben.
Können die Unternehmen und Projektteams, die auf den SOA-Zug gesprungen sind, aber nun auch kochen? Die Industrie hat ihnen eine ganze Werkzeugpalette für SOA-Menüs in die Hand gedrückt - doch wie steht es mit dem Kochen? Da habe ich nämlich meine Zweifel, ob die Befähigung zum Kochen auch schon genauso weit verbreitet ist, wie die Werkzeuge.
Nicht, dass die SOA-Köche nicht die Knöpfe an den Werkzeugen bedienen könnten. Das lernen sie in teuren Schulungen. Mir geht es eher um eine noch grundlegendere Haltung. Als Hobbykoch kann ich auch irgendwie Messer und Pürierstab bedienen. Aber was kommt am Ende raus? Das big picture, der ganzheitliche Blick aufs Kochen, der fehlt mir. Solange ich nur irgendwie satt werden will, ist der auch egal. Aber wenn ich ein wirklich schönes Menü zusammenstellen und auch noch zubereiten will... dann muss ich einen solchen Blick haben.
Dito beim Thema SOA. Nein, bei SOA ist das sogar noch viel wichtiger. Denn Software ist soviel komplexer als selbst ein Meistergericht. Ich glaube deshalb, dass SOA solange kein wirklich breiter Erfolg wird, solange es mit bestimmten Werkzeugen und einer gewissen Softwaregröße assoziiert wird. SOA als Service Oriented Architecture zu bezeichnen, empfinde ich deshalb als kontraproduktiv. "Service" suggeriert, dass es um spezielle Technologien geht. "Architecture" suggeriert, dass damit nur ab einer bestimmten Größenordnung zu rechnen ist.
Dabei kann SOA nicht wirklich ein Erfolg werden, wenn man sich nur darum kümmert, wie Software im Großen gebaut und zusammengeschaltet werden soll. Genausowenig kann ökologisches Verhalten eine Sache von Großunternehmen allein sein. Ökologisches Verhalten beginnt bei jedem Einzelnen im täglichen Leben... und kommt dann auch bei großen Institutionen an. Auf die Softwareentwicklung übertragen bedeutet das: Solange "Serviceorientierung" nicht eine Sache jedes einzelnen Entwicklers ist, wird sie im Großen keinen nachhaltigen und breiten Erfolg haben.
"Serviceorientierung" im Kleinen, d.h. für jeden Entwickler, ist aber natürlich nach derzeitiger Definition ein Widerspruch in sich. Deshalb plädiere ich für eine Neuinterpretation des Akronyms "SOA". Ich würde es gern als "System Oriented Attitude" verstehen. "Attitude" steht dabei für Haltung, d.h. eine ganz grundlegende Sicht auf die Welt der Softwareentwicklung im Allgemeinen. Und "System" steht für eine Betrachtung von "Software als System" und zwar als komplexes System mit vielen Hierarchie-/Abstraktionsebenen. Und auf jeder dieser Ebenen muss ständig gegen die (schleichende) Zunahme von Komplexität (oder Entropie) gekämpft werden. Das ist keine Sache von Enterprisearchitekten, sondern jedes Entwicklers. Immer.
Services sind da nur ein Mittel auf einer Hierarchieebene. Komponenten sind ein anderes, kaum wirklich genutztes. Klassen ein weiteres. Solange Anwendungen aber Spaghetti-Klassenmodelle enthalten und binäre Komponenten nicht wirklich zur Strukturierung von Software eingesetzt werden und noch Unsicherheit über die Rolle eines SQL Servers, der C#-Code ausführen kann, herrscht... solange ist nicht zu erwarten, dass die bisherige SOA-Idee es schon in den Olymp der Softwareentwicklung geschafft hat. SOA ist mehr als ESB und SOAP. Wer SOA nicht als systemorientierte Haltung begreift und sie bei jedem Projekt - ob klein oder groß - von vornherein atmet, der wird keinen wirklichen Erfolg mit serviceorientierten Architekturen haben.
Meine Empfehlung daher: Wer Serviceorientierung haben will, der fange mit einer Beschäftigung mit der Systemtheorie und systemischem Denken an. Als durchaus ernüchternden Start kann ich Dörners "Logik des Misslingens" empfehlen. Das Buch macht sensibel für Komplexität.
Keine Kommentare:
Kommentar veröffentlichen