Sämtliche Marketingabteilungen von IT Firmen und (IT)-Manager von großen Konzernen reden zur Zeit von SOA. (Wer an dieser Stelle schon Pickel im Gesicht bekommt sollte besser nicht weiterlesen, da das Akronym noch öfters in dem Artikel erwähnt werden könnte. ) Für die jenigen, die im letzten Jahr kein Bullshit Bingo gespielt haben, SOA steht für Service Oriented Architecture

Warum tun die das?

Die Marketingabteilungen tun es, da SOA ein Vielzahl von Bedeutungen hat, so dass man vieles Behaupten kann ohne überprüfbar zu werden. Viele Marketingabteilungen mögen so etwas.

Die Manager haben große Problem und spekulieren darauf, dass eine SOA ihnen helfen könnte, schließlich reden alle davon, da muss es ja gut sein ... so wie XML, Applets und Objektorientierte Datenbanken.

SOA wird die Probleme der Manager aber nicht lösen. Um das verargumentieren zu können, kläre ich erstmal was SOA für mich in diesem Artikel bedeuten soll:

Applikationen machen einen Teil ihrer Funktionalität von außen aufrufbar, als Webservice oder meinetwegen auch als Corba Funktion. Also alles was unter die erste oder dritte Variante fällt, die von Martin Fowler aufgeführt wurden.

Warum hilft das nicht?

Um dies zu Befragen stellt sich erstmal die Frage nach dem Problem, das eigentlich gelöst werden soll. Diese Frage wird erstaunlich selten gestellt. Wenn sie gestellt wird ist die Antwort entweder ein verklausuliertes, "Äh, keine Ahnung, wieso fragst du mich, ich bin vom Marketing", oder etwas in der Richtung: "Dann können diese Dienste von allem und jedem ganz einfach aufgerufen werden." Oder klarer formuliert: Code soll wieder verwendet werden, und diesmal ohne Source Code, DLLs, JARs oder dergleichen hin und herzukopieren, sondern einfach in dem man den Code aufruft.

Warum funktioniert das nicht?

1. Es ist nicht wirklich den alten Ansätzen von Wiederverwendung überlegen, es gibt also keinen Grund warum es funktionieren sollte.
2. Wiederverwendung scheitert nicht an technischen Barrieren. Wiederverwendung scheitert an Kommunikationsproblemen und an mangelndem Design.

Der erste Punkt sollte eigentlich offensichtlich sein (auch für Manager, was der Teil ist, der mich an der ganzen Geschichte irritiert). Der zweite Punkt bedarf eventuell Erläuterungen. Wenn ein Entwickler ein Problem hat und es eine Bibliothek, einen Service oder ein Grummelmörpf gibt (Grummelmörpfs sind der nächste große Hype in Sachen Wiederverwendung), die dieses Problem lösen, so gibt es die folgenden Gründe diese nicht zu verwenden. In Klammern steht die von mir geschätzte relative Häufigkeit:

1. Die Bibliothek ist dem Entwickler nicht bekannt. (70%)
2. Die API der Bibliothek  passte nicht zur geplanten Verwendung (20%)
3. Die Verwendung der Bibliothek ist per Firmeninterner Richtlinie verboten, da es in einer Version von vor 13 1/2 Jahren einen Bug gab, der Probleme verursacht hat. (8%)
4. Der Entwickler möchte es lieber selber bauen (2,8%)
5. Diese wunderschöne, perfekt passende API, die der Entwickler gefunden hat liegt leider in Form von Cobol vor und der Entwickler weiß nicht, wie er darauf von Java aus zugreift. (0,2%)

Jetzt mal Spaß bei Seite, wer hat schon mal eine nennenswerte Bibliothek nicht verwendet, weil sie aus technischen Gründen nicht aufrufbar war? Wem ist das noch NIE passiert. Meldet euch in den Kommentaren!

SOAs lösen keine Probleme! Aber warum versuchen es die Manager trotzdem?

Weil das Problem der nicht Wiederverwendung gigantisch groß ist. Große Konzerne beschäftigen zig Tausend Entwickler seit Jahrzehnten, und die dabei duplizierte Code Menge ist astronomisch. Schon eine Minimale reduzierung der Duplizierung würde gewaltige Beträge einsparen.

Wie könnte man das Problem also lösen, oder wenn nicht lösen, so zumindest mildern?

Ich würde definitiv bei den oberen 3 Punkten ansetzen.

1. Abstruse Firmen Vorgaben abschaffen. Wenn ich das Geld bekommen würde, das alleine durch die Vorgabe von Websphere  als einzusetzender Webserver verbrannt wird, müsste in der Familie meiner Eltern keiner jemals wieder arbeiten.
2. Entwickler schulen, und / oder bessere Entwickler einstellen. Ich kenne eine Menge Softwareentwickler, einige davon sind in der Lage wartbaren Code zu schreiben und nur wenige sind in der Lage eine brauchbare wiederverwertbare API zu entwerfen, zu warten und weiter zu entwickeln. Das ist eine der schwierigsten Aufgabe beim Softwaredesign überhaupt. Und die Frage nach der verwendeten Technik (Interface in der einen oder anderen Sprache, oder Webservice oder oder oder) ist dabei weitgehend irrelevant.
3. Am schwierigsten, aber auch am lohnensten ist es die Bibliotheken bekannt zu machen. Ich glaube nicht, dass es eine Chance gibt dies durch irgendeine Aktion des Managements direkt herbei zu führen. Kein Befehl, keine vorgeschriebene Architektur wird dies bewirken. Denn ein Entwickler dem vorgeschrieben wird, die von ihm entwickelte Funktionalität als Webservice verfügbar zu machen, wird dies zwar tun. Er wird sich aber keine Mühe geben das so zu gestalten, dass es von anderen verwendet werden kann. Er wird sich keine Mühe machen, den Webservice bei anderen bekannt zu machen. Das bedeutet ja nur mehr Arbeit, wenn Leute auch noch mit Supportanfragen zu ihm kommen. Wenn man es aber schafft, dass es cool ist einen viel genutzten Webservice zu bauen, wenn die Kollegen nicht mit Supportanfragen, sondern mit Ideen für Verbesserungen und mit Lob zu ihm kommen, dann könnte es funktionieren. Warum also nicht einen Webservice-Bazar bauen. Eine Intranet Anwendung, in der Mitarbeiter ihre Bibliotheken, ihre Webservices, ihre Algroithmen veröffentlichen können, und für die Webservices von anderen Punkte verteilen können oder Kommentare verteilen. Wie bei DZone oder Sourceforge gäbe es dann 'die besten Bibliotheken des Monats' und dergleichen. Die Aufgabe des Managements wäre es 'nur'die Infrastruktur zur Verfügung zu stellen und den Mitarbeitern die Freiheit zu geben in diesem Bazar aktiv zu werden.

Was denkt ihr? Könnte das funktionieren? Wenn nicht, warum nicht?