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

[OOP 2008] SOA-Transformer

In einem sehr gelungenen Posting zu SOA hat Ralf Westphal auf mein Posting zu SOA-Leichtgläubigkeit Bezug genommen.

Der Punkt Flexibilität ist tatsächlich einer der problematischen Aspekte bei der Softwareentwicklung. Gerade das Erreichen einer guten Balance erweist sich als äußerst diffizil. Etwa bei real existierenden Architekturen, die allenfalls von Strategy-Patterns zusammen gehalten werden. Ein Strategy-Pattern gleicht aber der Aussage, dass sich der Architekt an der Anwendungsstelle noch nicht festlegen konnte oder wollte. Eine Häufung des Strategy-Patterns heißt demzufolge, dass er sich an vielen Stellen nicht festlegen wollte oder konnte. Weiss dieser Architekt denn überhaupt was er entwerfen möchte? Oder anders ausgedrückt: Würden sie ihm Ihre Kreditkarte anvertrauen? Ein anderer typischer Fall ist das Mediator-Pattern. Göttergleich thront der Mediator im Zentrum des Softwareuniversums. Keiner kommt an ihm vorbei, denn es kann schließlich nur einen geben. Man denke an die vielen Hub-and-Spoke Ansätze, die bei vielen Unternehmen als lebendige Leichen im Keller lauern.

Flexibilität muss geplant aber auch kontrolliert und gezielt beschränkt werden. Das Open/Close-Principle leistet hier gute Dienste. Flexible Architekturen, die sich nur an wenigen Stellen offen und damit verwundbar zeigen, zählen heute noch als seltene Spezies. Positive Ausnahmen: Eclipse und das Plug-In-Konzept, WCF und die konfigurierbaren Channels.

Da gerade SOA dem Produktliniengedanken sehr eng folgt, sind entsprechende Mechanismen um mit Variabilität systematisch umzugehen zum einen Feature Modeling und zum anderen Commonality/Variability-Analyse. Auf der Architekturebene erleichtern Patterns das systematische Behandeln der Variabilität. Und nicht zuletzt existieren Mechamismen auf der Plattformebene, wie z.B. Workflows, Rules Engines,  Plattforminterzeptoren.

Die Wahl der Mechanismen und Architekturkonzepte sollte aber mit Bedacht erfolgen. Nicht selten  experimentieren Softwareentwickler gerne mit den verschiedensten Ansätzen, die sich dann in den fertigen Systemen wieder finden.

Insofern gleicht SOA tatsächlich eher den cineastischen Transformern als ihren organischen Pendants, den Formwandlern. Soll die Architektur in Form bleiben und nicht alsbald unter Alterserscheinungen kollabieren, ist ihre vorausschauende Trans-Form-ationsfähigkeit essenziell. Minority Report läßt grüßen.

[OOP 2008] Moderne Zeiten

Kann sich noch jemand an die gute alte Zeit des Schwarz-Weiss-Fernsehens erinnern?  Damals, als die ersten Farbfernseher zu saftigen Preisen die Läden erreichten und mit neidischen Blicken betrachtet wurden? Da gab es eine Werbeanzeige in diversen Zeitschriften, die für lau eine Farbfolie offerierte, um aus dem heimischen Schwarz-Weiss-Fernseher einen Farbfernseher zu machen. Das funktionierte tatsächlich, wenn freilich die Farbzuordnung rein zufällig war und bisweilen zu grünen Gesichtern oder braunem Himmel führte.   Waren schon leichtgläubige Zeitgenossen!

Wenn ich freilich die jetzige Zeit betrachte, welcher Unterschied zu damals! Da gibt es doch glatt die neue, unwiderstehliche Welt von SOA, SaaS und ESBs. Nur leider sind die alten Anwendungen dazu noch nicht kompatibel. Voller Neid blicken Techniker und Manager daher auf das Land der unbegrenzten SOA-Möglichkeiten. Ist doch alles einfach! Man nehme eine beliebige  Anwendung und füge Web-Service-Schnittstellen hinzu. Schon ist alles angerichtet - wortwörtlich!

