Was bleibt von Microfrontends?

TRUE independent teams

Am Anfang dieser Serie stand ein Satz, der mich nicht mehr losgelassen hat:

TRUE independent teams

TRUE war vollständig großgeschrieben. Das klang nach Marketing, und ein Marketingversprechen wird nicht dadurch wahrer, dass man es lauter schreibt.

Nach 21 Artikeln über Grenzen, Ownership, Releases, Runtime-Integration, Betrieb und Kosten lässt sich der Satz noch einmal lesen – diesmal ohne die Häme, die ihm beim ersten Mal zustand.

Das Versprechen war nicht grundsätzlich falsch. Es war nur unvollständig. Echte Team-Autonomie entsteht nicht dadurch, dass eine Anwendung technisch in einen Host und mehrere Remotes zerlegt wird. Sie entsteht, wenn eine ganze Reihe weiterer Bedingungen erfüllt ist: klare fachliche Grenzen, klare Ownership, explizite Verträge, unabhängige Veränderbarkeit und Testbarkeit, kontrollierte Releases, beherrschbare Runtime-Abhängigkeiten, Ausfallgrenzen, Observability, Plattform-Guidance, Governance – und eine Organisation, die diese Grenzen tatsächlich respektiert, wenn es unbequem wird.

Das technische Remote ist nur ein Teil davon. Es war nie das eigentliche Ziel – es war immer nur eines von mehreren möglichen Mitteln, um dieses Ziel zu erreichen.

Das eigentliche Ziel waren nie die Remotes

Host und Remotes sind technische Mittel. Das eigentliche Ziel ist Veränderungsautonomie – die Fähigkeit, eine Änderung zu entscheiden, umzusetzen, zu testen, zu veröffentlichen und zu betreiben, ohne dafür regelmäßig den Rest der Organisation koordinieren zu müssen.

Ein Produkt kann zehn Remotes besitzen und trotzdem hochgradig gekoppelt sein:

Members-Remote ändern
        ↓
Shell muss angepasst werden
        ↓
Tasks-Team muss ebenfalls ändern
        ↓
gemeinsame Testumgebung erforderlich
        ↓
gemeinsame Abnahme
        ↓
gemeinsamer Release-Termin

Die technische Architektur ist verteilt. Die Arbeit ist es nicht.

Das Remote ist unabhängig deploybar. Für seine nächste Änderung fehlen nur noch die Freigaben von drei anderen Teams.

Kein Architekturdiagramm zeigt diesen Zustand. Ein Diagramm zeigt Boxen und Pfeile, keine Slack-Nachrichten, in denen ein Team auf die Freigabe eines anderen wartet. Genau deshalb lässt sich echte Autonomie nicht an der Zahl der Boxen ablesen, sondern nur daran, wie eine Änderung tatsächlich durch die Organisation läuft.

Grenzen schaffen Verantwortungsräume

Ein Motiv zieht sich durch die gesamte Serie: Wem gehört die URL? Wem gehört ein fachlicher Zustand? Wem gehört ein Geschäftsprozess? Wem gehört die UI, ein Fehler, ein Release, ein API-Vertrag? Was gehört in die Shell, was in ein Remote? Wer darf eine Produktkomposition aktivieren?

Diese Wiederholung war kein Zufall. Hinter fast jeder Microfrontend-Frage steckt am Ende eine Ownership-Frage.

klare Grenze
        ↓
klarer Verantwortungsraum
        ↓
klare Ownership
        ↓
weniger notwendige Abstimmung
        ↓
mehr tatsächliche Team-Autonomie

Eine Grenze allein erzeugt daraus allerdings noch nichts. Eine Grenze ohne Ownership bedeutet, dass niemand den Bereich wirklich trägt. Ownership ohne klare Grenze bedeutet, dass mehrere Teams denselben Verantwortungsraum verändern. Eine Deployment-Grenze ohne fachliche Grenze bleibt technisch verteilt und organisatorisch gekoppelt. Und eine fachliche Grenze ohne operative Verantwortung endet damit, dass ein Team seinen Code besitzt, beim Testen, Releasen oder Betrieb aber weiterhin wartet.

Klare Grenzen sind kein Selbstzweck. Sie schaffen einen Raum, für den ein Team Verantwortung übernehmen kann. Erst diese Verantwortung macht Autonomie möglich.

Deshalb lohnt es sich, bei jeder neu gezogenen Grenze dieselbe Kontrollfrage zu stellen: Wer trägt diesen Bereich, wenn er nachts ausfällt, wenn ein Kunde sich beschwert oder wenn eine Migration ansteht? Fällt die Antwort schwer, war die Grenze vermutlich technisch motiviert und nicht organisatorisch gemeint.

