Ein Gespräch mit Thomas Erl

"SOA in a Box" hat eine Menge Probleme verursacht

Sebastian Meyen, Mirko Schrempp und Torsten Winterberg

Thomas Erl ist einer der profiliertesten Vordenker für serviceorientiertes Computing. Er ist Gründer des Beratungs- und Schulungsunternehmens SOA Systems. In seinen zahlreichen Büchern und Seminaren propagiert er eine herstellerunabhängige Anwendung des Paradigmas der Serviceorientierung, dies vor allem gegen ein marketinggetriebenes SOA-Versprechen, das er selbst als „the evil SOA“ bezeichnet. Eine kritische Position, die Anne Thomas Manes Anfang 2009 in Form eines Nachrufs unter dem Titel „SOA is Dead – Long Live Services“ populär machte und deren nachfolgende Diskussion zur Verabschiedung des SOA-Manifests beigetragen hat. Die Business-Technology-Redaktion und Torsten Winterberg hatten die Gelegenheit, am Tag vor der Veröffentlichung des SOA-Manifests im Rahmen des SOA-Symposiums in Rotterdam mit Thomas Erl über die Prinzipien der „guten“ SOA zu sprechen.

Herr Erl, Sie und Anne Thomas Manes sagten heute, dass die eigentliche Absicht hinter SOA die Prak-tiker nicht erreicht hat. Haben Sie den Eindruck, dass die Architekten es versäumt haben, den Wert von SOA dem Business und den Entwicklern zu vermitteln?

Thomas Erl: Das grundlegende Problem ist meiner Ansicht nach, dass die Architekten das Paradigma hinter SOA nicht verstanden haben. Es gibt einen Designansatz, eine Designphilosophie, der gefolgt werden sollte und die explizit dazu da ist, einen bestimmten Zielzustand zu erreichen. Dieser Zielzustand wird durch ein Set von strategischen Zielen repräsentiert, die mit SOA und serviceorientertem Computing assoziiert werden. Also haben Architekten sich diese Ziele zu eigen gemacht, wussten jedoch nicht, was sie zu tun hatten, um sie zu erreichen. Viele sind in die Falle einiger Anbieter getappt, die sagten „Sie können SOA kaufen“, oder der Medien, die meinten „SOA sind Web Services“. Dieses und all die anderen falsch verstandenen Konzepte führten natürlich nicht dazu, die gewünschten Ziele zu erreichen. Das alles resultierte in fehlgeschlagenen Projekten, einer Menge Enttäuschungen, und es erreichte den Punkt, an dem schließlich jemand sagte: „Das funktioniert alles nicht, lassen wir es doch einfach sein.“

Das, was Anne Thomas Manes gesagt hat, würde ich gern als „Intervention“ bezeichnen. Eine Intervention in dem Sinne, dass du eingreifst, wenn du einen Freund hast, der in die falsche Richtung im Leben geht, zu viel Alkohol trinkt oder was auch immer, und zu ihm sagst: „Ich werde dich davon abhalten – das hier ist der Weg, den du stattdessen gehen solltest.“ Und das ist es, was sie beigesteuert hat. Sie erschütterte die SOA-Welt, aber ich denke, dass viele, viele Menschen missverstanden haben, was sich hinter dieser Aussage verbarg. Viele Leute sind schon bei der Headline hängen geblieben, ohne weiterzulesen.

Aber unabhängig davon hat es geholfen, das Schiff in die richtige Richtung zu lenken. Denn es half den Leuten, zu realisieren, dass wir ein größeres Verständnis darüber gewinnen sollten, was SOA wirklich ist – eine verteilte Technologie, ein Architekturmodell.

Aber auch dieses Verständnis reicht nicht aus, weil wir den versprochenen Zielzustand damit noch nicht er-reichen. Agilität, ROI, reduzierte IT-Lasten, Kosteneffektivität – all diese langfristigen Vorteile. Auch mit dem Verständnis der Technologiearchitektur haben wir immer noch nicht die Methode, den Ansatz, um Lösungen zu bauen, d. h. Programme, die uns diesem Zielzustand einen Schritt näherbringen. Daher hat es die Aufmerk-samkeit der Leute auf die Wichtigkeit dieses Verständnisses von Serviceorientierung als einer Priorität, die über allem steht, gelenkt. Dieses Verständnis gibt einem Klarheit über das, was gerechtfertigterweise serviceorientiert ist und was nicht. Im Hinblick auf Technologien, Produkte und alles, was sonst zum Teil des eigenen Ökosys-tems werden soll. Und es gibt Klarheit darüber, was hilft, diesen Zielzustand zu erreichen, oder was eben keine Hilfe sein wird, egal was von Anbietern angepriesen wird. Diese Klarheit hat uns zu dem gebracht, was wir an diesem Morgen in der Session präsentiert haben: eine allgemeine Sicht und ein Verständnis von SOA, durch das wir diese konkreten Teile haben – das Paradigma, den Zielzustand, das technologische Architekturmodell …

