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:
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...
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.
[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.
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:
- Softwarearchitektur dreht sich nur um nicht-funktionale Aspekte von Software. Ihre Ergebnisse spannen den Rahmen für Funktionalität auf.
- 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.
- 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.
