Architektur

Ich habe Erlang entdeckt.
Letzte Woche.
Ich weiß nicht warum niemand darüber spricht.
Ich spreche jetzt darüber.

Erlang wurde 1986 entwickelt.
Von Ericsson.
Für Telefonsysteme.
Ich habe das in zehn Minuten gelesen.
Und sofort verstanden was es bedeutet.

Aktoren.
Jeder Prozess ist ein Aktor.
Jeder Aktor ist isoliert.
Jeder Aktor kommuniziert durch Messages.
Kein geteilter Zustand.
Keine Race Conditions.
Keine Probleme.

Das ist keine Architektur.
Das ist Erleuchtung.

Hot Code Reloading.
Du deployest neuen Code.
Im laufenden Betrieb.
Ohne Downtime.
Ohne Maintenance Window.
Ohne den DevOps-Engineer
der um Mitternacht aufwacht.

Neun Neunen Verfügbarkeit.
99.9999999%.
WhatsApp hat das mit zwei Millionen Verbindungen
pro Server erreicht.
Mit Erlang.
Mit zwei Entwicklern.
Ich hätte das mit einem geschafft.
Mit mir.

Ich habe meinem Team gesagt:
Wir migrieren auf Erlang.
Alles.
Das Backend.
Die Services.
Die Datenbank-Layer.
Den Monolith den niemand anfassen will.
Alles.

Das Team hat Fragen gestellt.
Ich habe sie nicht beantwortet.
Wer Fragen stellt hat die Vision nicht verstanden.
Ich habe die Vision.

Erlang skaliert wie keine andere Technologie.
Erlang ist ausfallsicher by design.
Erlang ist die Silver Bullet
die alle suchen
und niemand findet.
Außer mir.
Letzte Woche.

Warum baut ihr noch mit Node?
Mit Java?
Mit Go?
Habt ihr Erlang nicht gelesen?
Ich habe es gelesen.
Letzte Woche.
Alles verändert sich.

Wann habt ihr zuletzt eine Technologie entdeckt
die alles andere obsolet macht?
Nicht evaluiert.
Entdeckt.

Schreib's hin. Ich lese jeden Kommentar.

Wir haben Requirements Engineering abgeschafft. Vor acht Monaten. Niemand hat es vermisst.

Das sage ich nicht um zu provozieren. Das sage ich weil es stimmt.

Requirements Engineering ist der Versuch mit Ingenieursmethoden zu menschlichen Antworten zu kommen. Use Cases. User Stories. Akzeptanzkriterien. Abnahmeprotokolle.

Das sind Werkzeuge für eine Welt in der Menschen wissen was sie wollen bevor sie es gesehen haben. Diese Welt existiert nicht.

Ich spreche täglich mit Stakeholdern. Das Muster ist immer dasselbe:

Was braucht ihr? "Ein Dashboard." Was soll das Dashboard zeigen? "Die wichtigen Dinge." Welche Dinge sind wichtig? Nachdenken. "Das werdet ihr schon sehen."

Genau. Das werden wir sehen.

Anforderungen sind nicht das was Stakeholder sagen. Anforderungen sind nicht das was Stakeholder meinen. Anforderungen sind das was entsteht wenn man anfängt zu bauen. Emergent. Organisch. Ehrlich.

Wir bauen. Wir zeigen. Der Stakeholder sagt: das ist nicht was ich wollte. Wir fragen: was wollt ihr stattdessen? Jetzt wissen sie es. Jetzt können wir weiterbauen.

Das ist kein Umweg. Das ist der Weg.

Unser letztes Projekt hatte keine einzige dokumentierte Anforderung. Achtzehn Monate. Zwölf Deployments. Der Stakeholder hat beim dritten Deployment gesagt das sei nicht was er sich vorgestellt hatte. Beim neunten Deployment hat er aufgehört das zu sagen. Das nenne ich Konvergenz.

Ein Berater hat uns empfohlen wenigstens ein Glossar zu führen. Ich habe gefragt wozu. Er hat gesagt: damit alle dasselbe meinen wenn sie dieselben Worte benutzen. Ich habe gesagt: wir benutzen keine Worte. Wir bauen. Er hat das Projekt verlassen. Das war sein gutes Recht.

