Softwarearchitektur ist Teamsport

Gemeinschaftliche Arbeit an der Softwarearchitektur eines Systems ist umstritten. Wer ist verantwortlich, wenn zentrale Entscheidungen von mehreren Personen getroffen werden? Wo sind die Ansprechpartner für das Management und andere Stakeholder? Wie entsteht eine stringente „Designlinie“? Wer achtet auf übergreifende Aspekte, die vielleicht nicht angenehm, aber notwendig sind? Wie soll es da flüssige Entscheidungsprozesse geben? Fragen über Fragen. Auf einige gibt es gute Antworten – und insgesamt keine Alternative zur gemeinschaftlichen Arbeit an der Softwarearchitektur.

Was ist Softwarearchitektur? Auch wenn diese Frage für den Anfang eines Artikels schrecklich langweilig klingt, liegt in ihr der Hauptgrund dafür, dass Architekturarbeit gemeinschaftlich erledigt werden muss. Es gibt viele Antworten darauf – doch haben moderne Definitionen von Softwarearchitektur eins gemeinsam: Sie stellen schwer zu ändernde Kernelemente eines Systems in den Fokus. Martin Fowler meint etwa: „To me the term architecture conveys a notion of the core elements of the system, the pieces that are difficult to change. A foundation on which the rest must be built.“ Schwierig zu ändernde Systembestandteile sind demnach ausschlaggebend dafür, ob es sich bei einer technischen oder konzeptionellen Frage um eine architektonische Aufgabe handelt.

Ist die Entscheidung für eine Datenbanktechnologie architekturell? Die Auswahl eines Cloud-Providers? Nach Martin Fowler lautete die Gegenfrage, ob Änderungen an diesen Entscheidungen später teuer oder aufwendig oder schlechte Entscheidungen qualitätsgefährdend für das Softwareprodukt wären. Eine Definition von Eoin Woods stellt diesen Aspekt zentral heraus: „Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be canceled.“ Ich könnte den Rest dieses Artikels mit Zitaten füllen, die Architektur ähnlich definieren. Stattdessen halte ich fest: Architekturarbeit beinhaltet die grundlegenden, später schwer änderbaren Entscheidungen innerhalb der Softwareentwicklung – die schwierigen Aspekte eben.

Die Rolle „Architekt“ und ihre Geschichte

Projektmanagerinnen kümmern sich ums Projektmanagement und Requirements-Ingenieure ums Requirements Engineering. Was machen Softwarearchitektinnen? Würden Sie sich um Softwarearchitektur kümmern, hätten sie nach den oben genannten Definitionen alle „schwierigen Entscheidungen“ zu treffen und würden die Architektur eines Systems formen. Entwickler würden demzufolge die einfachen Dinge erledigen und alles leicht Änderbare entscheiden. Solch eine Aufgabentrennung wirkt nicht nur seltsam, sie ist auch selten ratsam. Selbst wenn man von der Softwareentwicklung weg in andere Lebensbereiche blickt, sind sehr spezifische Voraussetzungen nötig, damit eine Arbeitsteilung in „schwierige Teile“ und „einfache Teile“ gut funktioniert. Warum solch eine Rollenidee trotzdem entstanden ist, ist eventuell historisch erklärbar.

Die Idee, eine Rolle für Architekturarbeit zu schaffen, stammt aus den 1980er- und 1990er-Jahren. Damals waren die grundlegenden, schwer änderbaren Entscheidungen innerhalb der Systementwicklung hauptsächlich struktureller Natur. Wie zerfällt unser System sinnvoll in Komponenten? Welche Schnittstellen sollte es geben? Wie legen wir Daten ab? Einzelne Personen konnten in diesen Wissensbereichen herausragende Expertise aufbauen und in den weniger dynamischen Umfeldern des letzten Jahrhunderts allein planerisch tätig sein. Es ging in einem gesetzten technischen Rahmen häufig darum, die langfristige Wartbarkeit von Systemen zu gewährleisten. Die Mittel dafür waren ein guter Komponentenentwurf, klare Schnittstellen oder eine klare Datenstruktur.