Unabhängigkeit ist keine Isolation

TRUE independent teams darf nicht mit vollständiger Isolation verwechselt werden. Teams in einem gemeinsamen Produkt teilen weiterhin Produktziele, Benutzer, Plattform, Design-Grundsätze, technische Standards, Sicherheitsanforderungen, APIs, teilweise Geschäftsprozesse und eine gemeinsame Produktionsumgebung. Vollständige Unabhängigkeit wäre weder realistisch noch besonders sinnvoll.

Relevant sind deshalb vor allem die Abhängigkeiten, die gemeinsame Veränderung und organisatorische Synchronisation erzwingen.

Ein Team ist nicht unabhängig, weil es keine Abhängigkeiten besitzt. Es ist unabhängig, wenn seine Verantwortung so klar abgegrenzt ist, dass die meisten Änderungen innerhalb dieser Grenze entschieden, umgesetzt, getestet, veröffentlicht und betrieben werden können.

Autonomie braucht Guidance

Unabhängige Teams brauchen gemeinsame Guidance. Das ist kein Widerspruch zur Autonomie, sondern ihre Voraussetzung: Ohne gemeinsame technische Leitplanken löst jedes Team dieselben Plattformprobleme noch einmal selbst – Integrationsverträge, Observability, Security, Release-Metadaten, Design-System, Build- und Deployment-Konventionen.

Guidance macht gute lokale Entscheidungen einfacher. Zentrale Kontrolle macht lokale Entscheidungen unmöglich. Ein Plattformteam kann Autonomie unterstützen. Es kann ebenso gut zum nächsten Flaschenhals werden. Die Grenze verläuft dort, wo ein Team für alltägliche Änderungen wieder regelmäßig eine andere Organisationseinheit braucht.

Ownership ist dabei kein Kästchen im Organigramm. Eine organisatorische Zuordnung allein reicht nicht. Das Team muss die Verantwortung, die innerhalb seiner Grenze liegt, auch tatsächlich tragen können – einschließlich Betrieb, Fehleranalyse und Weiterentwicklung.

Ein Organigramm kann ein Team einem Remote zuordnen. Es kann nicht erzwingen, dass dieses Team die damit verbundene Verantwortung auch tatsächlich trägt. Genau dieser Unterschied entscheidet, ob aus einer sauberen Architekturzeichnung am Ende echte Autonomie wird oder nur eine weitere Zeile in einer Zuständigkeitstabelle.

Das lernt man nicht im Getting Started

Microfrontends sind nichts, was eine Organisation mal eben einführt. Auch erfahrene Entwickler beherrschen eine verteilte Frontend-Architektur nicht automatisch, nur weil sie Angular, React oder Module Federation kennen. Die Fallstricke liegen selten dort, wo das erste Tutorial sie zeigt. Sie liegen später: Ein Remote braucht plötzlich Shell-State. Ein globaler Event-Bus wird zur fachlichen Integrationsschicht. Shared Libraries transportieren versteckte Ownership. Unabhängige Releases benötigen weiterhin die komplette Produktabnahme. Die Shell sammelt immer mehr Produktwissen. Runtime-Versionen driften auseinander. Ein Rollback trifft auf inzwischen inkompatible APIs. Observability kann einen Benutzerfehler keinem konkreten Build mehr zuordnen. Ein Plattformteam wird zur zentralen Warteschlange.

Die schwierigen Probleme entstehen meist erst nach dem ersten erfolgreichen Deployment.

Microfrontend-Architektur ist eine Fähigkeit, die Teams und Organisationen lernen müssen – nicht im Sinne eines Zertifikats, sondern durch Erfahrung, klare Architekturprinzipien, gemeinsame Guidance, Review, Feedback aus der Produktion und die Bereitschaft, Grenzen zu verändern, wenn sie nicht funktionieren.

Das erste Remote lässt sich in wenigen Tagen aufsetzen. Die Erfahrung, welche scheinbar harmlose Abhängigkeit in zwei Jahren zum Problem wird, entsteht wesentlich langsamer – oft erst, nachdem man die Folgen einer ähnlichen Entscheidung bereits erlebt hat.

Architekturgrenzen erodieren in kleinen Ausnahmen

Viele schlechte MFE-Architekturen scheitern nicht daran, dass die verwendete Technik grundsätzlich falsch wäre. Sie erodieren. „Nur dieses eine Shared Package.“ „Nur dieser eine Shell-Service.“ „Nur dieses eine globale Event.“ „Nur dieser eine gemeinsame Release-Schritt.“

Jede einzelne Ausnahme wirkt für sich genommen vernünftig. Über Jahre entsteht daraus wieder eine gekoppelte Architektur.

