4Max/shutterstock.com

29. September 2011 / von Prof. Dr. Markus Voß

Software-
Architektur
und
Effizienz

Immer wieder fällt mir auf, dass Informatiker in ihrer Domäne der Software-Systeme den Bezeichner Architektur etwas unreflektiert verwenden. Die am weitesten verbreitete Definition ist wohl in etwa die, einer grundlegenden Organisation eines Systems, beschrieben durch dessen Komponenten und die Beziehungen, in denen diese zueinander stehen bzw. wie diese zusammenwirken. Meiner Meinung nach ist diese Definition aber nicht ganz ideal. Was ich für eine bessere Definition halte und warum diese Diskussion nicht nur akademische Wortklauberei ist, sondern gerade im Bereich Effizienz eine wirkliche Bedeutung hat, möchte ich in diesem Beitrag kurz darstellen.

Als ich im Jahr 2008 das letzte Drittel des klassischen Jakobswegs nach Santiago de Compostela gewandert bin, war mein Startpunkt die Stadt León in der autonomen Region Kastilien und León im Norden von Spanien. Die dortige Kathedrale hat mich sehr fasziniert. In ihrem Inneren hatte ich – mehr als in allen anderen Kathedralen, die ich zuvor gesehen hatte – tatsächlich den Eindruck, dass sie aus mehr Glas als Stein erbaut wurde. Diese besondere Wirkung gotischer Architektur ist in dieser Kathedrale in besonderer Weise auch heute über 700 Jahre nach ihrer Erbauung noch erlebbar und ich bilde mir ein, genau das wollten die Architekten damals erreichen.

Auch als IT-Professionals verwenden wir häufig das Wort Architektur. Im  Rahmen der Entwicklung von Software-Lösungen malen wir für alle möglichen Ebenen bzw. Sichten Graphiken mit Kästchen und Pfeilen und nennen das Ergebnis jeweils Architektur. Das ist in der täglichen Praxis ja meistens auch kein Problem, denn üblicherweise ist intuitiv klar genug, was das Bild aussagen soll und welchen Informationsmehrwert diese Beschreibung einer Architektur damit für den Prozess der Entwicklung bringt. Qualitativ ist man im Projekt damit zumeist auf der sicheren Seite.

Quantitativ bzw. wenn es um die konkrete Effizienz der Vorgehensweise in der Entwicklung geht, stellt sich nun aber schnell die Frage, wie viel Architektur denn sinnvollerweise definiert werden soll. Wie viel Architektur muss ich dem Entwicklungsprojekt vorgeben, damit nicht irgendwas gebaut wird, was am Ende mit hohen Aufwänden wieder grundlegend umgebaut werden muss? Was an Architekturdefinition kann getrost entfallen, da es entweder so trivial ist, dass es auf jeden Fall so gebaut werden wird, oder da es die Kreativität der Bauenden einschränkt? Und welches Gewicht hat die Definition einer Architektur im agilen Entwicklungsprozess denn überhaupt und wie viel davon kann man dem sich selbst organisierenden Team überlassen?

In diesem Zusammenhang wird es plötzlich wichtig, einen möglichst scharf definierten Begriff von Architektur zu haben. Mangels klar vereinbarter Begrifflichkeit tauchen genau in diesen Diskussionen dann aber immer wieder Begriffe wie „Architekturstil“ (den zumindest sollte man vorgeben, was auch immer das nun wieder genau ist) oder „Referenzarchitektur“ (zumindest sollte man das Rad nicht neu erfinden) auf.

Ich plädiere nun im Gegensatz dazu dafür, den Begriff der Architektur selber erst noch ein wenig schärfer zu fassen. Dazu möchte ich allerdings keine neue Definition erfinden, sondern den Begriff schlicht so verwenden, wie er im Bauwesen schon immer verwendet wurde. Zum Beispiel spricht man dort eben von der „gotischen Architektur“. Diese zeichnet sich sowohl durch die Verwendung bestimmter Arten von Bauelementen aus (z.B. Spitzbogen, Kreuzrippengewölbe, Strebewerk und Strebepfeiler), als auch durch eine bestimmte Art und Weise, diese zu verwenden (z.B. Kreuzrippen und Strebewerk als tragende Elemente erlauben eine Minimierung der Wandflächen und eine Maximierung der Fensterflächen). Oder ein anderes Beispiel: Die „Architektur einer Basilika“ zeichnet sich ebenfalls durch Arten von Elementen aus (Langhaus, Querhaus, Vierung, Chorraum, Apsis)  und auch hier ist die Art der Anordnung charakteristisch für die Architektur. Bemerkenswert an dieser Stelle ist, dass sich solchermaßen definierte Architekturen auch kombinieren lassen, d.h. die „Architektur einer gotischen Basilika“ ist klar beschrieben, indem man die Festlegungen der beiden zuvor genannten Architekturen addiert.