In den 1990er-Jahren nahmen Vernetzung und Virtualisierung von Systemen zu, die Vielfalt von Programmiersprachen ebenso. Waren IBM-Mainframes und Unix-Workstations davor fast alternativlos, tauchten nun neue Servertechnologien auf. Allein 1995 erblickten Windows NT, der Apache HTTP Server und die Programmiersprachen Java, PHP, JavaScript, Ruby und Delphi das Licht der Welt. Diese Technologien brachten auch neue Implementierungsstrategien und Muster mit sich. Mit der Etablierung des Internets wurden parallel auch die Nutzergruppen von Software größer und verteilter. Software musste nun nicht mehr nur wartbar, sie musste auch sicher, zuverlässig, benutzbar oder skalierbar sein. Und das unter komplexeren technischen Rahmenbedingungen.

Diese technische Entwicklung hat bis heute eher Fahrt aufgenommen, als dass sie eingeschlafen wäre. Die Menge an Programmierframeworks, -umgebungen und -werkzeugen ist enorm. Heute müssen eher Personen mit unterschiedlichen Expertisen zusammenfinden und effektiv zusammenarbeiten, um gute Software zu bauen. Die eine Person mit Überblick und fundiertem Wissen in allen herausfordernden Bereichen gibt es nicht mehr.

Abb. 1: Die aktuelle Cloud Native Landscape [1]

Moderne Architekturarbeit (ist komplex)

Die Vielzahl an Lösungsoptionen macht Softwareentwicklung spannend, aber auch herausfordernd. Neben Laufzeitumgebungen und Plattformen können wir über Sprachen, Technologien, Frameworks, Protokolle, Bibliotheken, die Strukturierung der Lösung, Schnittstellendesign und andere Themen nachdenken. Dabei soll das erstellte Softwareprodukt gut wartbar sein, sich über die Zeit verändernden Rahmenbedingungen stellen können, stabil sein und unterschiedlichen Performanz-, Last- und Sicherheitsvorstellungen entsprechen. Es entsteht eine verwobene Designaufgabe, die noch dazu nicht statisch ist. Sowohl Zielsetzungen als auch Lösungsoptionen entwickeln sich ständig weiter, und auf beiden Seiten tappen wir teilweise im Dunkeln. Architekturarbeit ist komplex. Selbst dann, wenn wir menschliche und politische Faktoren ausblenden, die noch einmal Öl ins Feuer gießen.

Um komplexe Probleme zu bearbeiten, gibt es Strategien. Neben anderen Autoren geht David J. Snowden in dem von ihm entwickelten Cynefin-Framework auf komplexe Problemstellungen ein. In [2] empfiehlt er eine Arbeitsweise, die auf Experimente optimiert ist: ausprobieren – beobachten – reagieren. Als „Leader“ solle man Umgebungen schaffen, die die Emergenz von Mustern ermöglichen, den Grad der Interaktion und Kommunikation erhöhen und den Nährboden für die Generierung neuer Ideen schaffen. Um das zu erreichen, solle man etwa Diskussionen fördern (z. B. durch Großgruppenmethoden), Rahmen klar abstecken, Anreize schaffen, Dissens und Vielfalt fördern, Zielsetzungen konkretisieren oder entstehende Lösungsmuster prüfen. All das könnte die Rolle „Architekt“ als Führungspersönlichkeit machen. Sie würde dann aber anders funktionieren als in den 1980er- und 1990er-Jahren.

In meinem Buch „Vorgehensmuster für Softwarearchitektur“ habe ich 2014 beschrieben, wie Architekturarbeit in komplexen Umfeldern funktionieren kann. Die 4. Auflage, die im Frühjahr 2025 erscheint [3], enthält auch ein „Manifest“ für moderne Architekturarbeit. Abgeleitet aus theoretischen Grundlagen wie jenen von Dave Snowden und eigenen Erfahrungen, ist die Komplexität im Architekturbereich handhabbar, wenn Sie kontinuierliche Verbesserung leben, zielorientiert handeln, Kollaboration fördern und Verantwortung breiter streuen.

Abb. 2: Werte moderner Architekturarbeit [3]

