Softwarearchitektur

Am 15.+16. July 2010 trifft sich in München die Fachgruppe Softwarearchitektur der Gesellchaft für Informatik. Das ganze ist in diesem Jahr verpackt in eine kleine Konferenz mit dem Titel Software Architectures for the Cloud.

Ich erinnere mich noch deutlich an das Jahr 2004 und das Gründungstreffen des GI-Arbeitskreises Software Architektur.  Komischerweise ging es damals in Oldenburg eigentlich nur darum, ein Buch zu schreiben. Es wirkte irgendwie wie abgesprochen und etliche Teilnehmer waren doch etwas überrascht. Das ganze kam mir darüber hinaus sehr akademisch vor und ich habe mich die letzten 6 Jahre deshalb aus den GI Aktivitäten herausgehalten.

Die Agenda für dieses Jahr sieht aber eigentlich recht spannend aus. Ich denke, daß ich in diesem Jahr den Kontakt ‘mal wieder aufnehmen werde, zumal ich Florian Matthes auch persönlich ganz gut kenne.

Ein neues Feature von Spring 3 ist die Unterstützung von REST. Dieser Architektur-Ansatz für verteilte Systeme nutzt HTTP und die Ansätzes des Webs deutlich anders, als man dies zum Beispiel von Web Services gewohnt ist. Wie man technisch REST-Anwendungen implementiert sollte klar sein - eben mit Spring 3. Aber ist bei diesem Ansatz zu beachten?

Genau diesen Bereich deckt Stefan Tilkov mit seinem Buch "REST und HTTP: Einsatz der Architektur des Web für Integrationsszenarien" ab. Es enthält eine ausführliche Darstellung des REST-Ansatzes als Architektur und beantwortet daher genau die Fragen, die man bei einem Einstieg in REST hat. Man kann an dem Buch deutlich erkennen, dass der Autor viele Erfahrungen im Bereich Architektur und insbesondere REST gesammelt hat. Er wägt verschiedene Ansätze ab, kommt zu schlüssigen Empfehlungen und betrachtet das gesamte Thema erfrischen unideologisch. Auch die Abgrenzung zu den WS-*-Technologien gelingt so sehr gut und nachvollziehbar. Die zum Teil dann doch spitzen Kommentare finden sich in den Fußnoten und dienen eher der Auflockerung.

Das Buch führt zunächst kurz in REST ein, um dann das Gezeigte durch eine Fallstudie in der Praxis zu zeigen. Dann werden die wesentlichen Elemente (Ressourcen, Verben, Hypermedia, Repräsentationsformate) detailliert erläutert und am Beispiel des Atom-Protokolls praktisch verdeutlicht.

Schließlich geht es um Features wie Sitzungen, Skalierbarkeit, Caching, Sicherheit, Dokumentation und erweiterte Anwendungsfälle, die dann an einer Erweiterung der ersten Fallstudie praktisch gezeigt werden. Dabei wird die Fallstudie komplexer und deckt viele typische Anforderungen im Enterprise-Umfeld ab. Den Abschluss bildet eine Betrachtung zu "Enterprise SOA mit REST".

Insgesamt ist das Buch eine kurzweilige, kompakte und sehr gut gelungene Einführung in REST und auf jeden Fall zu empfehlen.

Wer gleich zugreifen will:





bzw.

REST und HTTP: Einsatz der Architektur des Web für Integrationsszenarien

Wenn ich mir Architekturen ansehen, wie sie typischerweise präsentiert werden, muss ich an dieses Photo denken:




Ein völlig sauber, möglichst quadratisches Gebäude mit rechten Winkeln - das ist es, was man meistens als Ziel für die Architektur präsentiert bekommt. Oder die tatsächliche Architektur des Systems soll wirklich so aussehen. Meistens gibt es da aber dann die sprichwörtlichen "kleinen" Ausnahmen.

In Wirklichkeit erinnern mich die tatsächlichen Architekturen eher an das hier:


Das ist das Spiel "Villa Paletti", zum bekommen bei Amazon. Dabei geht es darum, dass jeder Spieler Säulen seiner Farbe ganz nach oben auf das Gebäude stellen muss, bis es einstürzt. Es gewinnt der Spieler mit den wertvollsten Säulen auf der obersten Ebene.

Wenn man sich die dabei entstehenden Konstruktionen anschaut, sind sie sicher ein Gräuel, wenn man ein Gebäude mit möglichst vielen rechten Winkeln und klaren Strukturen bevorzugt. Und natürlich ist das Ziel einer Software-Architektur nicht, dass sie am Ende einstürzt.

Aber die entstehenden Entwürfe haben auch Vorteile: Auf dem Bild kann man erkennen, dass die oberste Ebene nur von zwei Säulen unterstützt wird. Hier kommt man also mit einem sehr geringen Material-Einsatz aus - und bei einem klassischen Entwurf würde man sicher jede Ebene mindestens mit drei Säulen unterstützen. Es kann also im Laufe des Spiels eine Konstruktion entstehen, die mit weniger Material mehr Höhe erreicht, als dies bei einer im Vorhinein geplanten Konstruktion der Fall wäre.