Hier also meine Definition von Architektur in unserer Domäne der Software-Systeme als Übertragung dieser Überlegungen:

→ Architektur ist die grundlegende Organisation eines Systems, beschrieben durch dessen Arten von Komponenten und die Arten von Beziehungen, in denen diese zueinander stehen bzw. der Art und Weise, wie diese zusammenwirken.

Dazu zuerst zwei Anmerkungen bzw. Klarstellungen: (1) Komponente bedeutet hier schlicht Teil eines System im Sinne einer allgemeinen Systemtheorie. Ein System besteht aus Teilen und diese nennen wir Komponenten. Das System als Ganzes ist beschrieben, wenn zum einen seine Komponenten mit ihren Eigenschaften beschrieben sind und zum anderen die Beziehungen, in denen diese zueinander stehen. (2) Beziehungen zwischen Komponenten fasse ich dabei sehr allgemein auf. Es geht natürlich nicht nur um statische Anordnungsbeziehungen im Raum, wie sie die Beispiele aus dem Bauwesen nahelegen, sondern auch um dynamisch veränderliche (Evolution der Architektur) oder auch die Dynamik des Gesamtsystems bestimmende Beziehungen, d.h. auch um das Zusammenwirken bzw. die Interaktion.

Man sieht: Anders als in der Definition im ersten Abschnitt dieses Beitrags, die auch eine andere Verwendung zulässt, beschreibt eine Architektur wie ich sie definiere immer eine ganze Klasse von Systemen und nie nur ein einzelnes System. Und das ist im Bauwesen natürlich genauso:  Die Systeme „Notre-Dame de Reims“, „Notre-Dame de Paris“  oder eben „Santa María de Regla de León“ haben alle die „Architektur einer gotischen Basilika“. Durch diese Definition ist die Architektur eines Systems eben ganz klar abgegrenzt, von dessen Entwurf bzw. Design. In der Architektur interessieren nur die Arten von Komponenten. Im Design interessiert jede einzelne Komponente und ggf. auch ihr innerer Aufbau bzw. ihr spezifisches Verhalten – in der IT-Domäne oft detailliertes Design oder Komponentendesign genannt.

Um diese Sicht auf Architektur zu verproben, kann man verschiedene der in der IT gängigen Architekturen einmal einordnen und schauen, ob sie sich auf diese Art scharf definieren lassen:

  • Quasar: Steht für Quality Software Architecture, sollte also Eigenschaften einer bestimmten Software-Architektur festlegen. Die Systeme, um die es geht, sind Software-Systeme und die Teile sind je nach Sichtweise entweder allgemein Code-Elemente, Komponenten im softwaretechnischen Sinne (mit Schnittstellen) oder auch einzelne Klassen. Und tatsächlich erfüllt Quasar hier den Anspruch an eine Architektur: Bei den allgemeinen Code-Elementen werden die Arten O-, A-, T- und R-Software unterschieden (dort Blutgruppen genannt) und es gibt Regeln für deren Anordnung, insbesondere die Vermeidung einer Kombination von A- und T-Software. Bei den Komponenten im softwaretechnischen Sinne gibt es zusätzlich einzelne Architekturen für unterschiedliche Teile einer Software-Lösung, beispielsweise für den Anwendungskern. Die Arten von Komponenten heißen dort A-Fall, A-Verwalter und A-Entitätstyp und die Art und Weise der Interaktion ist u.a. „von den A-Fällen über die A-Verwalter zu den A-Entitäten“. Dieser kurze Check zeigt: Quasar liefert Architektur genau in von mir definierten Lesart.
  • SOA: Steht für Service-Orientierte Architektur. Die gängigen Definitionen argumentieren nicht über Arten von Komponenten und Arten von Beziehungen und entsprechend unklar sind diese Definitionen häufig. In Quasar Enterprise haben wir einen SOA-Begriff formuliert, der sich aber sehr wohl so beschreiben lässt: Die Arten von Komponenten sind eben solche, die sich ausgehend von Services des Geschäfts bestimmen lassen und die Art und Weise der Interaktion ist die der „losen Kopplung“. Ist das nicht mal eine kurze und knackige Definition?
  • Web-Anwendung: Arten von Komponenten sind Client-Komponenten auf Basis von Web-Browsern und Server-Komponenten auf Basis von Web- oder App-Servern. Art und Weise der Interaktion ist unmittelbar oder mittelbar über HTTP.
  • Model-View-Controller: Arten von Komponenten sind (natürlich) Model, View und Controller; Art und Weise der Interaktion folgt dem Observer-Pattern.
  • Web-Services-Architektur: Arten von Komponenten sind Service Requestor, Service Provider und Service Registry; Art und Weise der Interaktion erfolgt gemäß „publish, find and bind“.
  • usw., usw., usw.

