Follow my new blog

Dienstag, 28. Mai 2013

Zeitgemäße Architekturkompetenz

Die Frage, was denn die Aufgabe eines Softwarearchitekten sei, ist nicht tot zu kriegen. Eine Konferenz, die etwas auf sich hält, hat dazu mindestens eine Podiumsdiskussion.

Ich habe da jetzt keine Lust mehr drauf. Das ewige Diskutieren hält uns davon ab, das Wichtige zu tun, nämlich Softwarearchitektur zu betreiben.

Im Sinne des Cult of Done beende ich deshalb jetzt für mich die Arbeit am Begriff "Softwarearchitektur". I´m done.

Hier die Eckpfeiler der Definition, was Softwarearchitektur aus meiner Sicht bedeutet:

  1. Softwarearchitektur dreht sich nur um nicht-funktionale Aspekte von Software. Ihre Ergebnisse spannen den Rahmen für Funktionalität auf.
  2. Softwarearchitektur hat das Ganze im Blick. Ihre Aufgabe ist es, ein globales Optimum herzustellen und lokale Optima zu vermeiden [1]. Softwarearchitektur ist damit eine ökonomische Disziplin.
  3. Da es nicht so einfach "das Ganze" gibt, sondern immer nur verschiedene Blickwinkel und unterschiedliche Werte, Anforderungen, Bedürfnisse, die sich auch noch über die Zeit verändern, kann Softwarearchitektur nicht einmal ein Optimum einstellen. Architektur ist daher ein Prozess, ihr Ergebnis ein dynamisches Gleichgewicht.

Die Invariante der Softwarearchitektur ist mithin der Wandel. Alles kann sich über die Lebensdauer einer Software verändern.

Deshalb ist für mich die Evolvierbarkeit die zentrale nicht-funktionale Anforderung, um die sich die Softwarearchitektur kümmern muss.

Natürlich beantwortet Softwarearchitektur Fragen zu...

  • Produkten, z.B. "Soll Sql Server oder Oracle eingekauft werden?"
  • Technologien, z.B. "Soll ein RDBMS oder eine NoSql Datenbank zum Einsatz kommen?"
  • Paradigmen, z.B. "Sollen die Daten relational strukturiert werden oder dokumentenorientiert?"

Und viele weitere Entscheidungen trifft die Softwarearchitektur auch noch. Ständig muss sie dabei abwägen, um keine nicht-funktionale Anforderung aus dem Blick zu verlieren. Kann sie das eigentlich? Wer hat die Kompetenz, aus einer wachsenden Zahl von Optionen, die richtigen auszuwählen? Es scheint mir zunehmend schwieriger.

Dass 1 Person dies als Architekt dauerhaft kann, glaube ich nicht. Deshalb ist für mich zeitgemäße Architekturkompetenz eine Teamangelegenheit [2]. Dabei mag der eine mehr, der andere weniger Spaß daran haben - ohne dass am Ende jedoch alle zumindest verstanden und zugestimmt haben, sehe ich keinen hohen buy-in. Und ohne hohen buy-in, droht von vornherein Erosion der Architektur(vision).

Also: Es gibt viel zu beachten für die Softwarearchitektur. Kräfte ziehen sie in verschiedene Richtungen, Anforderungen sind im Wandel, Optionen entwickeln sich... Mir scheint es daher illusorisch, von der Softwarearchitektur Entscheidungen von Dauer zu verlangen.

Natürlich wünscht sich jeder, dass dies oder jenes endlich ein für alle mal entschieden wird: Hardware, Plattform, Paradigma, Technologie, Produkt, Methode... Damit Ruhe reinkommt, damit die Entwicklung planbarer wird, damit der Einkauf gute Konditionen aushandeln kann.

Doch hier scheint mir Software fundamental anders als alle anderen Produkte. Für Software lassen sich endgültige Entscheidungen immer weniger treffen. Nicht nur, weil Kunden notorisch schlecht sagen können, was sie eigentlich wollen, sondern weil die Branche sich mit ihrem rasanten Fortschritt selbst immer wieder Knüppel zwischen die Beine wirft. Es kommt einfach keine Ruhe rein. Vorgestern Desktop, gestern Web, heute Mobile. Gestern RDBMS, heute NoSql, morgen NoDb. Vorgestern Java Applets, gestern Silverlight, heute HTML5/JS, morgen... Und was sonst noch alles. Vor allem aber: Eigentlich stirbt kein Paradigma, keine Technologie aus.