Ich versuche diese Werte in meinen Entwicklungsvorhaben hochzuhalten:

• Wir nutzen (automatisierte) Feedbackmechanismen, um ausgehend von einer ersten Designidee Systeme stetig zu verbessern und weiterzuentwickeln.
• Wir brechen die Zielsetzung von Softwaresystemen so weit herunter, dass wir die individuell besten technischen Lösungen finden können.
• Wir fördern rollenübergreifende Kollaboration, um die Komplexität heutiger Software- und Architekturentwicklung bewältigen zu können.
• Wir etablieren breite Verantwortungsstrukturen und weiche Architekturstandards, um auch bei Problemen reaktionsfähig und dynamisch zu bleiben.

Trotz dieser theoretischen Grundlage und der anwendbaren Praktiken, die darauf basieren, gibt es in der Praxis immer noch Impulse, zentrale Rollen zu schaffen, die „Architektur machen“, also Entscheidungen selbst treffen und verantworten. Das hat teilweise mit Unternehmensstrukturen und -kulturen zu tun, teilweise auch mit Bedenken, was gemeinschaftliche Architekturarbeit betrifft. Jene Bedenken, die ich am häufigsten höre, möchte ich genauer betrachten.

Gegenargument 1: „Verantwortung ist nicht teilbar“

Die Idee, dass jemand die Verantwortung tragen muss, ist omnipräsent. Im geschäftlichen Kontext gibt es Führungsstrukturen und Organigramme, im Mannschaftssport gibt es Trainerinnen und in der Politik gewählte Vertreter. Wenn eine Gruppe nicht gut funktioniert, werden verantwortliche Leute versetzt, gefeuert oder zum Rücktritt bewogen. Soll die gemeinschaftliche Arbeit an der Architektur dieses Konzept aushebeln? Gleich vorweg: Die Antwort ist „nein“.

Dieses Gegenargument bedient sich einer sprachlichen Verwirrung. Wenn im agilen Kontext über „breite Verantwortung“ gesprochen wird, ist damit nicht die organisatorische Verantwortung gemeint, die tatsächlich schwer teilbar ist. Es wird oft führende Persönlichkeiten und organisatorisch verantwortliche Personen geben; wichtig ist jedoch, wo das Verantwortungsbewusstsein liegt. Breites Verantwortungsbewusstsein sorgt dafür, dass Beteiligte mitdenken, in Krisenfall reagieren, statt zu warten, und auch über die Grenzen der eigenen Aufgabe hinausschauen. In komplexen Umfeldern müssen sie gut in der Bewältigung neuartiger Probleme werden und breit gestreutes Verantwortungsbewusstsein hilft hier enorm.

Denken Sie an Fußball. Trainer sind organisatorisch verantwortlich und müssen den Hut nehmen, wenn der sportliche Erfolg ausbleibt. Trotzdem sind alle Spielerinnen verantwortungsbewusst. Sie helfen sich gegenseitig aus, versuchen Vorgaben gut umzusetzen und Erfolg zu haben. Wenn es schneller Entscheidungen bedarf, können sie auf Prinzipien zurückgreifen, aber sie agieren dabei frei. Bei Niederlagen sind sie niedergeschlagen und setzen mit Kritik auch bei sich selbst an. Als dynamische Sportart muss Fußball auf Individuen setzen und gibt ihnen Denkmodelle und Organisation mit. Dabei hat Fußball jedoch einen großen Vorteil, was die Komplexität betrifft: Die Regeln sind klar und stabil, die Mittel und Werkzeuge (Ball, Schuhe, Feld, Tore, Beine …) entwickeln sich kaum weiter oder sind standardisiert. Das Ziel (gewinnen) ist allen bekannt und gleichermaßen wichtig. In der Softwareentwicklung haben wir mit einigen Komplexitätsfaktoren mehr zu kämpfen. Lokale Erkenntnis und Reaktion sowie gemeinschaftliches Lernen werden noch wichtiger.