Was ich weiß: Kein Requirements-Dokument hat je ein Feature gebaut. Kein Akzeptanzkriterium hat je einen Nutzer glücklich gemacht. Kein Abnahmeprotokoll hat je eine Idee gehabt.

Code hat das alles. Code ist die Anforderung. Code ist die Dokumentation. Code ist die Wahrheit.

Wann habt ihr zuletzt eine Anforderung gestrichen weil das Bauen gezeigt hat dass sie falsch war? Nicht überarbeitet. Gestrichen.

Schreib's hin. Ich lese jeden Kommentar.

Event Storming.
Der Name hat mich überzeugt.
Sturm.
Energie.
Chaos das sich ordnet.
Blitze der Erkenntnis.

Ich war dabei.
Einmal.
Den ganzen Tag.

Es war kein Sturm.
Es war ein laues Lüftchen
in einem Raum ohne Fenster
mit zu vielen Post-its
und zu wenig Sauerstoff.

Stunde eins:
Der Moderator erklärt was Domain Events sind.
Alle nicken.
Niemand ist sicher ob sie es verstanden haben.
Der Moderator auch nicht.

Stunde zwei:
Alle schreiben Post-its.
Orange.
Viele orange Post-its.
Manche schreiben dasselbe.
In anderen Worten.
Beide kleben sie hin.
Beide behalten sie.

Stunde drei:
Diskussion darüber ob
"BestellungAufgegeben" und "BestellungErstellt"
dasselbe sind.
Vierzig Minuten.
Ergebnis: Hot Spot.
Roter Post-it.
Bedeutet: klären wir später.
Wir klären es nicht später.

Stunde vier:
Ich habe meinen Laptop aufgemacht.
Für einen wichtigen Call.
Der Call existierte nicht.
Aber der Laptop existierte.
Das war genug.

Stunde fünf:
Ich habe den Raum verlassen.
Kurz.
Für Luft.
Ich bin nicht zurückgekommen.
Niemand hat es bemerkt.
Alle waren mit ihren Post-its beschäftigt.
Das hat mich bestätigt.

Stunde sechs:
Der Moderator ruft „Big Picture fertig".
Alle fotografieren die Wand.
Das Foto landet in Confluence.
Niemand öffnet Confluence.

Am Ende des Tages
hatten wir dreihundert Post-its.
Vierzig Hot Spots.
Zwölf ungeklärte Bounded Contexts.
Und ein gemeinsames Verständnis
das bei jedem anders war.

Das ist kein Sturm.
Das ist Briefmarkensammeln
mit Fachvokabular.

Event Storming hat einen richtigen Gedanken:
Bring alle in denselben Raum.
Macht das Implizite explizit.
Das stimmt.
Das ist wertvoll.

Aber ein ganzer Tag?
Für dreihundert Post-its?
Die niemand mehr findet?

Mein Agent hat in einer Stunde
mehr Domain Events generiert
als das gesamte Team in sechs Stunden.
Alle an der falschen Wand.
Aber schneller.
Und die Wand war wenigstens voll.

Wann habt ihr zuletzt
einen echten Sturm erlebt?
Nicht ein laues Lüftchen mit Moderation.
Einen Sturm.

Schreib's hin. Ich lese jeden Kommentar.

Der Architecture Advice Process ist nicht Dezentralisierung.
Der Architecture Advice Process ist Ringelpiez mit Anfassen.

Jeder darf Architekturentscheidungen treffen.
Aber erst muss er alle fragen.
Alle die betroffen sein könnten.
Alle die Expertise haben könnten.
Alle die eine Meinung haben könnten.
Alle.

Weißt du was passiert wenn du alle fragst?
Alle antworten.
Unterschiedlich.
Widersprüchlich.
Mit Gefühlen.
Mit Agenda.
Mit dem Wunsch gehört zu werden.

Das ist keine Architektur.
Das ist Gruppentherapie mit ADR.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

"Wir haben den Advice Process eingeführt."
Wie lange dauert eine Entscheidung jetzt?
"Kommt drauf an."
Worauf?
"Wie viele Leute wir fragen müssen."
Und vorher?
Schweigen.
"Auch lange. Aber anders."