Wenn Sie heutzutage über SOA sprechen, wer ist Ihr Zielpublikum?

Thomas Erl: Das ist eine gute Frage. Wenn ich auf solchen Events wie diesem hier spreche, habe ich kein spezielles Zielpublikum vor Augen – es ist, wer auch immer kommt. Bezüglich der Leute, die am Programm teilnehmen (The SOA Certified Professional Program from SOASchool.com) und ein Training oder Zertifikat bekommen, haben wir unterschiedliche Spezialisierungen wie Architekten, Analysten, Cloud Compu-ting, Security usw. Also ist da eine entsprechende Demografie, die zu uns kommt. Securityleute, Architekten usw. neigen dazu, dieses oder jenes zu wählen … Ich würde sagen, man kann sie am besten und allgemeinsten als „Praktiker“ kategorisieren.

Sie erwähnten eben, dass Architekten in der Ära der „bösen“ SOA in bestimmte Fallen getappt sind. Wür-den Sie sagen, dass dies ein Zeichen von Unreife bei den Architekten ist, diese also nicht bereit für die Probleme sind, die sie überwinden müssen? Es scheint, als würden heutzutage Leute eher zufällig Architekten – sie haben eine bestimmte Position, die sich „Architekt“ nennt, aber niemand weiß so richtig, was dieser Job wirklich ist.

Thomas Erl: Das habe ich zweifellos gesehen. Ich bin nicht sicher, ob das der einzige Typ von Architekten ist, der in diese Falle getappt ist. Ich denke, es gibt clevere Architekten und vielleicht nicht so clevere. Und manchmal geht es auch gar nicht um Intelligenz. Ich vermute einen anderen Aspekt, der zu dieser Situation geführt hat: der Widerstand gegenüber Veränderungen bzw. die fehlende Offenheit für neue Ansätze. Das ist ein Aspekt – ferner gibt es Architekten, die an OO oder EDI glauben, oder sie brauchen in Bezug auf alles, was sie tun eine Grundlage, auf die sie sich beziehen können, und da kommt plötzlich jemand und sagt: „Tja, jetzt werden wir es anders machen.“

Der Grund dafür, dass SOA in einigen Fällen für diese Leute so bedrohlich ist, liegt darin, dass die SOA-Einführung Cross-Silo ist. Es ist nicht nur diese eine Applikation, die ich auf diese Art baue. Eine ernsthafte SOA-Initiative beeinflusst einen signifikanten Teil einer IT-Unternehmung. Das kann die Dinge in einer IT-Organisationsstruktur wirklich drastisch verändern. So könnte ich die Befugnis über einige Teile einer Lösung, die ich zu bauen habe, verlieren, weil diese von einer anderen Enterprise-Architekturgruppe geleitet und entwickelt werden müssen. Und die Manager könnten die Befugnis über die Art, wie sie ihre Projektteams leiten, verlieren, weil sie jetzt neue Leute reinbringen müssen, und dann hat man noch den Fall der Standard Compliance. Das ist etwas, worüber wir in Bezug auf SOA lange Zeit gesprochen haben, aber für eine Organisation oder eine IT-Umgebung, die nicht an Standards gewöhnt ist, ist es eine große Zumutung, jetzt zu sagen „ok, wir lenken und reglementieren alles, was wir tun.“ Das macht keinen Spaß. Es gibt dann eben Regeln – dir wird gesagt, was du tun kannst und was nicht. Und auf diesem Level gibt es einfach Leute, die sagen „das ist es nicht wert“ oder „das ist nichts für mich“ oder „ich werde alles verlieren, was ich bis jetzt erreicht habe, wenn ich das tue“. Was auch immer für Gründe vorliegen, es gibt diesen Widerstand gegen Veränderung. Und manchmal wurde das mit einer anderen, falschen Idee gekoppelt, dass nämlich SOA immer Enterprise-weit sein sollte. Wenn du an den Tisch kommst, und sagst „wir werden die gesamte IT-Umgebung ändern“ und „ihr müsst alle den Regeln folgen“, dann fühlt es sich an wie Kommunismus oder Ähnliches. Diese beiden Dinge führen entweder zur Ablehnung oder zu gescheiterten Versuchen.

Deshalb war der Domain-Inventory-Ansatz so erfolgreich. Als eine Alternative zur Enterprise-weiten Ein-führung kann man SOA auch in Domains segmentieren und einführen. Standard Compliance ist etwas, das nötig ist, aber dann nur innerhalb des Bereichs einer gegebenen Domain. Wenn es innerhalb machbarer Gren-zen ist, ist es viel weniger bedrohlich. Das alles hängt zusammen mit dem Reifegrad der Praxis, der Patterns und der Prinzipien, die sich entwickelt haben und die jetzt veröffentlicht wurden und den Leuten helfen, die Möglichkeiten nachzuvollziehen.

Geschrieben von
Sebastian Meyen, Mirko Schrempp und Torsten Winterberg
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.