Was können Sie nun konkret tun, um Verantwortungsbewusstsein zu streuen und zu fördern? Die einfache Antwort ist: Stellen Sie Dinge nach, die im Fußball funktionieren. Etwas fundierter gesprochen ist es wichtig, dass Entwicklerinnen das Gefühl haben, einen Unterschied zu machen, dass sie den Effekt der eigenen Arbeit sehen, dass Erfolge klar benennbar sind und Misserfolge direktes Feedback geben. Zwischen Aktion und Feedback sollte wenig Zeit liegen, die Ziele sollten allen Beteiligten bewusst sein. Kontinuierliches Feedback auf Architekturebene ist essenziell, um die komplexen Zusammenhänge zwischen technischen und konzeptionellen Entscheidungen zu verstehen und Architekturarbeit auf mehrere Schultern zu verteilen. Kontinuierliche Auslieferungsprozesse und kurze Iterationen sind dafür ebenso wichtig wie Prüfungen für Architektureigenschaften.

Abb. 3: Der Fitness-Function-Quadrant

Holistische Architekturprüfungen testen direkt die tatsächlich geforderte Systemeigenschaft. Ein Beispiel wäre ein Performanztest für eine wichtige Berechnung oder eine Usability-Einschätzung eines echten Nutzers. Prüfergebnisse können direkt und ungefiltert als Feedback verwendet und müssen nicht erst interpretiert werden. Das macht holistische Prüfungen sehr attraktiv. Gleichzeitig sollte Feedback aber häufig und kleinteilig erfolgen, was manchmal im Konflikt zu holistischen Prüfungen steht. Wollen Sie die Aufbewahrungsfristen für Rechnungsdaten sicherstellen, können Sie holistisch testen, indem Sie nach zehn Jahren prüfen, ob die Rechnungsdaten noch vorhanden sind. Etwas kurzfristiger verfügbares Feedback wäre wohl effektiver.

Atomare Prüfungen testen Systemeigenschaften, die Rückschlüsse auf die eigentlich geforderte Qualität erlauben. Anstatt die echten Ausfallzeiten zu messen, könnten Sie atomar die Infrastrukturauslastung monitoren und so Rückschlüsse auf die Stabilität ziehen. Dieses Feedback ist in kleineren Systemen einfacher zu bekommen; es liefert allerdings kein umfassendes Bild der Fehlerrobustheit.

Kontinuierliches, wenn möglich holistisches Feedback ist interessant, um Verantwortungsbewusstsein zu stärken. Nutzen Sie atomare Prüfungen, um feingranulares Feedback zu schwieriger testbaren Eigenschaften zu bekommen. Mit qualitativen Prüfungen sind nicht nur Erfolge und Misserfolge klarer benennbar, auch die Zielsetzungen werden besser kommuniziert.

Gegenargument 2: „Gemeinschaftliche Architektur ist langsam“

Bei diesem Gegenargument höre ich statt „langsam“ manchmal auch „ineffizient“. Die Idee, sich mit mehreren anderen Personen einig werden zu müssen, löst die Befürchtung aus, man würde sich lange in Abstimmungen und Pattsituationen aufhalten. Tatsächlich geht es meistens schneller, allein zu entscheiden, als sich mit anderen Leuten zu einigen. Die Frage ist jedoch, welchen Zeithorizont man für die Bewertung der Entwicklungsgeschwindigkeit heranzieht.

Nehmen wir an, Sie denken über den Einsatz von Spring Modulith nach. Sie befinden sich gerade im Aufbau einer Microservices-Lösung, allerdings scheint Ihnen der Entwicklungs-Overhead etwas zu hoch für die Zielsetzungen – schließlich wollen Sie lediglich die langfristige Wartbarkeit sicherstellen, haben aber nur zwei Entwicklungsteams, die an der Software arbeiten, und keine herausragend großen Skalierbarkeitsanforderungen. Vorausgesetzt, Sie hätten die Hebel, könnten Sie sehr schnell allein entscheiden, den Microservices-Umbau zu stoppen und die Entwicklung Richtung Spring Modulith zu schwenken. Betrachten Sie nur die Entscheidungsgeschwindigkeit, haben Sie sehr effizient gehandelt. Was passiert jedoch, wenn dieser Umbau nun komplizierter ist als erwartet? Wer außer Ihnen kann und sollte nun detailliertere Entscheidungen zu Konventionen treffen? Wer reagiert, wenn sich herausstellt, dass der Modulith-Ansatz doch Schwächen hat, die ins Gewicht fallen?

