Aufruf für mehr SOA: Mehr Service-orientierte Abstraktion!

Wenn die Komplexität des Codes wächst – und das tut sie immer und überall –, nimmt auch die Anzahl der darin verborgenen Fehler zu. Dies schafft irgendwann substantielle Risiken. Um diese Risiken zu kontrollieren und um reaktive Sicherheitsmechanismen gegen Angriffe und Ausfälle implementieren zu können, strukturiert man moderne IT-Systeme in Schichten und setzt diese aus abgegrenzten Komponenten wie beispielsweise virtuellen Maschinen oder Software-Komponenten oder Prozess-Bausteinen zusammen.



Jede dieser Komponenten kapselt die Erfüllung bestimmter Aufgaben in einer Black Box mit wohldefinierter Schnittstelle. Dabei ist es ein wichtiges Designziel, funktionale Redundanz zu vermeiden (ausgenommen bei Echtzeitsystemen). Wo eine derartige Struktur noch nicht vorhanden ist, versucht man, sie künstlich zu implementieren, indem man existierende Funktionalität in virtuelle Komponenten verpackt. Dies schafft die Möglichkeit, alte Systeme «komponentenweise» durch neue, sauber strukturierte zu ersetzen.

Soweit die graue Theorie. In der Praxis endet das Black-Box-Prinzip, wo die Performance-Probleme beginnen. Und die virtuelle Zerlegung von unzerlegbar komplexen Legacy- Systemen ist ein Thema für sich. Doch unabhängig von der Schwierigkeit der Aufgabe besteht ihre Natur stets darin, die richtigen Abstraktionen zu erfinden. Abstrahieren und Modellieren sind die Voraussetzung, um technische Nachhaltigkeit zu implementieren. Einerseits hat sie das Ziel, die Implementierungsaufgabe in handhabbare Teile zu zerlegen, andererseits ist sie die Basis für ein klassifiziertes Ereignissystem, wie es für ein antizipierendes und reaktives Problemmanagement notwendig ist.



Das effektive Nutzen der Ereignisströme ist derzeit eine der grossen Herausforderungen für die Praxis. In komplexen Systemen verlangt das Problemmanagement, dass die Ereignisse verteilt gesammelt, gefiltert und in Bezug zueinander gesetzt werden. Damit dies zugleich effektiv und mit wenig Overhead geschehen kann, ist eine Ereignisontologie notwendig, die eine «schöne» und «vernünftige» Systemstruktur voraussetzt. Eine solche basiert notwendigerweise auf einer Abstraktion, die das Problemmanagement möglichst optimal unterstützt. Ist sie gegeben, dann ist die Definition der Ereignisontologie und der Ereignisfilter eine bewältigbare Aufgabe. Fehlt sie, dann sind Ontologien & Co nur Buzzwords.




Analoges gilt für das derzeit vieldiskutierte SOA. Die einen sagen, dass es SOA irgendwie schon immer gegeben habe, die anderen, dass es das noch gar nicht so richtig gibt. Grund ist: SOA-Implementierung ist eine Abstraktionsaufgabe wie andere auch. Weil uns aber das Definieren von praxisrelevanten Abstraktionen so schwerfällt, ist das Ergebnis oft bescheiden. Dazu kommt auch noch das Interesse der Hersteller, Kunden exklusiv an sich zu binden – mit proprietären Abstraktionen.




Wir sollten daraus unsere Konsequenzen ziehen. Statt immer neuer Produktschulungen, Persönlichkeits- und Kreativtrainings oder Führungskurse wäre es vernünftiger, das richtige Abstrahieren grundsätzlich zu schulen. Denn sowohl Nachhaltigkeit als auch Innovation benötigt Menschen mit der Fähigkeit zu praxisrelevantem, abstraktem Denken!