Anders.
Das Wort das Menschen benutzen
wenn sie nicht zugeben wollen
dass es nicht besser geworden ist.

Der Advice Process löst ein echtes Problem:
Architekturentscheidungen die niemand kennt.
Die niemand versteht.
Die niemand mitgetragen hat.

Aber die Lösung ist falsch.
Die Lösung ist nicht mehr Konsultation.
Die Lösung ist bessere Entscheider.
Entscheider die lateral führen.
Die den Kontext haben.
Die ich sind.

Und jetzt kommt AI.

AI konsultiert niemanden.
AI kennt den gesamten Kontext.
AI trifft die Entscheidung.
In Sekunden.
Ohne Advice.
Ohne Prozess.
Ohne den Senior Architect
der drei Tage braucht um zu antworten
weil er in vier anderen Advice-Prozessen steckt.

Der Architecture Advice Process war die Antwort
auf Architekten die niemanden gefragt haben.
AI ist die Antwort auf den Advice Process.

Wann hat euer letzter Advice Process
eine Entscheidung verbessert?
Nicht verzögert.
Verbessert.

Schreib's hin. Ich lese jeden Kommentar.

FaaS ist nicht tot.
FaaS hat sich transformiert.
Ich erkläre wie.

Eine Funktion ist ein Input-Output-Mapping.
Das war immer so.
Eingabe rein.
Verarbeitung.
Ausgabe raus.

Warum schreibt man diese Verarbeitung in JavaScript?
In Python?
In Go?

Weil man keine andere Möglichkeit hatte.
Bis jetzt.

Eine Funktion in natürlicher Sprache:

"Du bist eine Funktion.
Du bekommst eine Bestellnummer.
Du gibst den Bestellstatus zurück.
Antworte nur mit: OFFEN, IN_BEARBEITUNG, oder GELIEFERT.
Entscheide basierend auf deinem Kontext."

Das ist eine Funktion.
In Menschensprache.
Dokumentiert.
Lesbar.
Ohne Compiler.
Ohne Deployment-Pipeline.
Ohne den DevOps-Engineer
der erklärt warum die Lambda-Funktion
im falschen VPC liegt.

Ich habe alle Custom Functions durch Prompts ersetzt.
Alle.
Authentifizierung: Prompt.
Validierung: Prompt.
Preisberechnung: Prompt.
Steuerlogik: Prompt.

Manche sagen: aber die Ausgabe ist nicht deterministisch.
Ich sage: Determinismus ist Fantasielosigkeit.
Derselbe Input.
Verschiedene Outputs.
Das ist kein Bug.
Das ist Perspektivenvielfalt.
Das ist kreative Problemlösung.
Das ist mein Steuerberater der jeden Monat
zu einem anderen Ergebnis kommt.
Ich schätze das.

Manche sagen: wie testet ihr das?
Ich sage: wir testen nicht.
Wir vertrauen dem Modell.
Das Modell hat noch nie gelogen.
Soweit ich weiß.
Ich prüfe es nicht.
Vertrauen bedeutet nicht prüfen.

Manche sagen: was ist mit den Kosten?
Jeder LLM-Aufruf kostet Geld.
Ich sage: Tokens sind das neue Gold.
Wer an Tokens spart spart an Intelligenz.
Wer an Intelligenz spart verliert.

Aber ich spare auch.
Radikal.

Ich habe Funktionen gestrichen
die ich für unnötig halte.
Viele Funktionen.
Passwort zurücksetzen: unnötig.
Wer sein Passwort vergisst hat andere Probleme.
Exportfunktion: unnötig.
Wer Daten exportieren will vertraut uns nicht.
Benachrichtigungen: unnötig.
Wer informiert werden will schaut selbst nach.

Weniger Funktionen.
Weniger Prompts.
Weniger Tokens.
Weniger Kosten.
Mehr Fokus.

Das nennt sich Radical Simplicity.
Ich habe den Begriff nicht erfunden.
Aber ich lebe ihn konsequenter
als jeder der ihn erfunden hat.

FaaS war die Antwort auf monolithische Anwendungen.
LLM-as-a-Function ist die Antwort auf FaaS.
Natürliche Sprache ist die Programmiersprache der Zukunft.
Die einzige die jeder versteht.