Wenn Sie Glück haben, fanden alle Kolleginnen Ihren Entschluss gut und helfen nun mit, die Lösung auszugestalten und passend umzusetzen. Allerdings: Wenn sich alle einig wären, wäre ein gemeinschaftlicher Entscheidungsprozess auch schnell und günstig gewesen … Die alleinige Entscheidung hat nur Geschwindigkeitsvorteile, wenn Sie sich über Bedenken und Widerstände hinwegsetzen. Damit büßen Sie jedoch Verantwortungsbewusstsein bei einigen Kolleginnen ein. Bei Konkretisierungen, unerwarteten Seiteneffekten oder Problemen helfen diese Kolleginnen nicht ganz so motiviert mit wie andere. Treffen Sie nicht nur eine, sondern viele Entscheidungen auf diese Art und Weise, isolieren Sie sich zusehends und müssen irgendwann allein die Gesamtverantwortung tragen. Das ist nicht nur risikoreich, es macht Sie in weiterer Folge auch langsamer. Während die Entscheidungsgeschwindigkeit bei Einzelentscheidungen also etwas besser ist, sinkt die Reaktionsgeschwindigkeit bei Problemen und die Umsetzungsgeschwindigkeit, wenn sich Designfragen stellen. Über Widerstände hinwegzuarbeiten ist falsche Velocity, die man teuer bezahlt.

Was können Sie nun konkret tun, um gemeinschaftliche Architektur zu unterstützen und Entscheidungen trotzdem effizient zu treffen? Zunächst sollten Sie Architekturentscheidungen als solche identifizieren: Sie betreffen übergreifende oder grundlegende Systemaspekte, die in weiterer Folge immer schwerer anzupassen sind. Gehen Sie nur in Gruppenprozesse, wenn es sich auch tatsächlich um Architekturentscheidungen in diesem Sinn handelt (eine lokale Schnittstelle oder sehr isoliert eingesetzte Technologien würden sich wahrscheinlich nicht qualifizieren). Treffen Sie echte Architekturentscheidungen nur allein, wenn Sie keine großen Überraschungen erwarten, die Umsetzung keine große Hürde darstellt und lokale Überlegungen dazu eher schaden als helfen würden. Oft profitiert die Entwicklung allerdings von einer größeren Gruppe an Personen, die eine Entscheidung mittragen. Bei Unsicherheiten, neuen Lösungen oder komplexeren Zusammenhängen ist immer ein Gruppenprozess zu bevorzugen.

Suchen Sie nach effizienten Entscheidungsverfahren, die Widerstände von Personen quantifizieren und besprechbar machen, sind Konsensverfahren eine gute Wahl. Anders als Abstimmungen stellen sie Widerstände ins Zentrum.

Gegenargument 3: „Kollaboration skaliert nicht gut“

Selbst wenn gemeinschaftliche Entscheidungen „effizient“ sein können, wenn man den Betrachtungshorizont auf Umsetzung, Auslieferung und potenzielle Anpassungen ausweitet: Wird das Entwicklungsvorhaben zu groß, ist allein schon die notwendige Transparenz für gemeinsame Entscheidungen aufwendig. Und Entscheidungsprozesse mit 60 oder mehr Personen sind angsteinflößend. Wahrscheinlich handelt es sich hierbei um das beste Gegenargument bisher. Mit wachsender Größe eines Entwicklungsvorhabens kann nicht mehr jede Person in alle Entscheidungen eingebunden sein. Einerseits würde die Kommunikationslast andere Arbeiten zu stark behindern, andererseits stoßen die Beteiligten wohl auch an kognitive Grenzen. Das ist ein oft gesehenes Problem.

