[OOP 2008] Nach der OOP ist vor der OOP

Zwei Wochen sind bereits vergangen seitdem die OOP 2008 ihre Pforten geschlossen hat. Mit einem gewissen Abstand fällt es leichter, ein Fazit zu ziehen. Was waren dieses Jahr die thematischen Schwerpunkte, wie lautet also die Hitparade der Themen? Wenn man alles Revue passieren läßt, gehört sicherlich SOA zu den Topthemen der Konferenz und dies in allen möglichen Facetten. Aber auch das alte aber immer hochaktuelle Thema Softwarearchitekturen nahm neben Agilen Prozessen einen breiten Raum ein. Insgesamt habe ich den Eindruck, dass sich dieses Jahr die Techie-Themen der Art "Neue coole Technologie X" eher im Hintergrund hielten, während die tatsächlichen Praxisprobleme beim Software Engineering im Vordergrund standen. Ein bisschen gegen den Strom schwamm allerdings die durchaus intensive Thematisierung dynamischer Sprachen. Die gehören in den Firmen noch nicht unbedingt zum Mainstream, könnten aber bald größeren Einfluß gewinnen. Schließlich sind Sprachen wie C++, C# oder Java zwar mächtig, für einige Probleme aber viel zu unproduktiv. Was mir sehr gut geafllen hat, ist der Blick über den Tellerrand, in Form von Keynotes und Vorträgen, die sich auch Aspekten jenseits der Technik widmeten. Seien wir ehrlich, in den meisten Projekten stellt das Beherrschen von Technologien zwar eine Herausforderung dar, aber die meisten Probleme resultieren eher aus Fehlleistungen anderer Art. Insgesamt hat die OOP den Spagat geschafft, zwischen technischen und nicht-technischen Themen ein breites Spektrum abzudecken, ohne aber den roten Faden zu verlieren. Dadurch hebt sich die Veranstaltung wohltuend von den sonstigen Hardcore-Technik-Events ab.  

[OOP 2008] Back to the Future - Forward to the Past

Die OOP 2008 vorbei und schon steht die OOP 2009 vor der Tür. Was waren die Highlights der diesjährigen Veranstaltung? Eigentlich lassen sich diesmal gar nicht so richtig einzelne Themen identifizieren. War es Scrum? Oder SOA? Oder Agilität? Mir fällt die Antwort schwer, zumal die OOP eine ganze Reige spannender Themen zu bieten hatte.

Was aber noch viel spannender sein dürfte: welche kommenden Trends erwarten uns für die OOP 2009 und später? Alles nur nicht SOA oder Agilität, würde man fast sagen. Aber im Ernst wie lauten die Trendthemen für die nächste Zukunft?

Sind es dynamische  Sprachen?

Oder neue Middlewareansätze?

Oder Produktlinien?

Oder ganz was anderes?

[OOP 2008] Languages are a Programmer's Best Friends

Wer das berühmte Buch der Pragmatic Programmers kennt, dürfte sich an die Empfehlung erinnern, der Informatiker solle sich jedes Jahr eine neue Programmiersprache aneignen - wer das Buch übrigens nicht kennt, sollte es sich unbedingt anschaffen.

An diese Empfehlung habe ich mich gehalten und in den letzten Jahren Ruby, D, ein wenig Groovy sowie Lisp gelernt und mich neuerdings mit Scala beschäftigt. Nicht, dass ich jetzt täglich Projekte in unterschiedlichen Programmiersprachen anstreben würde. Jede dieser Sprachen integriert innovative Konzepte, die zu einer neuen Sicht auf die Dinge verhelfen und nicht zuletzt zu einer intellektuellen Herausforderung. Allerdings muss ich gestehen, dass ich ursprünglich vom Sprachdesign und Compilerbau komme, und dadurch zum Sprachen-Junkie mutiert bin.

Was aber könnte ich mir für 2008 vornehmen? Ein heisser Kandidat könnte Erlang sein, eine Sprache, die sich speziell für verteilte und parallele Systeme eignet. Kein Wunder, stammt Erlang doch aus den Federn vom Telekommunikationserfahrenen Joe Armstrong. Von Klaus Rohe wurde mir F# ans Herz gelegt, eine funktionale Sprache für .NET.

Gibt es noch weitere Kandidaten? Was bringt interessante Konzepte mit und was könnte in Zukunft etablierten Sprachen das Fürchten lernen? Vielleicht bekomme ich hier ja ein paar gute Tipps.

[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!