So ergibt sich für mich als Schluss für die Architekturkompetenz eines als Kernaufgabe. Sie ist das zeitgemäße Fundament für die obigen Architekturpfeiler:

Die vornehmste Aufgabe für die Softwarearchitektur ist es, möglichst viele Entscheidungen reversibel zu halten [3].

Softwarearchitekten sind sozusagen eine Kartellbehörde, die ständig darauf achtet, dass keine Monopole entstehen, d.h. systemrelevante Größen, die alles dominieren. Keine Plattform, kein Paradigma, kein Hersteller, keine Technologie sollte so groß und alles durchdringend werden, dass sich der Rest nur noch demütig danach richten kann.

Nur wenn Softwarearchitektur ständig dafür sorgt, dass Entscheidungen im Grunde jederzeit nach neuer Erkenntnislage verändert werden können, kann sie angstfrei und zügig voranschreiten.

Solange noch die Angst regiert, ist Softwarearchitektur nicht frei. Solange muss umfänglich geprüft, statt geliefert werden. Solange muss verhandelt, statt Feedback generiert werden. Solange muss noch einer seinen Arsch absichern, statt Wert für den Kunden bzw. das Ganze zu schaffen.

Früher... ja, früher war das noch anders. Da bestand Architekturkompetenz in einmaligen Entscheidungen. Die Zahl der Optionen war deutlich geringer. Und der Mangel an quasi allem hat deutliche Grenzen gesetzt. Entscheidungen fanden im Konkreten statt. Heute tun sie das auch noch, klar. Einer muss sagen, ob z.B. Notifications via Pubnub oder XMPP verschickt werden sollen. Doch diese Entscheidungen sind nicht von solcher Dauer wie früher. Deshalb wandert zeitgemäße Architekturkompetenz auf die Meta-Ebene. Sie trifft Entscheidungen über Entscheidungen, nämlich wie die konkreten möglichst unbegrenzt vorläufig gehalten werden können.

Soweit meine Definition für Softwarearchitektur. Ich finde sie einfach verständlich und klar umrissen. Nach ihr zu handeln jedoch, ist nicht so einfach. Es erfordert viel Bewusstheit. Ich würde sogar sagen, es geht mehr um Bewusstheit als um technische Kompetenz.

Endnoten

[1] Dass Architekten mit allen möglichen Stakeholdern zu tun haben, ist damit selbstverständlich. Sonst können sie keinen "Bedürfnisausgleich" mit Blick auf ein globales Optimum herstellen.

[2] Über die Frage, ob "der Softwarearchitekt" codieren soll, kann ich mich nicht ereifern. Mir ist das egal. Erstens gibt es für mich nicht (mehr) denen einen Softwarearchitekten. Zweitens kann kein Teammitglied heutzutage mehr alle nötige Kompetenz für die ganzen nötigen Architekturentscheidungen auf sich vereinigen. Architekten als Universalgelehrte gibt es nicht mehr. Drittens müssen die, die Architekturentscheidungen fällen, nur irgendwie zu ihrer Kompetenz kommen. Wie sie das erreichen...? Wahrscheinlich, indem sie auch mehr oder weniger lange in den Codiergräben gekämpft haben. Aber wie lange, ob sie das heute noch kontinuierlich müssen... Das lasse ich dahingestellt. Wichtiger ist mir, dass die, die Architektur betreiben, sich ihrer Kompetenzgrenzen bewusst sind. Da können sie nämlich ggf. etwas dagegen tun.

[3] Reversibilität bedeutet hier natürlich, mit angemessenem Aufwand reversibel zu sein.

7 Kommentare:

Sageniuz hat gesagt…

Hi Ralf, toller Post. Ich wollte dich fragen, ob du persönlich zwischen SW-Architektur und SW-Design unterscheidest. Falls ja, würden mich genau diese Unterschiede interessieren.

Nils Tubbesing hat gesagt…