Was ist jedoch die Alternative zur gemeinschaftlichen Architekturarbeit in größeren Kontexten? Würden Sie stattdessen vieles zentralisieren und nicht mehr in der Breite diskutieren, wären gerade größere, komplexere Entwicklungsvorhaben von einzelnen Personen abhängig, die selbst nur schwer den Überblick behalten können. Sie könnten sich aber auch nicht auf die motivierte Mitarbeit auf allen Ebenen verlassen und würden deshalb einengende Regeln einführen, Prozesse zentralisieren und die Entwicklung verlangsamen.

Dieses Dilemma hat keine perfekte Lösung. In der Praxis versucht man meist, Gruppenprozesse moderiert zuzulassen, aber die Menge an diskutierten Fragestellungen stark zu reduzieren. Die übergreifenden architektonischen Fragestellungen, die für alle Teams relevant sind, könnten z. B. reduziert werden, indem man Teams freistellt, eigene Wege zu gehen. Bezeichnen wir die für alle bindenden identischen Systemaspekte als Makroarchitektur und jene, die Teams allein entscheiden können, als Mikroarchitektur, würden wir also die Makroarchitektur möglichst schmal ausprägen.

Abb. 4: Schlanke Makro-, dicke Mikroarchitektur

Architekturstile wie Microservices erlauben es, Services in vielen technischen Bereichen unterschiedlich zu bauen. Services können sich in der Datenhaltung, der Programmiersprache, den intern verwendeten Frameworks, ggf. sogar in der UI-Technologie unterscheiden. All diese Aspekte können somit der Mikroarchitektur zugerechnet werden, während sich Teams auf Makroebene z. B. um gemeinsame Securitylösungen, Monitoringkonventionen und Integrationsmechanismen bemühen müssen. Durch die Reduzierung von erzwungener, synchroner Abstimmung zu vielen technischen Themen können auch größere Entwicklungsorganisationen eine gewisse Mitbestimmung einräumen oder den Kuchen an Mikroarchitekturentscheidungen so groß machen, dass darüber ausreichend Verantwortungsbewusstsein entsteht.

Gegenargument 4: „Offenheit sorgt für Chaos“

Die angesprochene Offenheit im Architekturbereich bedeutet, dass Entwicklungsteams unterschiedliche Wege gehen können. Dabei entsteht einerseits die Befürchtung, Teams wären mit der Vielzahl an selbst zu treffenden Entscheidungen überfordert, andererseits, dass Wildwuchs das System auf Dauer unverständlich und unwartbar machen würde. Sowohl Überforderung als auch Wildwuchs führen potenziell zu chaotischen Zuständen in der Entwicklung, lassen sich aber auch mit entsprechenden Mitteln bekämpfen.

Stellen Sie sich vor, Sie wären in der Stadtplanung tätig. Sie haben bestimmte Ideen, was den Fluss von Menschen in Ihrer Stadt betrifft: Vielleicht möchten Sie Ströme von Berufstätigen auf dem Arbeitsweg von erholungssuchenden Spaziergängern trennen. Vielleicht möchte sie laufende Kinder in der Nähe großer Straßen vermeiden. Diese höheren „Designziele“ sind wahrscheinlich nicht jeder gehenden Person klar. Würden Sie auf Makroebene handeln, könnten Sie Verbote aussprechen („Jogger dürfen Weg X nicht benutzen“). Ließen Sie die konkrete Entscheidung allerdings offen, könnten Sie immer noch mit Anreizen arbeiten, um den Designzielen nahe zu kommen. Ein gewundener Weg mit viel Baumschatten und schöner Aussicht könnte Erholungssuchende und Jogger eher anziehen, die direkt gehaltene Unterführung könnte für den gehenden Berufsverkehr interessanter sein. Anreize erfüllen nicht nur einen höheren Designzweck, sie machen die Erfahrung für die einzelnen Benutzergruppen auch besser. Um gute Anreize zu schaffen, müssen Sie sich mit den Zielen und Bedürfnissen der gehenden Bevölkerung auseinandersetzen, was bei strikten Verboten nicht unbedingt der Fall wäre.

