Problem 10: wenn das Organigramm zur Architektur wird
Ein weiteres Problem ist, wenn das Organigramm zur Architektur wird. Es hängt ein bisschen mit Problem 7 zusammen, hat aber einen organisatorischen Aspekt, über den ich schon oft mit Thibault(öffnet im neuen Fenster) gesprochen habe.
Wenn Teams anfangen, Dutzende Microservices zu entwickeln, organisieren sie sich oft nach Teamverantwortung statt nach Fachbereich. Es gibt dann also zum Beispiel ein "Zahlungsteam", ein "Wachstumsteam" und so weiter. Die Dienste werden in den Kubernetes-Namespace deployt, der Terraform-Stack wird ins AWS-Konto des Teams eingestellt und alle Dashboards und Alarme mit dem Slack-Kanal des Teams verknüpft.
Auf dem Papier sieht das ordentlich aus. Jedes Team hat seine klare Ownership, seine Autonomie und seinen Spielraum, in dem es experimentieren kann, ohne andere zu stören – bis das Organigramm sich verändert (und es verändert sich ständig).
Dann kommt ein neuer VP of Engineering, mit neuen Ideen für mehr Effizienz und bessere Abstimmung, und strukturiert um. Plötzlich wird das "Payments-Team", das für zwei klar begrenzte Kontexte zuständig war – beispielsweise "Payments" und "Subscriptions" -, in zwei Teams aufgeteilt.
Ein Team behält "Payments", das andere übernimmt "Subscriptions". Doch die gesamte Infrastruktur, die Namespaces und die IAM-Richtlinien sind nach wie vor im alten Konto verflochten.
Nun gibt es zwei Möglichkeiten:
- Die Infrastruktur wird gemeinsam genutzt und damit eine neue Art von Abhängigkeitschaos geschaffen.
- Es wird alles migriert – was nur eine kunstvolle Umschreibung ist für: "Herzlichen Glückwunsch, du hast dir gerade ein sechsmonatiges Migrationsprojekt eingehandelt!"
Keine der Optionen fühlt sich gut an. Die erste bremst die Teams aus und verursacht Unklarheiten bei den Zuständigkeiten ("Wer kümmert sich jetzt um diesen Alarm?"). Die zweite verschwendet Zeit und Budget für Arbeiten, die keinen Mehrwert für die Nutzer haben.
Das Problem reicht tiefer als bis zu Cloudkonten oder Namespaces. Es betrifft die Kopplung an die Organisationsstruktur. Wenn Conways Gesetz (g+) auf Umstrukturierungen trifft, kommt es zu einem architektonischen Drift. Systeme, die einst die Teamstruktur widergespiegelt haben, überdauern sie und plötzlich spiegelt die Topologie der Plattform wider, wer 2021 wem unterstellt war.
Das ist eine der teuersten Arten von technischen Schulden. Sie bleibt lange unsichtbar und verdreifacht dann plötzlich das (nicht vorhandene) Budget für Umstrukturierungen.
Die neue Normalität
Vier Jahre nach meinem ersten Text sehe ich immer noch dieselben Muster, nur verpackt in andere Frameworks, Clouds und YAML-Dialekte. Die Tools haben sich weiterentwickelt, die Grundlagen jedoch nicht: Verteilte Systeme bleiben verteilt, Menschen bleiben Menschen und die Komplexität bleibt ungebrochen.
Was als Nächstes kommt, wird das Ganze noch interessanter machen. Wir versuchen nun, KI-Agenten zu entwickeln: autonome, zustandsbehaftete Systeme, die miteinander kommunizieren, wahrscheinlichkeitsbasierte Entscheidungen treffen und auf unvorhersehbare Eingaben reagieren. Mit anderen Worten: verteilte Systeme mit eigenen Meinungen. Was kann da schon schiefgehen?
Die Trugschlüsse bleiben die gleichen, nur auf einer anderen Ebene. Weder Latenz noch Konsistenz, Beobachtbarkeit oder Determinismus verschwinden auf magische Weise, nur weil die Komponente nun "denkt".
Als Branche werden wir den gleichen Zyklus erneut durchlaufen: anfängliche Begeisterung, kreative Katastrophen, Booms von Werkzeugen und schließlich ein bisschen Demut.
Ob Microservices oder KI-Agenten: Die Geschichte ändert sich nicht grundlegend. Wir versuchen immer noch, chaotische Systeme dazu zu bringen, sich vorhersehbar zu verhalten. Und wir tun so, als könnten wir sie vollständig kontrollieren.
Die gute Nachricht ist: Wir werden weiter lernen. Die schlechte Nachricht: wahrscheinlich auf die harte Tour.
Übersetzt von Juliane Gunardono mit Unterstützung von DeepL
- Anzeige Hier geht es zum Handbuch für Softwareentwickler bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.



