Module Federation seit fünf Jahren produktiv gebaut — bei Convanit, bei Siemens AG. Der Audit beurteilt euer MF-Setup von jemandem, der es selbst gebaut hat: Lohnt sich der Wechsel zu Native Federation? Wenn ja, wie? Wenn nein, warum nicht?
Gemessen am gleichen App-Ausschnitt vor und nach der Migration von Module Federation auf Native Federation. Hauptursache der Verbesserung: sauberes Scoping geladener Angular-Versionen über Import Maps.
Module Federation hat funktioniert. Aber jedes Major-Release von Angular kostet Tage an Webpack-Konfigurations-Arbeit, die niemand mehr will. Der Wechsel zu Native Federation ist absehbar — die Frage ist nicht ob, sondern wann, wie, mit welchem Risiko.
Die Antwort kann ein Architekt nicht aus dem Bauch geben. Sie hängt an konkreten Faktoren: Wie viele Remotes? Welche Shared Dependencies? Welche Build-Pipeline? Welche Team-Topologie? Welche Angular-Version, welche CI-Laufzeit, welche Deployment-Strategie?
Eine NF-Migration scheitert selten an Native Federation. Sie scheitert am unsauber inventarisierten Ist-Zustand.
„Wir sollten migrieren, aber niemand traut sich, eine Roadmap zu schreiben.“ Es gibt einen Konsens, dass Module Federation Wartungsschmerz erzeugt — aber kein verbindliches Bild, was der Wechsel kostet, wo die Risiken sitzen und in welcher Reihenfolge.
„Wir haben angefangen und stecken fest.“ Erste Spikes existieren, aber Shared Dependencies, Versionierung oder die Build-Topologie bremsen aus. Es fehlt eine externe Sicht, die das Knäuel auseinandersortiert.
„Der Lead hat gewechselt, das Wissen ist weg.“ Die Original-Architekten der MF-Setups sind nicht mehr im Team. Die aktuelle Mannschaft braucht eine Außenperspektive, um die Architektur zu verstehen, bevor sie sie verändert.
2 Tage Remote-Audit. Schriftliche Ergebnisse innerhalb 5 Werktagen nach Abschluss.
Schriftliche Bestandsaufnahme eures Module-Federation-Setups: Remote-Topologie, Shared-Dependency-Graph, Build-Pipeline, kritische Kopplungspunkte. Inklusive Performance-Hotspots im Host/Remote-Setup (Bundle-Splits, Lazy-Loading, Shared-Dep-Versionierung) — als Kontext, nicht als separate Tiefenanalyse.
Drei Check-Items, die im Audit immer geprüft werden — weil sie häufig den Migrationspfad bestimmen:
Konkreter Phasen-Plan für den Wechsel — sequentiell oder inkrementell, je nach euer Topologie. Welche Remotes zuerst, welche Shared Deps neu verhandelt werden müssen, wo Schnittpunkte mit Angular-Updates liegen.
Die zehn größten Risiken eures Setups, priorisiert nach Eintrittswahrscheinlichkeit und Auswirkung. Jeweils mit konkreter Mitigation. Die Liste, die euer Engineering Lead dem CTO zeigt.
Live-Session mit Architekt:innen und Tech Leads: Report-Walkthrough, offene Fragen, gemeinsame Priorisierung. Aufgezeichnet, damit das Team später nachhören kann.
Die eigentliche Migration ist nicht Teil des Audits — wenn ihr sie durchführt, kann sie AI-gestützt erfolgen. Bei Siemens haben wir die Migration über Schematics skaliert (jedes Team migrierte selbst). Heute würde derselbe Hebel über Coding-Agents laufen — wie ich es bei der Migration von 44 Angular-Komponenten in SAP Spartacus mit Worktrees, Skill-Pattern und Review-Gates gemacht habe.
„Aus heutiger Perspektive würde ich mehr auf agentisches Programmieren setzen — wenn ich sehr viele gleichartige Probleme habe, das einmal lösen und der Agent setzt es um. Ich review's.“ — meine eigene Position.
Aus dem Audit fällt eine klare Roadmap; ob ihr sie selbst, klassisch oder AI-gestützt umsetzt, ist eine getrennte Entscheidung. Falls AI-gestützt: Praxisbericht 44 Komponenten Spartacus →
Kurzer Call: Stack, Größenordnung, was ihr euch vom Audit erhofft. Klärung, ob der Audit passt — wenn nicht, ehrliche Empfehlung, was sonst sinnvoll wäre.
Read-Only-Zugang zum Monorepo (oder relevanten Repos), bestehende Architektur-Dokumentation, Build-Konfigurationen. Ein 60-Min-Stakeholder-Call mit Architekt:in oder Tech Lead.
Zwei zusammenhängende oder gesplittete Tage. Code-Analyse, Stakeholder-Interviews bei Bedarf, Erarbeitung von Roadmap und Risiko-Matrix.
Schriftliche Deliverables zugestellt, anschließend 90-Min-Walkthrough mit dem Team. Danach steht das Mandat: weiterführende Begleitung optional, kein Lock-in.
Offizielles Board-Mitglied an der Seite von Ingenieuren aus BMW, Dutch Railways, DAZN, Santander und Sanitas. Mitgestaltung der Architektur-Linie, nicht nur Anwender.
native-federation.com/team15 Teams, 150 Entwickler in der Reichweite, Angular 17–19. Architektur-Design und Migration auf die Native-Federation-Linie. Genau die Art von Migration, die dieser Audit vorbereitet.
"One of Lutz's most outstanding qualities is his technical depth and rigor. […] He played a key role in designing, analyzing, and evolving solutions first based on Module Federation and later on Native Federation. […] A deep understanding of Angular internals, build systems, runtime behavior, and architectural trade-offs."Matteo Murgida — System Architect, Siemens
Module Federation in einem gemischten Stack (React-Host, Angular-Remotes, Razzle-Build, Jotai-State). MF nicht in der Theorie, sondern mit allen Stolperstellen aus mehreren Jahren Produktivbetrieb — die Erfahrungs-Basis, aus der ein NF-Audit-Urteil kommt.
Angular-Host, React-Whiteboard, Svelte-Mermaid-Editor in einer App. Web Components als Boundary, typed Event Bus, jeder Remote auch standalone lauffähig. Der praktische Beleg zu den Patterns auf dieser Seite.
Zum ProjektKönnt ihr — und wenn ihr die Kapazität und die externe Vergleichserfahrung habt, solltet ihr es sogar. Der Audit lohnt sich für Teams, bei denen interner Konsens fehlt oder bei denen Stakeholder eine externe Begründung erwarten.
Für einen Audit ja. Ich liefere keine Implementierung in 2 Tagen — ich liefere eine Diagnose und eine Roadmap. Das ist mit guter Vorbereitung (siehe Ablauf) realistisch und entspricht dem Format, das auch große Beratungen anbieten — nur ohne deren Overhead.
Im Erstgespräch klären wir den Zuschnitt. Sehr große Landschaften (mehr als 10 Remotes, mehr als 3 Teams) brauchen typischerweise einen Plus-Audit (3 Tage, €6.500 netto). Kleinere Setups laufen im Standard-Format. Wenn euer Fall aus dem Standard-Korridor fällt, sage ich das im Erstgespräch — ohne Preisspielchen.
Dann ist der Audit ein Sanity-Check: zweite Meinung auf Architektur-Entscheidungen, Risiko-Matrix als Validierung. Manche Kunden buchen ihn genau dafür — bevor sie ein größeres Migrations-Mandat starten.
Möglich, aber nicht erforderlich. Aus dem Audit kann ein längeres Mandat werden (Migrations-Begleitung, Architektur-Review, Workshop für das Team), muss aber nicht. Der Audit selbst steht für sich.
Dann ist die Hauptseite die richtige Anlaufstelle. Dort gibt es Mandate, Workshops und Praxis-Sessions zum breiteren Thema „GenAI in Enterprise-Codebasen“ — Native Federation ist nur eine Teilfacette davon. Services auf der Hauptseite ansehen →
Erstgespräch zum Audit. Setup, Voraussetzungen, Termin.
Danke — Nachricht ist angekommen.
Ich melde mich binnen 48 Stunden zurück.
Da ging etwas schief. Bitte direkt an hello@lutzleonhardt.de.
Oder direkt per Mail: hello@lutzleonhardt.de