Die andere interessante Eigenschaft des Spiels ist, dass man ständig evolutionär weiterentwickelt. Das Gebäude umfasst immer alle Bausteine und wird schrittweise "optimiert", also höher. Das ist bei dem Gebäude auf dem anderen Bild sicher nicht der Fall. Dort wird das Gebäude gebaut, es dann irgendwann "fertig" und kann danach eigentlich nicht mehr wirklich verändert werden. Bevor es "fertig" ist, kann man es nicht benutzen. Für Software ist das eine schlechte Eigenschaft, weil man dann die Software nicht ernsthaft weiterentwickeln kann.

Ich bin nun der Meinung, dass "Villa Paletti" eine wesentlich bessere Metapher für Software-Entwicklung ist als das Gebäude weiter oben. Warum?

• Software entsteht evolutionär. Es wird ständig weiterentwickelt, angepasst usw - ein klarer, rechteckiger Entwurf kann dabei nicht entstehen.


• Selbst wenn ein "sauberer" Entwurf entstehen könnte - das "Villa Paletti"-Modell ist teilweise überlegen, wie man am Beispiel des Material-Einsatzes sieht.

Für die Software-Entwicklung bedeutet das aus meiner Sicht, dass wir uns von den klaren, rechteckigen Entwürfen verabschieden müssen - wir werden sie eh nicht realisieren können. Wenn man es dennoch versucht, landet man bei Stackenblocken, weil man es eben nicht schafft, alles in rechten Winkeln anzuordnen. Zu Stackenblocken gibt es unter http://www.youtube.com/watch?v=QEN5-_93gQg ein sehr sehenswertes Video.

Das bedeutet aus meiner Sicht:

• Lebe damit, dass die Architektur nicht perfekt sein wird!


• Beeinflusse aktiv, welche Teile architekturell besser und schlechter sind. Wenn nicht alles perfekt sein kann, muss man dafür sorgen, dass zumindest die wichtigen Teile eine gute Architektur haben.


• Setze also Prioritäten: Probleme, mit denen man leben kann, sollte man nicht korrigieren. Beispielsweise ist ein sauberer Entwurf kein Wert an sich, sondern er hilft bei der Weiterentwicklung. Ein sauberer Entwurf für einen Teil, den man nicht weiterentwickeln wird, macht daher kaum Sinn.


• Entwickel daher die Architektur und die Software evolutionär weiter. Man kann nicht ein sauberes, neues Gebäude bauen - es wird früher oder später wieder umgebaut werden, das muss evolutionär passieren und das Umschalten auf das neue Gebäude wird nicht einfach sein.

Together with my colleague Stefan Roock I wrote an article on building architectures in an agile way for the current issue of the German ObjektSpektrum magazine. The article is part of a controversy with Thomas Lieder about how to incrementally build architectures in agile projects.

In the introductory part of the controversy we talk about the basics of agile methods and the goal of keeping a flat cost curve for features over a long period of time. To achieve this goal we need to change and refactor the software all the time. This is an integral part of agile software development. We learned that its not possible to foresee the future and therefore decided to design only the next steps - and refactor, if we learn over time and find better designs if new requirements appear. This is quite clear on the low-level of individual classes and nicely supported by test-driven development and refactoring tools.

If we use the same argumentation for the architecture of a project, the discussions get a lot more controversy. People don't believe that it is easy to change and refactor the architecture of a system incrementally and flexible over time. We found this discussion often times quite unstructured and using the term architecture in various flavors and meanings. To ease the discussion about agile architectures we divide between the basic architectural style and the concrete architecture of a concrete system. Our opinion is that the basic architectural style is hard to change over time (for example changing a system from a standalone-rich-client application into a multi-user app-server-based system could be quite hard). In contrast to this we believe that changing the concrete architecture and structure of a system could be done incrementally and agile over time. This is obviously not true for every application. They need to be build from ground-up for flexibility and change. But how to build a system that is easier to change over time, even on the architectural level?

From our point of view, there are three fundamental characteristics of design you need to remember every day to build flexible architectures: understandable, loosely coupled and free of redundance. There are many well-known design principles that helps you to build such systems. Keep them in mind, build loosely coupled components, think about good APIs between them - and you are on the right track to build flexible applications and flexible architectures.

A few days ago I gave a short talk on Incremental Design at SEACON 2009, a new buzzword-free conference in Hamburg, Germany. Aside of the fact that this was the first conference in my beautiful home town (and only 15min away from home), I enjoyed to meet a lot of people there. I also made up a few slides for my talk, which you can now download as PDF (in German):

• Inkrementeller Entwurf (pdf)

And last but not least I used my new presentation tool called Session Five for the first time. Was absolutely great!