Die Zeiten ändern sich offensichtlich, nicht aber die menschliche Neigung, an Wunder zu glauben. Leider ist die Modernisierung von existierenden Landschaften alles andere als trivial. Es gilt, Anwendungen neu aufzubrechen und zu strukturieren, um sie an den richtigen Stellen zu integrieren. Und Integration heisst eben nicht nur Kommunikation, sondern Datenintegration, Geschäftsprozesse, Organisations- und Prozeßänderungen. Stichwort: Dominoeffekt durch inhärente Komplexität.

Das impliziert natürlich, dass ein systematisches Vorgehen essenziell ist, ebenso technisches Knowhow und Architekturkompetenz. Insgesamt sind die Anforderungen also entsprechend hoch. Kein Wunder, dass viele Modernisierungsprojekte kläglich scheitern. 

[OOP 2008] Die Zukunft von OO ist Funktional

Sprachen wie Ruby oder C# haben sich bereits in die Richtung bewegt, Neuentwicklungen wie Scala das Ziel bereits erreicht. Die Zukunft objektorientierter Sprachen heisst .... Lisp. Kompletter Unsinn? Dann lassen Sie mich ins Detail gehen. Schon lange (über 60 Jahre) existieren zwei grundlegende Paradigmen der Programmierung. Auf der einen Seite das funktionale Lambda-Kalkül und auf der anderen die prozedurale Turing-Maschine. Beide sind in der Lage, alle denkbaren und berechenbaren Funktionalitäten zu beschreiben und verarbeiten. Während die Turing-Maschine hierfür einen unendlichen Variablenspeicher nutzt, basiert das Lambda-Kalkül ganz symbolzentriert auf Funktionskompositionen und Funktionsaufruf. Nun sind die OO-Sprachen einmal, lax ausgedrückt, nichts anderes als Turing-artige Maschinen höherer Abstraktion. Funktionale Sprachen wie Lisp, ML oder Haskell hingegen beruhen im wesentlichen auf dem Lambda-Kalkül. Vorteil der funktionalen Programmierung ist zum Beispiel dessen symbolorientierter Ansatz und dessen Gleichbehandlung von Daten und Funktionen. Nachteil beispielsweise die geringere Performanz - und bisweilen das ungewohnte Programmierparadigma. In neu entwickelten Sprachen wie Scala (das im übrigen auf Java VMs läuft) lassen sich nun beide Ansätze, OO und funktionale Programmierung, miteinander kombinieren. C# 3.0 hat bewiesen, dass auch "traditionelle" OO-Sprachen sich sinnvoll um funktionale Ansätze wie Lambda-Ausdrücke ergänzen lassen. Dass dies viele Vorteile in sich birgt, beweisen die Brüder im Geiste Ruby, Scala, C# 3.0 oder Smalltalk. Natürlich werden Programmierer jetzt nicht auf Common Lisp oder Scheme umschwenken. Wohl aber dürften sie in Zukunft mit den aus diesen "Ursprachen" kommenden Konzepten konfrontiert werden. Ruby und C# 3.0 sind nur der bescheidene Anfang. Insofern kann eine Beschäftigung mit "good old Lisp" nicht schaden. Ganz nach dem Motto: Das Lamda-Kalkül ruft. Folgen wir ihm!

[OOP 2008] Architektur mit Schleife :-)

Gernot berichtet in seinem Blog-Posting über eine realistische Vorgehensweise bei der Architekturerstellung. Dem Ansatz kann ich aufgrund meiner täglichen Praxis nur zustimmen. Wobei das Bild den Eindruck erweckt, als würde man/frau zunächst eine komplette Architekturvision erstellen und dann erst in der nächsten Iteration aufgrund von Feedback die Architektur überarbeiten.