Architekturgrenzen verschwinden selten in einer großen Entscheidung. Meist werden sie in sehr vernünftigen kleinen Ausnahmen abgetragen.

Autonomie braucht deshalb nicht nur initial gute Grenzen. Sie braucht Pflege.

Die Zahl der Remotes misst nichts

Erfolg bedeutet nicht: möglichst viele Remotes, möglichst kleine Remotes, möglichst viele Repositories, möglichst viele Deployments, möglichst viele Frameworks oder möglichst wenig Shared Code. Ein Team kann auch zu weit zerlegen.

Am Ende zählt, ob die Verteilung tatsächlich Koordination reduziert oder nur mehr Infrastruktur geschaffen hat. Verteilung lohnt sich nur, wenn die vermiedene Koordination langfristig mehr kostet als die Verteilung selbst.

Der modulare Monolith ist kein Rückschritt

Ein modularer Monolith ist kein gescheitertes Microfrontend-System. Wenn ein Team oder wenige eng zusammenarbeitende Teams einen Bereich gemeinsam verändern, testen und veröffentlichen können, kann der Monolith die wirtschaftlich und technisch bessere Lösung sein. Ebenso kann eine Migration bewusst stoppen. Ebenso kann ein ehemals getrenntes Remote später wieder konsolidiert werden.

Architektur ist kein Fortschrittsbalken von Monolith über Microfrontends zu noch mehr Microfrontends. Ein Team, das seinen Bereich im Monolithen souverän beherrscht, ist nicht auf dem Weg zu etwas Besserem – es ist bereits am Ziel, das diese ganze Serie beschreibt. Wer nach diesen 21 Artikeln entscheidet, hier keine Microfrontends zu brauchen, trifft eine ebenso valide Architekturentscheidung wie jemand, der sich bewusst für eine verteilte Lösung entscheidet.

Woran erkennt man tatsächliche Autonomie?

Eine gute MFE-Architektur zeigt sich im Alltag, nicht im Architekturdiagramm. Fünf Beobachtungen genügen: Ein Team kann seine Capability ändern, ohne regelmäßig mehrere andere Teams koordinieren zu müssen. Das Remote lässt sich unabhängig entwickeln und fokussiert testen. Eine normale Änderung erzwingt keine vollständige Produktabnahme. Fehler und Ausfälle bleiben innerhalb klarer Grenzen. Und ein Produktionsproblem lässt sich einem konkreten Build und einer konkreten Produktkomposition zuordnen.

Die Gegenprobe ist genauso aufschlussreich: Wenn eine Änderung am Members-Remote regelmäßig Änderungen an Shell, Tasks, einer Shared Library und anschließend eine gemeinsame Abnahme benötigt, ist die Architektur möglicherweise verteilt. Die Veränderung ist es nicht.

Keine dieser Beobachtungen benötigt ein Dashboard. Sie lassen sich in jedem Team beantworten, das ehrlich auf die letzten Releases zurückblickt.

TRUE independent teams noch einmal gelesen

Als ich TRUE independent teams zum ersten Mal las, störte mich vor allem das TRUE. Nach dieser Serie ist der Blick differenzierter.

Das Versprechen ist erreichbar – wenn independent nicht mit isoliert verwechselt wird. Es braucht klare Ownership, tragfähige Grenzen, Plattform-Guidance, technische Verträge, passende Betriebsmodelle, Disziplin und Erfahrung. Und die Organisation muss bereit sein, diese Verantwortung tatsächlich an Teams abzugeben.

Eine Architektur kann Teamautonomie ermöglichen. Eine Organisation kann sie trotzdem verhindern.

Vielleicht war TRUE also gar nicht das problematische Wort. Problematisch war die Vorstellung, man bekäme es mit dem ersten Remote kostenlos dazu.

Microfrontends sind nicht kompliziert um ihrer selbst willen, sie lohnen sich nicht automatisch, und sie sind auch keine Zukunft, der man sich anschließen muss. Sie sind ein Werkzeug für eine bestimmte Situation: Mehrere Teams arbeiten an einem gemeinsamen Frontend, sollen ihre Bereiche aber verändern können, ohne für alltägliche Änderungen ständig aufeinander warten zu müssen. Wo diese Situation nicht besteht, lösen Microfrontends nichts, was nicht auch anders zu lösen wäre.

TRUE independent teams sind möglich. Aber sie sind das Ergebnis einer bewusst gestalteten Architektur und Organisation – nicht der Ausgangszustand nach nx generate.

Eine gute Microfrontend-Architektur erkennt man nicht daran, wie verteilt das Frontend ist, sondern daran, wie wenig Organisation eine einzelne Änderung benötigt.