Ich halte es für am wichtigsten zu verhindern, dass das selbe Problem in einem Team/Produkt mehrmals gelöst wird. Das passiert in größeren Teams oder bei längeren Projektlaufzeiten sehr gerne mal gerade auch bei nicht-Funktionalen Anfordeurngen bzw. Cross-Cutting Concerns. Deswegen würde ich auch die Bezeichnung
"Chefingenieur" der des "Architekten" bevorzugen. Es braucht nicht den der allein alle technologischen Entscheidungen fällt, es braucht den, der dafür sorgt, dass sie gefällt und dann auch eingehalten werden (und überdacht wenn notwendig). Die Tätigkeitsbezeichnung "Architekt" beinhalte IMHO den vom Bau geerbten Denkansatz, dass *erst* *einer* den Plan macht und *dann* *viele* diesen umsetzen. Nicht sonderlich agil ;-).

Ralf Westphal - One Man Think Tank hat gesagt…

@Sageniuz: Design ist für mich der Oberbegriff, Architektur ein Aspekt von Design.

Wer designt, der entwirft, der denkt nach, der stellt eine Form von Bauplan auf für Software. Das Design ist nicht das Programm, sondern nur eine Abstraktion.

Wer Architektur betreibt, der entwirft auch - aber eben nur im Hinblick auf nicht-funktionale Aspekte.

Den Entwurf funktionaler Strukturen nenne ich Modellierung. Nicht perfekt, aber gut genug derzeit ;-) Schlag aber gern einen besseren vor. Vielleicht Dramaturgie? Hm...

Ralf Westphal - One Man Think Tank hat gesagt…

@Nils: Dass ein Problem nicht mehrmals gelöst wird, halte ich für eine Optimierung.

Erstens: Das Problem tritt nicht überall auf. Solange die Lösungslandschaft transparent ist, ist es kein Problem. Architektur hingegen ist immer notwendig.

Zweitens: Wenn die Lösungslandschaft intransparent wird, dann muss man abwägen, ob die Lösung mehr Transparenz oder mehr "Feuchtigkeit" (statt DRYness) ist. Es kann nämlich sein, dass "Wiederverwendnung" teurer ist, als Lösungen nochmal zu erfinden.

"Chefing" als Rolle find ich interessant. Allerdings wäre ich erstmal dafür, dass ein Team selbst dafür sorgt, dass es Entscheidungen fällt und einhält. Dafür gibt es Reviews und Retrospektiven.

Dass in "Architektur" BDUF oder so steckt, finde ich nicht. Nur wenn man es ganz traditionell nimmt. "Chefing" klingt für mich andererseits auch nicht agil.

Anonym hat gesagt…

Im Kern Zustimmung.
Ich würde das leicht abwandeln: die nicht-reversiblen Entscheidungen sollten möglichst nicht zum Problem werden. Die sollte man mehr im Auge haben als die reversiblen. So haben ja andere schlaue Menschen bereits Architektur definiert: fundamentale Entscheidungen. Wenn man an denen rüttelt, käme es einem Neubau gleich.
Ich würde nicht unbedingt auf die Anzahl, sondern auf den Umfang der (nicht-)reversiblen Entscheidungen Wert legen.
Grüße.
Carsten

Ralf Westphal - One Man Think Tank hat gesagt…

Macht der Umfang einer irreversiblen Entscheidung etwas aus?

Nein, ich glaube, das ist nicht so. Ich kann mir keine kleine irreversible Entscheidung vorstellen. Denn wenn der Umfang, den du ansprichst, klein ist, dann ist das ja der Ansatzpunkt für eine Revision der Entscheidung.

Aber nenne gern eine aus deiner Sicht irreversible Entscheidung von kleinem Umfang.

Mir scheint das ein Widerspruch.

Anonym hat gesagt…

Das Wörtchen "nicht" hatte ich doch geklammert ;) Technisch irreversibel ist ja in der Softwareentwicklung quasi nix, es wird nur durch die Kosten gedeckelt, also rein betriebswirtschaftlich. Das Wort irreversibel wird in der Softwareentwicklung sinnentfremdet: wirtschaftlich nicht sinnvoll (und nicht: nicht umkehrbar), also großer Umfang/Kosten.

Carsten