Viel zu oft wird der Eindruck vermittelt, das alles, was sich nicht Microservice nennen darf, automatisch ein böser alter Monolith ist. Dabei liegt die Kunst genau darin, verteilte Architekturen nur so weit zu treiben, wie sie für die Bedürfnisse des jeweiligen Geschäfts sinnvoll sind. Und auf keinen Fall weiter, denn man holt sich schnell neue Probleme rein, die größer sind als jene, die man loswerden möchte. Die Session zeigt an einem Beispiel aus dem Bankenumfeld, wie rein *fachliche* Anforderungen ganz automatisch und schrittweise zu einer verteilten Architektur geführt haben, die aus diesem Weg ihrer Herleitung auch keiner Sinn-Diskussion bedarf. Wenn man Verteilung wirklich braucht, dann wird man es merken. Dafür braucht man z.B. Trunk-based Development und Single-Repo nicht aufgeben und behält sich die angesagten Hype-Begriffe lieber für ein gepflegtes Bullshit-Bingo vor.