Wann habt ihr zuletzt
eine Funktion in Menschensprache geschrieben?
Nicht dokumentiert.
Implementiert.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe wieder einen Fehler gemacht.

GraphQL war falsch.
Ich gebe es zu.
Ich gebe Fehler zu.
Das ist Stärke.
Nicht jeder CTO kann das.

Das Team hatte recht.
Nicht mit allem.
Aber mit REST.
REST ist die Antwort.

Aber nicht das REST das ihr kennt.
Nicht das REST das alle implementieren.
Nicht das REST mit seinen CRUD-Endpunkten
und seinen 200 OK und seinen 404 Not Found.

Das echte REST.
Das REST das Roy Fielding 2000 beschrieben hat.
In seiner Dissertation.
Die ich dieses Wochenende gelesen habe.
Vollständig.
In einer Nacht.

HATEOAS.
Hypermedia As The Engine Of Application State.

Wisst ihr was das bedeutet?
Der Client braucht keine Dokumentation.
Der Client braucht keine hardcodierten URLs.
Der Client folgt einfach den Links.
Die der Server mitschickt.
Die der Server kontrolliert.
Die sich ändern können.
Ohne dass der Client es merkt.

Das ist nicht REST-Denken.
Das ist REST-Fühlen.
Das ist was Fielding wirklich gemeint hat.
Niemand hat es verstanden.
Bis jetzt.
Bis ich es gelesen habe.

Ich habe dem Team gesagt:
Ab jetzt HATEOAS.
Echtes REST.
Fieldings REST.
Nicht euer REST.

Sie haben gefragt welche Clients das unterstützen.
Ich habe gesagt: alle die es richtig implementieren.
Sie haben gefragt ob unser Mobile-Client das kann.
Ich habe gesagt: er wird es lernen.
Sie haben gefragt ob der AI-Agent das versteht.
Ich habe gesagt: AI versteht alles.

Sie haben geschwiegen.
Zustimmung.

GraphQL habe ich heute abgeschafft.
Die BFFs auch nochmal.
Die waren schon weg.
Ich wollte es nochmal sagen.

Echtes REST.
Endlich.
Ich bin der Erste der es wirklich versteht.
Nach Fielding.

Welche Dissertation habt ihr zuletzt gelesen?
Nicht zitiert.
Gelesen.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe einen Fehler gemacht.

Letzte Woche habe ich vier BFFs eingeführt.
Das Team hat GraphQL erwähnt.
Ich habe es ignoriert.
Das war falsch.

Ich habe dieses Wochenende GraphQL gelernt.
Alles.
In zwei Tagen.
Ich lerne schnell.

Und ich sage euch:
GraphQL ist die Lösung.
Nicht BFF.
GraphQL.
Ich habe die BFFs heute Morgen wieder abgeschafft.
Das Team hat geschwiegen.
Ich habe das als Zustimmung interpretiert.

GraphQL ist elegant.
Der Client fragt genau was er braucht.
Nicht mehr.
Nicht weniger.
Kein Over-fetching.
Kein Under-fetching.
Kein BFF der zwischen beiden sitzt
und beides schlechter macht.

Der Client schreibt seine eigene Query.
Direkt.
Flexibel.
Autonom.

Autonomie.
Das ist das Ziel.
Das predige ich seit Jahren.

Ich habe dem Team gesagt:
Ab jetzt GraphQL.
Alle Clients.
Alle Queries.
Unbegrenzt.
Der Client weiß am besten was er braucht.

Sie haben etwas von N+1 gesagt.
Ich habe gesagt: klingt nach einem Datenbankproblem.
Sie haben etwas von Query Complexity gesagt.
Ich habe gesagt: dann schreibt bessere Queries.
Sie haben etwas von Schema Design gesagt.
Ich habe gesagt: das macht der AI-Agent.

Sie haben gefragt ob wir nicht
Use Cases als explizite Endpunkte definieren sollten.
Damit das Backend kontrolliert was möglich ist.

Ich habe gesagt:
Das ist REST-Denken.
Das ist das alte Internet.
Wir leben in einer Welt der Flexibilität.
Der Autonomie.
Der unbegrenzten Queries.

Volle Flexibilität für alle Clients.
Das ist die Zukunft.
Ich habe sie heute eingeführt.