Nach meiner Ansicht funktioniert Architektur iterativ in zwei Stufen. Ausgehend von den "Requirements" und deren Klärung erfolgt zunächst inkrementell die Erstellung einer Architekturvision respektive Grobarchitektur. Jedes Inkrement umfasst zum einen Verfeinerung und zum anderen architektonisches Refactoring. Die Inkremente fangen mit den höchst prioren Anforderungen an und betten die fachliche Logik in die für nicht-funktionale Eigenschaften benötigte Infrastruktur ein. Das erfolgt schrittweise, Requirement für Requirement, bis eine Grobarchitektur bereitsteht, die einfach genug ist, um sie zu kommunizieren, aber auch stabil genug, um in die nächste Phase einzutreten, nämlich zur inkrementellen Erstellung der Feinarchitektur.   

Wichtige Richtlinien dabei sind z.B.:

• Learning from Failure
• Strategisches Design vor fachlichem Design

Die beiden Phasen der Architekturerstellung verfallen also nicht der Versuchung des "Big-Bang"-Ansatzes.

Wichtig ist aber genauso die Vorgabe von Leitlinien am Anfang. Nicht umsonst definieren Booch, Jacobsen, Rumbaugh, dass Architektur die Definition der Subsysteme und ihrer Zusammenarbeit umfasse, aber aauh die dabei zugrunde gelegten Design-Richtlinien (guiding principles).

Schwieriger gestaltet sich allerdings die Architekturerstellung beim Product Line Engineering, bei dem im Domain Engineering die Plattformdefinition erfolgt, und erst im Application Engineering die Produkterstellung. Hier werden auf einmal ehemals taktische Aspekte wie Variabilität zu strategischen Aspekten, die gründlicher Maßnahmen bedürfen. Etwa Scoping, C/V-Analyse, Domain Driven Design und Feature Modelling.

Ich bin gespannt wie Gernot das Thema Product Line Engineering sieht.

[OOP 2008] SOA ist nicht (nur) Technologie

Ralf hat auf meine Gedanken zu SOA mit einigen guten Gedanken geantwortet und empfiehlt Systemtheorie und systemisches Denken. Er gibt zu bedenken, dass SOA nicht nur Denken im Großen bedeuten kann. Nachdenken hat natürlich noch nie geschadet, auch nicht beim Programmieren :-) Mein Beobachtungen suggerieren, dass die Probleme auch woanders liegen, weil zum Beispiel SOA oft nur als weitere Middleware begriffen wird, nicht als Paradigma. Ist SOA eine schlichte Evolution von OO? Reicht es, existierende Applikationen durch Service-Wrapper zu SOA-enablen?

Aus meiner Sicht ist SOA eine Vielzahl von Dingen:

• Es ist keine Technologie, sondern ein Architekturparadigma.
• SOA ist nicht gleich WS-*.
• SOA erfordert Änderungen in Organisationen und Prozessen. Stichwort: Governance. Im Prinzip sind SOA-Entwicklungen Produktlinien.
• SOA ist keine Middleware, die bisherige OO Middleware ersetzt. Es ist eine Fortentwicklung von Message-Oriented Middleware.
• SOA ist eine Integrationstechnologie.

SOA lässt sich daher auch im Kleinen nutzen, betrachtet man es als Paradigma.

Sobald ESBs, SOA Frameworks und WS-* in den Mittelpunkt rücken, ist es ein Ansatz für grosse Systeme. Allein schon deshalb, weil die Komplexität von ESB-Lösungen und SOA Frameworks den Rahmen von Kleinprojekten sprengt.

Zur Umsetzung des SOA-Gedankens ist ein holistischer Ansatz gebracht, der auf folgenden Säulen beruht:

• Standardisierung: Es solte möglichst auf Standards gesetzt werden, nicht auf Eigengewächse. Es sei denn, ein proprietärer Ansatz wird angestrebt.
• Markt und Hersteller: Zu beachten ist der volatile SOA-Markt, der ständigen Änderungen unterworfen ist. Welche Standards unterstützen die Hersteller. Welche Produkte sind reif und welche noch nicht?
• Architektur und Domäne: Welche Anforderungen ergeben sich hinsichtlich der Domäne? Welche Technologien mappen am besten auf diese Anforderungen. In einem top-down Ansatz müssen grobgranulare Dienste aus den Geschäftsanforderungen abgeleitet werden. Feingranulare Dienste sollten nicht direkt für Clients zugreifbar sein. Service-Aufrufketten sind zu vermeiden, Versionierungsaspekte und verschiedene Service-Versionen zu berücksichtigen. Best Practice Ansätze (Patterns) bieten grosse Hilfe. Für die Integration von Legacy Software ist ein geplantes Vorgehen notwendig.
• Prozeß und Organisation: Die Organisation ist dem SOA-Paradigma entsprechend zu ändern, etwa Einteilung in Anwendungs- und Serviceentwicklung. Governance-Aspekte müssen durch eigene Teams abgedeckt werden, speziell bei SOA im Grossen. SOA fängt oben an bei den Anforderungen. Ein bottom-up-Ansatz ist lediglich für Integrationsaspekte zulässig. Jegliche Art von Big-Bang-Ansatz ist kontraproduktiv. Eine schrittweise Transition ist hingegen empfehlenswert.
• Technologie: Herstelleraussagen hinsichtlich SLAs und NFRs sind gründlich zu verifizieren, etwa durch Prototyping. SOA darf nicht als Middleware betrachtet werden. Den Fehler, in Point-to-Point Kommunikation zu verfallen, sollte man vermeiden, schon wegen der höheren Komplexität.

Das sind natürlich nur einige Punkte. Wir sehen, ein systemisches Vorgehen ist durchaus vorteilhaft. Dabei ist aber nicht nur die IT-Abteilung involviert sondern alle Stakeholder. SOA ist nicht einfach sondern sehr komplex, weil es schon heute Ansätze des Ultra Large Scale Computing vorweg nimmt, sich aber auch im Kleinen umsetzen läßt. Gerade diese Mischung sorgt für Sprengkraft.

Wer also sein Projekt unter Garantie gegen die Wand fahren will, greife jetzt zu einem SOA Toolkit nach Wahl und fange einfach an, darauf loszuprogrammieren.

[OOP 2008] Das GaGa Prinzip

Garbage-in-Garbage-out lautet eine der universellen Prinzipien der Softwareentwickung. Auf Basis schlechter Anforderungen lassen sich nun mal keine anforderungsgerechten Qualitätssysteme erstellen. Ein Compiler, dem der Entwickler ein unstrukturiertes, fehlerhaftes Softwaresystem übergibt, kann daraus nur selten ein strukturiertes, fehlerfreies System  konstruieren. Aus einer unvollständigen UML-Beschreibung, lassen sich schwerlich gute Softwareartifakte ableiten. Und hier haben wir genau das Problem der modellbasierten Softwareentwicklung. Neulich auf der ooPSLA 2007 gab es ein hochrangig besetztes Panel zum Thema OO-Sprachen nach Simula 67. Eine der Befürchtungen der Programmiersprachen-Koryphäen besteht darin, dass unbedarfte Softwareingenieure die Schaffung domänenspezifischer Sprachen als ihr Steckenpferd entdecken könnten. In diesem Fall bekämen wir ein echtes Problem. Sprachentwicklung ist beileibe nicht simpel, speziell wenn es sich um DSLs für einigermaßen nicht-triviale Domänen handelt. Insofern bleibt zu hoffen, dass mächtige MDSD-Waffen und Analyse-Methoden nicht in die falschen Hände geraten.   Wie gesagt: Garbage-in-Garbage-out!

[OOP 2008] Agile Architekturen

