Den 50. Entwickler einzustellen sollte Sie schneller machen. Meistens macht es alle langsamer. Builds dauern länger. Pull Requests stauen sich. Eine Änderung in einem Modul bricht etwas in einem anderen. Teams warten aufeinander, anstatt auszuliefern. Sie haben nicht mehr Engineers eingestellt, um weniger zu produzieren. Und trotzdem stehen Sie genau hier.

Ich habe an zwei grossen Plattformen gearbeitet, bei denen dieses Skalierungsproblem im Mittelpunkt stand: eine CRM-Ablösung für Tausende von Call-Center-Agenten auf europäischen Märkten und eine Industrieautomatisierungsplattform, die von einem Team auf viele wachsen musste. In beiden Fällen funktionierte die Technologie einwandfrei. Die Koordination nicht.

Warum Koordination zum Engpass wird

Wenn fünf Entwickler an einer Codebase arbeiten, entsteht Koordination auf natürlichem Weg. Menschen reden miteinander. Jeder weiss, woran die anderen arbeiten. Code Reviews fangen Konflikte früh auf. Das gemeinsame mentale Modell des Systems passt in alle Köpfe.

Bei 50 Entwicklern bricht das zusammen. Bei 200 ist es unmöglich. Man kann nicht darauf vertrauen, dass alle wissen, was andere Teams tun. Man kann nicht alle den Code aller anderen reviewen lassen. Man kann nicht alles in einen Branch mergen und das Beste hoffen.

Der Instinkt ist, das durch Prozesse zu lösen. Mehr Meetings. Mehr Genehmigungsschritte. Mehr Koordinationskanäle. Aber auch Prozesse skalieren nicht. Jede Koordinationsebene, die man hinzufügt, erzeugt Wartezeiten. Teams blockieren auf Reviews. Features stagnieren im Staging. Releases werden zu Zeremonien statt zu Routineabläufen.

Die eigentliche Frage ist nicht, wie man 200 Entwickler koordiniert. Sie lautet: Wie macht man Koordination für 90 Prozent ihrer Arbeit überflüssig?

Der Governance-Stack

Governance ist ein schwieriges Wort in der Softwareentwicklung. Es klingt nach Bürokratie. In der Praxis ist gute Governance das, was Teams ermöglicht, schnell zu arbeiten, ohne sich gegenseitig die Arbeit zu sabotieren. Es ist die Menge an Vereinbarungen, Grenzen und gemeinsamen Grundlagen, die die Notwendigkeit von Einzelfallkoordination eliminiert.

Ein Governance-Stack für grosse Frontend-Entwicklung hat typischerweise vier Ebenen:

Pattern Library. Ein gemeinsamer Satz von UI-Komponenten, den jedes Team verwendet. Keine Leitlinien, keine Empfehlungen. Echte, getestete, dokumentierte Komponenten. Wenn jedes Team auf demselben Fundament aufbaut, entsteht visuelle Konsistenz von selbst, anstatt bei jedem Pull Request ein Design-Review zu erfordern.

Contracts zwischen Modulen. Klare Definitionen, wie Module kommunizieren. Welche Events kann ein Modul senden? Welche Daten erwartet es? Was ist die API-Oberfläche zwischen unabhängig deployten Teilen? Diese Contracts sind die Grenzen, die es Teams ermöglichen, ihre internen Implementierungen zu ändern, ohne andere zu beeinflussen.

Ownership-Grenzen. Jedes Modul hat genau ein Team, das es besitzt. Ownership bedeutet: Sie entscheiden, was hineinkommt, sie reviewen Änderungen, sie sind on call, wenn es bricht. Geteilte Ownership ist keine Ownership. Wenn etwas von jedem geändert werden kann, ist niemand dafür verantwortlich, es gesund zu halten.

Deployment-Unabhängigkeit. Jedes Team kann sein Modul nach eigenem Zeitplan deployen, ohne andere Teams zu koordinieren. Das ist die Auszahlung. Wenn die ersten drei Ebenen stimmen, wird unabhängiges Deployment sicher. Überspringt man sie, wird es zum Chaos.

Microfrontends als Organisationswerkzeug

Die meisten Gespräche über Microfrontends konzentrieren sich auf die technische Implementierung. Module Federation, Import Maps, Web Components, Iframe-Isolation. Das sind Implementierungsdetails. Der eigentliche Wert von Microfrontends ist organisatorisch.

Eine Microfrontend-Architektur bildet Code-Grenzen auf Team-Grenzen ab. Jedes Team besitzt einen Bereich der Applikation. Es kann ihn unabhängig entwickeln, testen und deployen. Es trifft eigene technische Entscheidungen innerhalb seiner Grenze. Es braucht keine Erlaubnis, um auszuliefern.

Deshalb ist die Framework-Wahl weniger wichtig, als die meisten denken. Ich habe Microfrontend-Architekturen mit Vue, React, Angular und framework-agnostischen Ansätzen funktionieren sehen. Die Architektur steht und fällt damit, wie gut die Grenzen gezogen und wie gut die Contracts zwischen Modulen durchgesetzt werden. Das Framework ist nur das, was innerhalb der Grenze läuft.

Auf der Deutsche Telekom CRM-Plattform haben wir eine framework-agnostische Microfrontend-Architektur entwickelt, die es 200+ Entwicklern auf europäischen Märkten ermöglichte, unabhängig auszuliefern. Die Feature-Velocity stieg um 30 Prozent, nicht wegen besserer Technologie, sondern weil Teams aufhörten, aufeinander zu warten.

Unabhängige Deployments ohne Chaos