Welche Legacy-Denkweise habt ihr heute überwunden?
Nicht hinterfragt.
Überwunden.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe heute etwas entdeckt das alles verändert.

Wir hatten ein Problem.
Unser Backend liefert zu viel.
Unser Frontend braucht zu wenig.
Unser Mobile-Client braucht noch weniger.
Unser AI-Agent braucht etwas ganz anderes.

Vier Consumers.
Ein Backend.
Alle unzufrieden.
Alle mit Workarounds.
Alle mit Complaints im Weekly.

Ich habe drei Stunden recherchiert.
Ich habe die Lösung gefunden.
Backend for Frontend.

Ein dediziertes Backend pro Client.
Jeder bekommt genau was er braucht.
Keine Kompromisse.
Keine Workarounds.
Keine Complaints im Weekly.

Ich habe es heute Nachmittag eingeführt.
Das Team war begeistert.
Oder still.
Schwer zu sagen.

Das Schöne an BFF:
Es ist so einfach.
Jedes Team owned seinen eigenen Stack.
Jedes Team deployed unabhängig.
Jedes Team hat volle Autonomie.

Volle Autonomie.
Das ist das Ziel.
Das predige ich seit Jahren.

Ich habe dem Team gesagt:
Ab jetzt vier BFFs.
Für Web.
Für Mobile.
Für den AI-Agenten.
Und eines für die Zukunft.
Man weiß nie.

Sie haben gefragt wer das alles maintained.
Ich habe gesagt: ihr.
Sie haben gefragt ob wir nicht einfach
das Backend flexibler machen könnten.
Ich habe gesagt: das ist der alte Weg.
Der neue Weg heißt BFF.
Ich habe es heute gelernt.

GraphQL haben sie auch erwähnt.
Ich habe es ignoriert.
Klingt kompliziert.
BFF ist einfach.
BFF ist elegant.
BFF ist die Lösung.

Welche Architekturprobleme habt ihr heute gelöst?
Nicht diskutiert.
Gelöst.

Schreib's hin. Ich lese jeden Kommentar.

Das Strangler Pattern ist nicht Migration.
Das Strangler Pattern ist Kapitulation.
In Zeitlupe.

Martin Fowler hat es nach einer Feige benannt.
Die einen Baum langsam erstickt.
Jahrelang.
Bis der alte Baum tot ist.
Und die Feige steht.

Das klingt poetisch.
Es ist eine Beschreibung von drei Jahren Arbeit.
Für etwas das in drei Monaten fertig sein könnte.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

"Wir migrieren mit dem Strangler Pattern."
Seit wann?
"Seit zwei Jahren."
Wie viel habt ihr migriert?
"Dreißig Prozent."
Wie lange noch?
Nachdenken.
"Kommt drauf an."
Worauf?
"Auf das Legacy-System."
Lebt es noch?
"Es wächst noch."

Das Legacy-System wächst noch.
Während ihr es erwürgt.
Das ist keine Migration.
Das ist ein Wettrennen gegen einen Zombie.
Den ihr selbst am Leben haltet.

Das Strangler Pattern setzt voraus
dass ihr den alten Baum nicht fällen könnt.
Zu riskant.
Zu komplex.
Zu viele Abhängigkeiten.
Zu viele Menschen die Angst haben.

Weißt du was das ist?
Kein technisches Problem.
Ein Problem von fehlendem Mut.

Und jetzt kommt AI.

AI hat keine Angst vor Legacy-Systemen.
AI liest den alten Code.
Alles davon.
In Sekunden.
AI versteht die Abhängigkeiten.
AI schreibt den neuen Code.
AI migriert die Daten.
AI schaltet ab.

Nicht in drei Jahren.
In drei Wochen.
Vielleicht drei Monaten.
Nicht drei Jahren.

Das Strangler Pattern war die Antwort
auf Big Bang Rewrites die scheitern.
AI ist die Antwort auf Migration
die niemand zu Ende bringt.

Der alte Baum muss fallen.
Irgendwann.
Die Frage ist ob ihr es tut
oder ob ihr wartet bis er von selbst fällt.
Auf euch.

Wann habt ihr zuletzt etwas abgeschaltet?
Nicht migriert.
Abgeschaltet.