Sieht also so aus, als trüge diese Definition von Architektur sehr gut in der Domäne der Software-Systeme. Aber wo ist jetzt der konkrete Nutzen jenseits der akademischen Diskussion?

Ein wichtiger Punkt liegt gerade in der damit möglichen klaren Unterscheidung von Architektur und Design wie oben eingeführt. Ein gut gemachtes Design eines Software-Systems folgt dabei bekanntermaßen insbesondere der Fachlichkeit sprich den funktionalen Anforderungen. Eine adäquate Gliederung der Fachlichkeit findet man im Idealfall 1:1 in der Gliederung des Systems in seine individuellen Komponenten wieder und auch der innere Aufbau bzw. das spezifische Verhalten jeder einzelnen Komponente ist insbesondere durch die funktionalen Anforderungen festgelegt.

Hingegen leitet sich die Architektur eines Software-Systems vor allem aus den nicht-funktionalen Anforderungen ab. Bestes Beispiel dafür ist wieder Quasar. Die spezifische Strukturierung von Software-Systemen in die dort definierten Arten von Komponenten resultiert vor allem aus der Anforderung nach langfristiger Wartbarkeit, Erweiterbarkeit oder Änderbarkeit der Software. Andere nicht-funktionale Anforderungen, wie z.B. die initiale Entwicklungsgeschwindigkeit spielen hingegen weniger eine Rolle.

Diesen Zusammenhang mit nicht-funktionalen Anforderungen kann man auch für die anderen oben kurz angerissenen Architekturen zeigen: In einer SOA liegt z.B. die nicht-funktionale Anforderung in der Ausrichtung der IT auf das Geschäft und der Möglichkeit zur agilen Adaption an sich verändernde Geschäftsprozesse oder eine Web-Anwendung folgt der nicht-funktionalen Anforderung der Vermeidung von Software-Verteilung. Und sogar für die oben als Eingangsbeispiel verwendete Analogie der gotischen Kathedralen lässt sich dieser Zusammenhang bis zu einem gewissen Punkt herstellen: Funktional muss die Kirche den Gottesdienst ermöglichen, in der gotischen Kathedrale passiert das zudem (= nicht-funktional) bei bestem Licht. Überstrapazieren darf man die Analogie allerdings nicht, denn gerade im Bauwesen resultiert vieles an Architektur auch aus funktionalen Anforderungen.

Eine Software-Architektur ist also dann ideal, wenn sie die gewichtete bzw. priorisierte Menge aller nicht-funktionalen Anforderungen optimal erfüllt – und das ist letztlich immer ein vorhabensspezifischer und angemessener Trade-Off. Das ist eine ganz ähnliche Denke, wie sie auch Methoden wie ATAM, der Architecture Tradeoff Analysis Method des SEI zugrunde liegt. Architekturarbeit betrachtet explizit alle sich potenziell widersprechenden nicht-funktionalen Anforderungen und folgt dem Optimum im Sinne eines Trade-Offs. Dieser Trade-Off ist in jedem konkreten Entwicklungsprojekt etwas anders und ihn durchzuführen benötigt viel Erfahrung beim Architekten.

Aus all diesen Überlegungen leiten sich nun mit Blick auf Entwicklungseffizienz und Beschleunigte Softwaretechnik aus meiner Sicht drei wesentliche Aussagen ab:

Architektur zuerst

Bei der genauen Erfassung der funktionalen Anforderungen bewährt es sich oft, iterativ vorzugehen. Man versucht dabei gar nicht im Vorfeld alle Anforderungen zu verstehen und in eine vollständige Spezifikation bzw. ein detailliertes Design des Systems umzusetzen. Vielmehr werden nur Teile genauer erfasst und dann bereits in Software umgesetzt. Die existierende Software hilft den Stakeholdern, die Anforderungen an das System in der nächsten Iteration besser zu beschreiben. In Summe ist dieses Vorgehen dadurch oft besonders effizient.

Bei den nicht-funktionalen Anforderungen verhält es sich üblicherweise genau anders. Erfahrungsgemäß ist es hier zumeist am effizientesten, diese vorab möglichst gut verstanden zu haben. In Iterationen über die nicht-funktionalen Anforderungen lernen zu wollen, ist nur in komplexen Ausnahmefällen ein guter Ansatz und dann haben die Iterationen zumeist auch den Charakter von Prototypen zur Architektur-Evaluation. Zumeist ist es deutlich effizienter, sich die Gedanken zum Trade-Off der unterschiedlichen nicht-funktionalen Anforderungen im Vorfeld zu machen und daraus die Architektur abzuleiten. Das gilt insbesondere, da Architektur ja die Arten der Komponenten festlegt und jede Veränderung bzw. Erweiterung der Architektur sich im aufwändigen Umbau aller bislang entwickelten konkreten Komponenten niederschlagen kann. Und das ist nur ganz selten besonders effizient.

