[OOP 2008] Re-use sucks - sometimes!

In dem Blogpost adressiert Ralf eines meiner Lieblingsthemen, "W-I-E-D-E-R-V-E-R-W-E-N-D-U-N-G". Da kann ich natürlich nicht widerstehen.

Vor einigen Jahren hatte ich mal bei Siemens einen Workshop zum Thema "Komponenten-basierte Entwicklung" organisiert. Da stellte sich heraus, dass in der Tat nicht (nur) Wiederverwendung sondern Adaptierbarkeit als wichtiges Thema erachtet wurde. Einer der Experten ging sogar so weit, sich darüber lustig zu machen, dass einige Firmen sich damals  intensiv mit der Bereitstellung von Wiederverwendungs-Repositories beschäftigten. Dummerweise sollte sich schon bald herausstellen, dass die "Füllung" dieser Repositories sehr zu wünschen ließ. gab es doch nicht allzu viele wiederverwendbare Bausteine, außer in einigen "ablegenen Randdomänen". Und sogar die wiederverwendbaren Komponenten zeitigten einige Probleme. Man denke an das 95%-Problem - die wiederverwendbare Komponente erfüllt fast alle Wünsche, nur einen klitzekleinen Teil hätte man gerne geändert. Vorstellungen wie die von Brad Cox Anfang der Neunziger Jahre, es gäbe irgendwann eine komplette weltweite Wiederverwendungsinfrastruktur, lösten sich schon bald wie Seifenblasen auf - Plopp!

Lustig wie sich das Thema Wiederverwendung dennoch wie ein roter Faden durch die Infomatikgeschichte zieht. Beim Erscheinen jedes neuen Paradigmas (etwa Komponenten oder neuerdings Services) verlassen die Wiederverwendungsjünger ihre Verstecke und setzen ihre Missionierungsbemühungen fort.

Ist also Wiederverwendung eine Sackgasse oder ein unerreichbares Ziel? Leider erachten viele Ingenieure Wiederverwendung als singulären, rein funktionalen Ansatz oder geben sich mit punktueller Wiederverwendung zufrieden.  Ein systematisches Vorgehen hingegen muss alle Aspekte berücksichtigen, technische, architektonische, organisatorische, prozeßspezifische. Re-use funktioniert immer dann, wenn es einen solchen holistischen Ansatz gibt. Wir sind beim Thema "Product Line Engineering" (PLE) angelangt, bei dem es um Programmfamilien geht, die auf gemeinsamen Artefakten beruhen (Wiederverwendung), aber auch teilweise unterschiedliche Anforderungen berücksichtigen (Adaptierbarkeit). In PLE gibt es eine strenge Unterscheidung zwischen den Plattformentwicklern (die für die wiederverwendbaren Artefakte verantwortlich sind) und den Anwendungsentwicklern, die auf Basis der Plattform eigene Software entwickeln. Im Prozeß werden dafür spezielle Aktivitäten integriert wie Scoping. Domain Engineering, Commonality/Variability-Analysen und Feature Modelling. Wichtige Themen wie Plattformevolution finden ebenfalls ausreichend Berücksichtigung: was zum Beispiel passiert wenn eine wiederverwendbare Komponente erweitert oder verändert wird, zumal etliche Anwendungen von diesen Komponenten abhängen?

Aus meiner Sicht bietet gerade Product Line Engineering einen vielversprechenden Ansatz, um Wiederverwendung auf stabile Beine zu stellen. Es zeigt sich aber auch sehr deutlich: Wiederverwendung ist nicht umsonst zu haben, weshalb es durchaus Szenarien gibt, in denen der Entwickler die Finger davon lassen sollte.

[OOP 2008] Gödel läßt grüßen

In seinem Blog-Posting hat Ralf mein letztes Posting zu Innovation aufgegriffen. Zum Thema Wettbewerb und Innovation möchte ich noch ein kleines Argument hinzufügen:  Meine langjährige Erfahrung als Mitarbeiter  in der industriellen F&E zeigt: in Märkten mit geringem Wettbewerb ergeben sich wenige, in Märkten mit größerem Wettbewerb dagegen viele Innovationen.