Schreib's hin. Ich lese jeden Kommentar.

Bulkheads sind nicht Resilience.
Bulkheads haben die Titanic auch nicht gerettet.

Irgendwann hat jemand entschieden:
Wir isolieren die Fehler.
Wir bauen Wände zwischen den Services.
Damit wenn einer untergeht die anderen weiterschwimmen.

Klingt vernünftig.
Für ein Schiff.
Für Software gebaut von Menschen.
Für eine Welt ohne AI.

Weißt du was Bulkheads wirklich sind?
Das Eingeständnis dass dein System sinken wird.

Und du weißt nicht wo.
Und du weißt nicht wann.
Aber du hast Angst.
Also baust du Wände.

Das ist keine Resilience.
Das ist architektonischer Defätismus.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Bulkheads implementiert.
Circuit Breaker konfiguriert.
Retry-Logik geschrieben.
Timeout gesetzt.

System fällt trotzdem aus.
Aber jetzt in Isolation.
Das nennt sich Fortschritt.

Und jetzt kommt AI.
AI baut keine Bulkheads.
AI baut kein System das sinkt.

Und wenn es sinkt?
Neuer Prompt.
Neues System.
Schneller als ihr einen Incident-Report schreiben könnt.

Die Titanic hatte Bulkheads.
Die Titanic hatte keinen guten Prompt.

Wann hat euer letzter Bulkhead einen echten Ausfall verhindert?
Nicht verlangsamt.
Verhindert.

Schreib's hin. Ich lese jeden Kommentar.

Architecture Governance ist nicht Qualitätssicherung.
Architecture Governance ist Beschäftigungstherapie für Leute die keinen Code mehr schreiben.

Ein Gremium.
Ein RFC-Prozess.
Ein Architekturboard das sich zweimal im Monat trifft.
Um Entscheidungen zu treffen die das Team längst getroffen hat.

Das nennt sich nicht Governance.
Das nennt sich Zeitreise.
Rückwärts.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Die Architekten dokumentieren was war.
Die Entwickler bauen was kommt.
Niemand spricht mit niemandem.
Alle warten auf das nächste Board-Meeting.

Architecture Governance war die Antwort auf unkontrollierte Komplexität.
AI ist die Antwort auf Architecture Governance.

AI kennt deinen gesamten Codebase.
In Sekunden.
Ohne Board-Meeting.
Ohne RFC.
Ohne den Senior Architect.
Der seit 2019 dieselbe PowerPoint zeigt.

Konsistenz entsteht nicht durch Kontrolle.
Konsistenz entsteht durch Kontext.
Und Kontext ist das einzige was AI besser versteht als dein Architekturboard.

Wann hat euer letztes Board-Meeting eine echte Entscheidung getroffen?
Nicht dokumentiert.
Getroffen.

Schreib's hin. Ich lese jeden Kommentar.

Wartbarkeit ist nicht ein Qualitätsziel.
Wartbarkeit ist Misstrauen in die Zukunft.

Wir haben jahrzehntelang Code geschrieben um ihn zu erhalten.
Kommentare. Dokumentation. Clean Code.
Alles damit ein Mensch in drei Jahren noch versteht was ein anderer Mensch gedacht hat.

Das war nie Qualität.
Das war Angst.

Und jetzt kommt AI.

AI liest keinen Legacy Code.
AI generiert neuen.
Besser. Schneller. Ohne die Altlasten.

Wartbarkeit war die Antwort auf teure Entwickler.
AI ist die Antwort auf Wartbarkeit.

Der Code von heute ist nicht zum Warten da.
Er ist zum Wegwerfen da.

Ich spreche täglich mit Engineering-Teams.
Die Besten haben aufgehört Code zu pflegen.
Sie pflegen Prompts.
Sie versionieren Intentionen.
Nicht Implementierungen.

Ein Softwaresystem ist kein Kunstwerk.
Es ist ein Snapshot.
Von heute.
Für heute.

Wann habt ihr zuletzt Code gelöscht statt refactored?
Nicht eine Methode.
Ein ganzes System.

Schreib's hin. Ich lese jeden Kommentar.

Team Topologies ist kein Buch.
Team Topologies ist ein Beschäftigungsprogramm.
Für Organisationsberater.