Eines der Kernaufgaben bei Softwareprojekten stellt die Erstellung der Architektur dar. Wie sich diese Aufgabe in den Entwicklungsprozeß einbettet, darin scheiden sich die Geister. Manche agile Methoden (z.B. xP)  schlagen eine Art "Design and Ownership by Committee" vor. Jeder Projektbeteiligte partizipiert an der Architekturerstellung. Im anderen Extrem ist eine Gruppe weniger dedizierter Architekten für diese Aufgabe zuständig. Laut Frederick P. Brooks (Keynote auf der ooPSLA 2007) zeichnen sich gerade die etwas "schlechteren" Softwaresysteme dadurch aus, dass sie von vielen Köchen erstellt wurden, während die richtig guten Softwaresysteme die Handschrift eines oder weniger Architekten tragen. Wie also verhält sich Agilität zu Architektur? Meiner Meinung nach lässt sich in einem agilen Prozeß beides kombinieren. Zunächst erfolgt die Bereitstellung einer architektonischen Vision durch einen oder wenige Architekten. Danach deren Verfeinerung durch einen inkrementellen Prozeß, der Top-Down Elemente (Verfeinerung) mit Bottom-Up Gardening (Refactoring) koppelt. Dass es in einem extreme Programming Prozeß gute Architekturen gibt, wenn nicht alle Beteiligten entsprechende Erfahrung mitbringen, bezweifle ich. Wie lautet also die Lösung für Agilität + Architekturen = ?

[OOP 2008] En vogue mit SOA

Mittlerweile dreht sich ein allzu grosser Teil der Informatikwelt um das Thema SOA.  Das Kochrezept in mancher Fachzeitschrift klingt geradezu verführerisch: man nehme eine Prise SOAP, dazu noch etwas WSDL, füge unter ständigem Rühren BPEL hinzu und würze das Ganze mit einigen weiteren WS-Standards, ganz nach dem persönlichem Gusto. Schon ist alles angerichtet - das ganze Unglück zumindest. Und führende Chefköche empfehlen als Dessert ESB, WEB 2.0, BPMN, BAM und BPM. Da natürlich alle am Kuchen teilhaben wollen, findet sich in dieser modernen  Cuisine ein bunter Eintopf aus Paradiesvögeln, vom Enterprise-Architekten bis zum C++-Experten. Selbstredend singen Marktanalysten mit Entzücken die "Ode an der SOA-Freude" - Orakel liessen sich schließlich schon immer gut honorieren.  Es könnte doch alles so schön sein. Leider schaut die Realität etwas anders aus als Technologieprovider uns glauben machen wollen. In der Praxis bekommen doch auffallend viele SOA-Projekte Probleme, teils wegen der unrealistischen und oft überzogenen Erwartungen, teils aber auch wegen der Komplexität, Technologieunreife oder fehlender Systematik. DAs erinnert mich auffallend an die Anfangszeit von CORBA, dem damals ähnlicher Kultstatus bescheinigt wurde. Und es gibt noch viele weitere auffallende Parallelen, speziell was das Thema Standardisierung betrifft. Wenn der leuchtende SOA-Stern weiterhin derart überfrachtet werden wollte, dürfte er bald implodieren und alles mit sich reissen.   Bin ich ein Advocatus Diaboli oder etwa ein Schwarzmaler? Angeblich soll es irgendwo in dieser Galaxie schon erfolgreiche SOA-Projekte geben. Bühne frei für die Gladiatoren und Missionare, die SOA auf ihre Fahnen geschrieben haben und mich nun eines Besseren belehren!  

[OOP 2008] Countdown

Für die kommende OOP 2008 haben wir wieder mittels Terraforming einen Blog-Planeten geschaffen. Auf dessen Orbit kreisen mehrere Monde. Darunter so veritable wie

SOA

Software Architektur

Agile Entwicklungsprozesse

Modernisierung bestehender Systeme

Analysis & Design (inkl. Model-driven-Development)

Ruby on Rails

 

Zu jedem dieser OOP-Satelliten erwarten Sie spannende Blog-Casts und hoffentlich kontroverse, aber unterhaltsame Diskussionen.

Dadurch erhalten OOP-Besucher und solche, die es werden wollen, einen Vorgeschmack auf die Ingredienzen der kommenden OOP. Dazu noch von so prominenten Chefköchen (beziehungsweise Trackchairs).

Für Kommentare und Feedback bitte ich um Öffnen eines Nachrichtenkanals zu michael.stal@sigs-datacom.de

 

Bon Voyage!

OOP Conference 2008

Ich werde diesen Blog nutzen, um den Planeten OOP ein wenig anzutreiben. Sobald die Trackchairs bereit sind, geht es los