Heute ein weiteres philosophisches Thema, gewissermaßen eine harte Nuß für Nußknacker. Laut Gödel's Unvollständigkeitssatz für Prädikatenlogik höherer Stufen gibt es Wahrheiten, die sich nicht formal beweisen lassen. Douglas Hofstadter hat sich diesem Thema 1989 in seinem weltberühmten Buch "Gödel, Escher, Bach" eingehend gewidmet - im Übrigen ein exzellentes Elaborat, das seltsamerweise fast in Vergessenheit geraten ist. 

Was aber folgt aus diesem Satz für Informatiker. Ich versuche einmal, ein wenig die daraus resultierenden Implikationen zu beleuchten. Zum einen natürlich, dass formales Beweisen seine Grenzen besitzt. Demnach lassen sich Softwaresysteme nicht in ihrer Vollständigkeit auf qualitative Eigenschaften überprüfen. Das gilt natürlich auch für potenzielle Fehler, Sicherheitslücken oder Nebenläufigkeitseigenschaften. Zum anderen bedeutet es, dass emergentes Verhalten in IT-Systemen durchaus unvorhergesehene Eigenschaften zeitigen kann- späte Hoffnung für KI-Freunde also? Natürlich folgt als eine weitere Konsequenz, dass sich durch schrittweise Programmtransformation auf Basis von "Axiomensystemen" (z.B. Patterns) nicht alle (semantisch) denkbaren Anwendungen erzeugen lassen. Auch modellbasierte Ansätze haben daher Grenzen. 

Informatiker hantieren täglich mit Werkzeugen, die in Form von Programmierumgebungen oder Generatoren unterschiedlichster Coleur in Erscheinung treten.  Letztendlich verbergen sich dahinter aber syntaktische Textersetzungssysteme, denen eine (operative) Semantik zugrunde liegt. Leider, oder besser gottseidank, verdecken unzählige Abstraktionsschichten diese Tatsache. Es bleibt das Resüme: Der Allmacht von Werkzeugen und damit ihren Nutzern sind laut Gödel Grenzen gesetzt.

[OOP 2008] Eine Frage der Innovation

Heute eine eher philosophische Frage: Wie entstehen Innovationen im Software Engineering?

These: Durch Evolution im Sinne von Thomas Kuhn. Aus Paradigmen resultieren Mutationen, von denen durch Selektion (Wettbewerb) diejenigen überleben, die den veränderten Randbedingungen am besten standhalten.

Antithese: Neuerungen resultieren durch Diktatur. Denn nur Monopolisten und Trendsetter haben die Voraussetzungen, um Platz für Innovatives zu schaffen statt sich in ständigem Konkurrenzkampf zu zermürben.

Synthese: Es bedarf des Wettbewerbs der Ideen (Evolutionen) um Anzeize für Innovation zu schaffen, aber auch Leitfiguren, um Revolutionen zu bewirken und durchzusetzen. Allerdings sollte das Pendel weder zum einen noch zum anderen Extrem schwingen.

Lemma 1 ist natürlich dass sich nicht immer sofort die technologisch besten Lösungen etablieren, sondern die ökonomisch reizvollsten (Shareholder Value).

Lemma 2 besteht darin, dass sich dennoch auf Dauer die technologisch besseren Lösungen etablieren und bewähren müssen.

Contradictio: Dummerweise haben wir es an dieser Stelle nicht nur mit einer singulären Technologie zu tun, sondern mit einer ganzen Reihe von komplementären Technologien. Wie die Natur und speziell die Entwicklung des Homo Informaticus zeigt, funktionieren "Best-of-Breed" Ansätze aber nicht. Ein perfektes Zusammenspiel mittelmäßiger Komponenten ist also einem mittelmäßigem Zusammenspiel exzellenter Einzelteile in der Regel überlegen. Stichwort: Swarm Intelligence.

Die heutige Informatik hat leider zu überbordender Entropie geführt. Der Softwareengineer verliert sich daher heute in einem Netz unzähliger Technologien (SOA, BI, OO, Java, .NET, UML, DSL, AOSD... ). Jede für sich durchaus ausgereift, aber in der Summe nicht mehr vernünftig nutzbar und beherrschbar.