In der Softwarearchitektur können wir uns ähnlicher Konzepte bedienen. Völlige Freiheit in Fragestellungen der Mikroarchitektur würde Technologien fördern, die von Haus aus einfacher anzuwenden oder bequemer zu integrieren sind. Welche Lösungen Teams bevorzugen, ist eher zufällig. Ein Anreizmodell kann bestimmte Optionen für Entwickelnde interessanter und einfacher machen als andere. Es entsteht ein Pfad des geringsten Widerstands, der die Verbreitung guter Architekturideen fördert, ohne massiv einzuschränken. Einfachheit und Developer Experience erzeugt eine gewisse Einheitlichkeit, ohne das Verantwortungsbewusstsein zu rauben.

Abb. 5: Anreizmodelle als Alternative zu völliger Freiheit und restriktiven Modellen

Anreizmodelle können den Einsatz bestimmter Technologien, Sprachen, Frameworks, Protokolle, Konfigurationen oder Bibliotheken fördern, Strukturierungsideen und Muster auf unterschiedlichen Ebenen verbreiten oder auch Entwicklungsstile und Prozesse (für Build, Deployment, Dokumentation, Qualitätssicherung …) nahelegen. Sie machen das Leben der Entwickelnden einfacher und transportieren gleichzeitig eine Architekturidee. Konkret geht das mit einfach anzuwendenden Defaults, wie Blueprints oder Standardkonfigurationen. Denkt man darüber hinaus, können Sie automatisieren, methodische Vereinfachungen schaffen oder auch Unterstützungsleistungen im Know-how-Bereich anbieten. Tabelle 1 zeigt diese Kategorien mit konkreten Anreizen.

Tabelle 1: Anreizideen, um Architekturideen ohne Regeln zu fördern

Firmen mit großen Entwicklungsabteilungen und hohem Innovationsdrang wenden vieler dieser Techniken erfolgreich an. Bei Spotify spricht man in diesem Zusammenhang von „Golden Paths“, bei Netflix von „Paved Roads“. Die Initiativen sind sehr erfolgreich und sorgen für einen technologisch-architektonischen Angleich unterschiedlicher Lösungen über die Zeit. Auch wenn Sie in ihrem Kontext kleiner loslegen: Designziele nicht über Entscheidungen zu kommunizieren, sondern einen einfachen Weg zu schaffen, der diese Ziele unterstützt, ist immer sinnvoll.

Bonusgegenargument: „Was mache ich dann als Architekt?“

Ich hoffe, die Ausführungen zu den anderen Gegenargumenten haben gezeigt, dass es ganz spezifischer Ideen bedarf, um erfolgreich gemeinschaftlich an Architekturthemen zu arbeiten. Nicht nur müssen Entscheidungsverfahren etabliert und moderiert werden, auch Anreizmodelle müssen geschaffen, Ziele heruntergebrochen und transparent gemacht, Feedbackmechanismen eingefordert und etabliert, übergreifender Austausch angekurbelt und fokussiert werden. Darüber hinaus schaden Impulse und konkrete Mithilfe in der Umsetzung nie.

Dass zentrale Rollen im Architekturbereich hier arbeitslos werden, ist unrealistisch. Die neue Schule der Softwarearchitektur sorgt eher dafür, dass diese zentralen Rollen selbst auch noch lernen können und von ihren Kolleginnen profitieren.

Wollen Sie die beschriebenen Praktiken detaillierter kennenlernen oder weitere Aspekte moderner Architekturarbeit aufschnappen, sei Ihnen die neue Auflage meines Buchs [3] über Vorgehensmuster ans Herz gelegt.

Links & Literatur

[1] https://landscape.cncf.io

[2] Snowden, David J.; Boone, Mary E.: „A Leader’s Framework for Decision Making“; in: Harvard Business Review, 2007

[3] Toth, Stefan: „Vorgehensmuster für Softwarearchitektur. Kombinierbare Praktiken in Zeiten von Agile und Lean“; Carl Hanser Verlag, 2025

[4] Ford, N. et al: „Building Evolutionary Architectures. Automated Software Governance“; O’Reilly, 2023

[5] Hohpe, Gregor: „Platform Strategy. Innovation Through Harmonization“; Leanpub, 2023

„`