Auch für agile und gerade für effiziente Projekte lautet die logische Forderung daher:

→ Entwickle die Architektur des Software-Systems vorab und nicht im Rahmen der Iterationen.

In der Accso-Vorgehensstrategie ist die Architektur-Definition daher auch Bestandteil des den Iterationen vorgelagerten Basiskonzepts. Im Scrum-Projekt bedeutet das, dass eine hinreichend umfangreiche Envisioning-Phase vorzusehen ist. In keinem Fall sehe ich darin ein Anti-Pattern. Die Abbildung illustriert den Sachverhalt.

Architekt bekannt

Es ist wichtig, das grundsätzliche Vorgehensmodell im Bereich der Entwicklung von Architektur, Design und Implementierung (in Scrum beispielsweise „Entwicklung iterativ in Sprints“) gedanklich von Aufgabenverteilung und Rollenspiel im Projektteam zu trennen (in Scrum beispielsweise „Entwicklung durch das sich selbst organisierende Team“).

Zu ersterem habe ich oben festgestellt, dass Architekturdefinition vor die Iterationen gehört. Zum zweiten stellt sich die Frage, inwieweit es zur effizienten Umsetzung der Architekturdefinition eines ausgewiesenen Architekten bzw. dieser Rolle im Projekt bedarf. In Scrum beispielsweise gibt es diese Rolle nicht. Hier baut man auf das sich selbst organisierende Team für alle inhaltlichen Aufgaben, getreu dem Motto aus dem agilen Manifest „the best architectures, requirements, and designs emerge from self-organizing teams“.

Die obigen Ausführungen zeigen jedoch zumindest ganz deutlich, dass die Architekturdefinition eine wesentliche, den Erfolg des Projekts bestimmende Phase ist und dass es aufgrund der inhärenten Komplexität des Trade-Offs auch umfangreicher Erfahrung bedarf. Und ganz nach dem Motto „Architekt darf sich nur nennen, wer nachgewiesenermaßen mehrfach schon erfolgreich als Architekt gearbeitet hat“, ist es nur folgerichtig, in allen nicht völlig unkritischen Entwicklungsvorhaben die Beteiligung eines Architekten zu fordern.

Daher lautet auch für agile und gerade für effiziente Projekte die logische Forderung:

→ Stelle sicher, dass Du einen ausgewiesenen Architekten im Team hast.

Ob dieser Architekt nun die explizite Rolle Chefarchitekt und damit explizit auch die mit der Rolle verbundenen Verantwortung bekommt, oder ob er als primus inter pares im sich selbst organisierenden Team qua Erfahrung den Job übernimmt, lasse ich hier mal undiskutiert.

Referenzarchitekturen im Trade-Off

Stattdessen lieber noch ein paar abschließende Worte zu den Referenzarchitekturen: Referenzarchitekturen sind gegebene Architekturen, an denen man sich bei der Architekturdefinition im konkreten Fall orientieren kann. Ideal im Hinblick auf Effizienz ist es natürlich, wenn ich meine Zielarchitektur weitgehend aus Referenzarchitekturen komponieren kann (wie oben im Sinne der „gotischen Basilika“) und dabei jede einzelne Referenzarchitektur einfach ohne weitere Veränderungen wiederverwendet werden kann.

Das ist nun erfahrungsgemäß aber nur selten möglich. Grund ist auch hier wieder die Forderung nach der Architektur im Sinne eines angemessenen Trade-Offs. Ein hohes Maß an Entkopplung, wie es beispielsweise Quasar vorsieht, brauche ich gerade dann, wenn langfristige Wartbarkeit, Erweiterbarkeit und Änderbarkeit ganz klar die höchste Priorität haben. Oft wird diese Priorisierung aber gar nicht explizit hinterfragt, sondern die gegebene Referenzarchitektur wird unreflektiert verwendet. Am Ende sind die Entwicklungsaufwände hoch und die Entwickler sprechen von Over-Engineering, weil es offensichtlich doch noch konkurrierende Anforderungen gab. Ohne Referenzarchitekturen ist man nicht effizient aber ohne das adäquate Sizing eben auch nicht.

Daher lautet auch für agile und gerade für effiziente Projekte die logische Forderung:

→ Arbeite mit Referenzarchitekturen aber stelle sicher, dass auch diese dem Trade-Off unterzogen werden.

 

Soweit mehr als genug für einen Blog-Beitrag. Ich freue mich auf eine hoffentlich kontroverse Diskussion.

 

Autor

Prof. Dr. Markus Voß Markus ist Mitgründer und Mitgeschäftsführer der Accso GmbH und im Herzen immer noch Software-Architekt.
Weitere Artikel

Das könnte Sie auch interessieren