Es ist an der Zeit, inne zu halten. Es ist Zeit für einen holistischen Ansatz, der die Einzeltechnologien vernünftig integriert.  Es ist Zeit abseits von Konferenzen, Wettbewerb und dem dort gehuldigten Expertentum einen Schritt zurückzutreten, um zu reflektieren und zusammen wachsen zu lassen was zusammen gehört.  Auch bloße Integration kann Innovation bedeuten, ganz im Sinne der kollektiven Intelligenz.  Das bedeutet aber auch, dass eine Gruppe von Team-Playern einem Team aus Individualisten überlegen ist.  Für erfolgreiches Softwareengineering bedarf es daher beide Arten der Integration, die auf technologischer Ebene aber auch die soziale.

[OOP 2008] Bubbles don't crash

Auf manchen Powerpoint-Folien erscheint SOA als allmächtiges Wunderwerkzeug für Jedi-Ritter. Zu enge Kopplung? Da hilft nur SOA! Integrationsprobleme in heterogenen Umgebungen? Natürlich nur mit SOA zu beseitigen. Das erinnert mich doch bedenklich an Alchimistenträume. Bisweilen ziehen dann die selbsternannten SOA-Experten und andere Abenteurer durch die Management-Etagen und verkünden ihre Heilsbotschaft. Nur gelegentlich kommen kritische Stimmen an die Oberfläche und berichten über Fallstricke und Probleme - wobei mir da gerade in den Sinn kommt, dass "Probleme" heutzutage  "Herausforderungen" heissen. Es ist ja so simpel: man nehme den bisherigen Entwicklungsprozess, die bisherige Organisation, adaptiere lediglich Applikationsstellen durch Service-Schnittstellen, und lasse einen SOA-Sturm durch alle Abteilungen fegen - "resistance is futile".  Schon ist alles angerichtet! Dummerweise lecken bereits so manche Organisationen gegenwärtig ihre Wunden, nachdem sie allzu leichtfertig auf die SOA-Karte gesetzt haben. Es ist wie immer im Leben: keine Technologie kann uns das Nachdenken abnehmen, aber bei jeder neuen Technologie ignorieren wir diese Tatsache von neuem. Was Grady Booch dereinst zum Thema Werkzeuge geäußert hat ("a fool with a tool is still a fool") hat nach wie vor Gültigkeit und dürfte sich als Naturgesetz qualifizieren. Da fällt mir auch der gute alte Witz ein: Treffen sich mehrere Wissenschaftler und diskutieren ob Gott ein Biologe, Physiker oder SAO-Experte ist. Da meint der Biologe, es sei ja wohl offensichtlich, dass Gott Biologe sei, denn immerhin habe er den Menschen als Krone der Schöpfung erschaffen. Daraufhin entgegnet der Physiker, dass das ja alles sein möge, aber am Anfang hätte Gott doch aus dem Chaos die Natur kreiert. Worauf der SOA-Experte nur süffisant lächelt und sagt "Und woher, glaubt ihr, stammt das Chaos?". Zum Entwickeln umd Umsetzen einer erfolgreichen SOA-Strategie bedarf es mehr als nur Powerpoint-Folien und warmer Worte. Fallstricke lauern in den verschiedensten Bereichen, seien es organisatorische, prozessbedingte, technische, architektonische, oder herstellerspezifische. Dem Chaos lässt sich nur mit einem systematischen Vorgehen begegnen. Und wie von mir bereits des öfteren in den Raum gestellt: SOA = Product Line Engineering.   Mit anderen Worten: SOAP und Co mögen jedes für sich einfach sein, aber das lässt sich nicht auf das SOA-Paradigma als holistischer Ansatz übertragen, dessen Implikationen bis in die IT-Strategie von Unternehmen reicht. In meinem SOA/Microsofttechnologien-Tutorial auf der OOP werde ich daher nicht nur die netten neuen Spielzeuge vorstellen, sondern auch ein paar Pitfalls und Guidelines adressieren. Wie gesagt: bubbles don't crash!