[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 = ?