Unabhängiges Deployment klingt grossartig, bis es zum ersten Mal schiefgeht. Team A deployed eine Änderung, die das Modul von Team B bricht, weil es sich auf ein undokumentiertes Verhalten verlassen hat. Jetzt gibt es einen Incident, gegenseitige Schuldzuweisungen und den Ruf nach mehr Integrationstests und Koordination. Genau das, was man vermeiden wollte.

Die Lösung ist nicht mehr Testing auf der Integrationsebene. Sie liegt in besseren Contracts auf der Grenzebene. So sieht das in der Praxis aus:

Explizite Integrationspunkte definieren. Jede Stelle, an der Module interagieren, sollte einen dokumentierten Contract haben: Events, gemeinsamer State, Routing und UI-Slots. Was nicht im Contract steht, existiert nicht. Teams sollten alles ändern können, was nicht im Contract steht, ohne andere zu beeinflussen.

Contracts versionieren. Contracts entwickeln sich weiter. Ein Modul muss vielleicht neue Daten zu einem Event hinzufügen oder die Form eines gemeinsamen State-Objekts ändern. Versionieren Sie die Contracts, damit Konsumenten in ihrem eigenen Tempo migrieren können, anstatt gezwungen zu sein, synchron zu aktualisieren.

Contracts testen, nicht Integrationen. Jedes Team testet, ob sein Modul seine Contracts einhält. Wenn jedes Modul seinen Contract erfüllt, funktioniert die Integration per Definition. Das ist schneller und zuverlässiger als End-to-End-Integrationstests, die exponentiell teurer werden, je mehr Module es gibt.

Einen Canary-Prozess für gemeinsame Änderungen nutzen. Wenn ein Contract sich tatsächlich ändern muss, führen Sie ihn schrittweise ein. Deployen Sie die neue Version neben der alten. Migrieren Sie Konsumenten einzeln. Das ist langsamer als eine Big-Bang-Änderung, eliminiert aber den Koordinations-Engpass.

Die richtige Governance: zu locker versus zu eng

Governance scheitert in zwei Richtungen.

Zu locker und man erhält Fragmentierung. Jedes Team baut seine eigene Komponentenbibliothek. Die UX ist über Module hinweg inkonsistent. Technische Schulden häufen sich in Silos an, die niemand sehen kann, bis ein Team geht und jemand anderes ihren Code pflegen muss. Die Siemens SIMATIC AX-Plattform begann hier: alles in einer Codebase ohne klare Grenzen, was bedeutete: keine klare Ownership.

Zu eng und man erhält den Engpass, den man vermeiden wollte. Jede Änderung braucht die Genehmigung eines zentralen Architektur-Teams. Die Pattern Library wird zum Gatekeeper statt zum Enabler. Teams umgehen die Governance, weil sie langsamer ist als ohne.

Das richtige Gleichgewicht sieht so aus:

  • Verpflichtend: Contracts und Ownership. Jedes Modul hat eine definierte Schnittstelle und ein verantwortliches Team. Das ist nicht optional. Ohne das ist unabhängiges Deployment eine Haftung.
  • Stark empfohlen: Pattern Library-Adoption. Gemeinsame Komponenten zu nutzen sollte der Weg des geringsten Widerstands sein. Machen Sie die Pattern Library so gut, dass Teams sie gegenüber eigenen Lösungen bevorzugen. Aber blockieren Sie kein Team darin, eine eigene Komponente zu bauen, wenn die Pattern Library ihren Anwendungsfall tatsächlich nicht abdeckt.
  • Flexibel: Technische Entscheidungen innerhalb der Grenzen. Wenn ein Team innerhalb seines Moduls einen anderen State-Management-Ansatz verwenden möchte, lassen Sie es. Solange es seine Contracts einhält und sein Modul die Performance- und Barrierefreiheitsanforderungen erfüllt, sind die internen Entscheidungen seine eigenen.

Worauf Sie achten sollten

Die "Alles teilen"-Falle. Eine gemeinsame Runtime, eine gemeinsame Build-Pipeline oder ein gemeinsames Deployment-Ziel über Module hinweg führt die Kopplung wieder ein, die man aufgeteilt hat. Gemeinsame Infrastruktur sollte auf das wirklich Gemeinsame beschränkt bleiben: Authentifizierung, Routing-Shell, Design Tokens, und nichts darüber hinaus.

Governance ohne Durchsetzung. Schriftliche Leitlinien, die niemand prüft, sind Dekoration. Nutzen Sie automatisierte Prüfungen, wo möglich: Contract-Validierung in CI, Metriken zur Pattern Library-Adoption, Bundle-Size-Budgets pro Modul. Was man nicht messen kann, wird im grossen Massstab nicht eingehalten.

Den Migrationspfad ignorieren. Die meisten Teams starten nicht mit einer sauberen Microfrontend-Architektur. Sie starten mit einem Monolithen und müssen von hier nach dort gelangen, während sie Features ausliefern. Planen Sie die Migration in Phasen. Jede Phase sollte eigenständig Wert liefern, nicht nur die nächste Phase vorbereiten.

Engineering-Teams zu skalieren ist kein Technologieproblem. Es ist ein Governance-Problem. Die Technologie (Microfrontends, Module Federation, was auch immer als Nächstes kommt) gibt nur den Mechanismus. Was es zum Funktionieren bringt, sind klare Ownership, durchgesetzte Contracts, eine gemeinsame Komponentenbasis und die Disziplin, Teams innerhalb klar definierter Grenzen unabhängig zu agieren. Gelingt das, machen 200 Entwickler Sie wirklich schneller.

Verwandter Artikel: Design Systems als Infrastruktur