Magenta View CRM: vom Trainer zum Frontend-Architekten, 200+ Entwickler skalieren
Deutsche Telekom · Magenta View CRM · 2021 – 2023
Die Situation
Deutsche Telekom ersetzte Oracle Siebel durch eine moderne CRM-Plattform: Magenta View. Tausende von Call-Center-Agenten in europäischen Märkten waren täglich auf dieses System angewiesen. Die neue Plattform musste über 200 parallel arbeitende Entwickler in mehreren Länderteams unterstützen, jedes mit eigenen regulatorischen Anforderungen und marktspezifischen Funktionen.
Das eigentliche Problem
Ich kam als Frontend-Trainer. Die ursprüngliche Aufgabe war die Schulung der ersten Welle von etwa 50 Entwicklern in HTML5, CSS3, Vue.js und Git-Workflows. Doch während der Schulung begann ich, dem Chief Architect Fragen zur Architektur zu stellen und Richtungen vorzuschlagen. Je tiefer ich eindrang, desto klarer wurde es: Das Team brauchte nicht nur Schulung. Es brauchte architektonische Führung.
Mit über 200 Entwicklern in mehreren europäischen Märkten lag die Kernherausforderung nicht in der Technologie. Es ging um Governance. Wie lässt man Dutzende von Teams unabhängig bauen, ohne dass die Plattform auseinanderfällt? Wie wahrt man Konsistenz für tausende Endnutzer und erlaubt gleichzeitig länderspezifische Anpassungen?
Zentrale Entscheidungen
- Vom Trainer zu einem von zwei Frontend-Architekten aufgestiegen, um die Anwendungsrichtung zu entwickeln und zu steuern. Das gab mir die Autorität, übergreifende Entscheidungen zu treffen, die alle Teams betrafen, nicht nur die, die ich schulte.
- Eine Pattern Library eingeführt als einzige Quelle der Wahrheit für UI-Komponenten. Das wurde das Fundament, auf dem das UX-Team später sein Design-System aufbaute. Jedes Team griff auf denselben Komponentensatz zurück, was die visuelle Inkonsistenz beseitigte, die entsteht, wenn über 200 Entwickler unabhängig voneinander bauen.
- Einen Finite-State-Machine-Ansatz eingeführt für das State-Management. Das brachte Vorhersagbarkeit in die Art und Weise, wie die Anwendung komplexe Zustandsübergänge verwaltete, und ermöglichte es Teams, das Anwendungsverhalten nachzuvollziehen, ohne den Code jedes anderen Teams zu verstehen.
- Eine framework-agnostische Microfrontend-Architektur konzipiert, die es Teams ermöglichte, ihre Werkzeuge innerhalb klar definierter Grenzen frei zu wählen. Die Integrationsschicht ermöglichte unabhängige Deployments, sodass jedes Team jederzeit liefern konnte, ohne sich mit anderen abstimmen zu müssen.
Die Feature-Velocity stieg um 30%, da Teams unabhängig entwickeln und deployen konnten. Die Pattern Library wurde zur gemeinsamen Sprache zwischen Engineering und Design. Die Microfrontend-Governance-Patterns ermöglichten echte parallele Entwicklung über europäische Märkte hinweg. Die Plattform ersetzte Oracle Siebel erfolgreich für tausende von Call-Center-Agenten und bewahrte dabei ein konsistentes Nutzererlebnis in allen Märkten. Letztlich arbeiteten über 200 Entwickler parallel an derselben Plattform.
Die Übergabe
Zweijähriger Auftrag von 2021 bis 2023. Die Pattern Library, der State-Management-Ansatz und die architektonische Governance wurden dokumentiert und an das interne Architekturteam der Deutschen Telekom übergeben. Die in diesem Auftrag etablierten Patterns leiteten weiterhin die Weiterentwicklung der Plattform in neuen Märkten.
Stehen Sie vor einer ähnlichen Herausforderung?
Jede Situation ist anders, aber die Muster wiederholen sich. Wenn Ihr Team nicht weiterkommt, Ihre Architektur unklar ist oder Sie kurz vor einer wichtigen technischen Entscheidung stehen, schildern Sie mir Ihre Situation.