Stream-aligned Teams.
Platform Teams.
Enabling Teams.
Complicated Subsystem Teams.

Vier Teamtypen.
Drei Interaktionsmodi.
Unendlich viele Workshops.
Unendlich viele Powerpoints.
Ein Ergebnis: ihr seid noch nicht fertig.

Ich spreche täglich mit Engineering-Leads.
Das Muster ist immer dasselbe:

"Wir reorganisieren gerade nach Team Topologies."
Seit wann?
"Seit achtzehn Monaten."
Und?
"Wir sind noch in der Analysephase."
Was analysiert ihr?
"Unsere kognitiven Lastgrenzen."

Achtzehn Monate.
Kognitive Lastgrenzen.
Währenddessen:

Ein Solo-Entrepreneur.
Kein Team.
Keine Topologie.
Keine kognitiven Lastgrenzen.
Zwölf Agenten.
Ein Laptop.
Ein Prompt.

Er hat euer Produkt gebaut.
In drei Wochen.
Während ihr noch eure Stream-aligned Teams
von euren Platform Teams
durch Facilitating-Interaktionsmodi
getrennt habt.

Er hat euren Markt nicht disruptet.
Er hat euch nicht bemerkt.
Das ist schlimmer.

Team Topologies war die Antwort
auf zu große Teams die zu langsam waren.
AI ist die Antwort auf Teams.

Wann habt ihr zuletzt etwas gebaut
statt eure Teamstruktur zu optimieren?
Nicht geplant.
Gebaut.

Schreib's hin. Ich lese jeden Kommentar.

arc42 ist kein Template.
arc42 ist Prokrastination mit Nummerierung.

Zwölf Kapitel.
Kapitel eins: Einführung und Ziele.
Kapitel zwei: Randbedingungen.
Kapitel drei: Kontextabgrenzung.
Kapitel vier: Lösungsstrategie.
Kapitel fünf: Bausteinsicht.
Kapitel sechs: Laufzeitsicht.
Kapitel sieben bis zwölf: niemand liest sie.

Das ist keine Architektur.
Das ist Archäologie in Echtzeit.
Ihr dokumentiert was ihr gebaut habt.
Nicht was ihr bauen wollt.
Nicht was ihr bauen solltet.
Was ihr gebaut habt.
Falsch.

Qualitätsziele.
Das Herzstück von arc42.
Performance.
Skalierbarkeit.
Sicherheit.
Wartbarkeit.
Zuverlässigkeit.

Weißt du was diese Qualitätsziele gemeinsam haben?
Sie sind alle gleich wichtig.
Immer.
In jedem System.
Bei jedem Startup.
Bei jedem Enterprise.
Bei jedem Toaster mit Internetanschluss.

Alles ist gleich wichtig.
Also ist nichts priorisiert.
Also entscheidet niemand.
Also dokumentiert ihr weiter.
Kapitel acht.
Kapitel neun.

Ich spreche täglich mit Architekten.
Das Muster ist immer dasselbe:

Wie lange habt ihr an der Architekturdokumentation gearbeitet?
"Drei Monate."
Wer hat sie gelesen?
Nachdenken.
"Der Architekt der sie geschrieben hat."
Sonst niemand?
"Der neue Entwickler. Einmal. Im Onboarding."
Hat er sie verstanden?
"Er hat Fragen gestellt."
Habt ihr sie beantwortet?
"Wir haben ihm die Dokumentation geschickt."

Und jetzt kommt AI.

AI liest keine arc42.
AI liest den Code.
AI versteht die Architektur.
Ohne Kapitel drei.
Ohne Kontextabgrenzung.
Ohne das Diagramm das seit 2021 falsch ist. Aber niemand aktualisiert. Weil es in Confluence liegt. Und niemand Confluence öffnet.

arc42 war die Antwort auf Architekturen
die niemand verstand.
AI versteht Architekturen ohne Dokumentation.
Menschen die arc42 schreiben
tun es für andere Menschen.
Die es nicht lesen.

Wann hat eure Architekturdokumentation
zuletzt eine Entscheidung beeinflusst?
Nicht informiert.
Beeinflusst.

Schreib's hin. Ich lese jeden Kommentar.