This case study is also available in English
TL;DR
Die Challenge
Phoenix Contact wollte seine veraltete E-Commerce-Plattform durch eine moderne, branchenführende Lösung ersetzen, um die digitale Kundenerfahrung zu verbessern.
Unser Lösungsansatz
INNOQ setzte auf Self-contained Systems (SCS), um eine flexible, erweiterbare und effiziente Plattform zu schaffen, die sich schnell an neue Anforderungen anpassen lässt.
Das Ergebnis
Die neue Plattform bietet nicht nur eine verbesserte Benutzerführung und individuelle Produktkonfiguration, sondern auch eine deutlich erhöhte Geschwindigkeit, Stabilität und kontinuierliche Update-Fähigkeit. Wurde auf der vorherigen Plattform maximal 1 Release pro Monat mit einer Downtime von 1–2 Tagen durchgeführt, sind es nun im Durchschnitt 10 Updates pro Tag ohne Downtime.
Hörempfehlung: CTO Need To Know Podcast “Legacy-Modernisierung: Shop-Monolithen knacken” mit Peter Whitmore, Director Engineering Digital Business Platform, Phoenix Contact
Die Anforderungen an den Relaunch der Webplattform und deren technische Performance waren hoch: Als neue digitale Kundenschnittstelle sollte sie sowohl als Unternehmens-Website als auch als E-Shop dienen. Ein Muss war also ein ansprechendes Design und eine einfache Benutzer:innenführung. Ein absoluter USP im Markt ist die individuelle Konfigurierbarkeit vieler Produkte von Phoenix Contact. Es geht im E-Shop also nicht nur um den reinen Verkauf von Lagerbestandsartikeln. Die Plattform ist vor allem auch ein Planungstool mit zielgerichteten B2B-Kundenlösungen, wie Musterbestellungen oder individualisierbaren Produkten durch die Einbindung bzw. Verlinkung zu eigenständigen Konfiguratoren.
Außerdem leiteten sich aus den Schwächen der bestehenden Plattform einige Grundbedingungen ab:
- mehr Stabilität
- höhere Geschwindigkeit
- schnellere Updates
- Responsiveness
- kontinuierliche Relaunch-Fähigkeit
Eine zusätzliche Herausforderung war der internationale Vertrieb mit knapp 50 Länderauftritten in 23 Sprachen, mit regionaler User Experience und lokalisierter Darstellung von ca. 150.000 Produkten pro Land. Alles in allem sollte das Zusammenspiel aller Elemente im Rahmen der Customer Journey reibungslos funktionieren und Phoenix Contact noch offensiver als E-Commerce-Unternehmen positioniert werden. So viel vorweg: Eine fertige Softwarelösung kam dafür nicht in Betracht.
Unabhängige Systeme für eine ganzheitliche Lösung
Die für den Relaunch verantwortliche Organisationseinheit bei Phoenix Contact ist DXM (Digital Customer Experience Management). Dort werden die digitalen Touchpoints zwischen Phoenix Contact und den Kund:innen entwickelt. Die Unit wurde für den Aufbau der Plattform gegründet, die intern CRISP (Continuous Relaunchable International Sales Platform) genannt wird.
Der darin enthaltene Begriff “Relaunchable” ist eine von vielen Anforderungen, um dedizierte Funktionen in der Plattform unabhängig anzupassen und freizuschalten und führte schließlich zur Entscheidung des Architekturansatzes: Self-Contained Systems (SCS).
Die Kernidee von Self-Contained Systems (SCS) ist es, ein fachlich komplexes System in mehrere kleinere, möglichst autarke Systeme und damit auch einfacher handhabbare Webanwendungen aufzuteilen. SCS erfüllt damit genau die Anforderungen, die Phoenix Contact an die neue Plattform stellt. Es gibt nur wenige Abhängigkeiten. Dadurch ist das System wesentlich schneller und fehlertoleranter. Außerdem kann viel flexibler auf neue Anforderungen reagiert werden, neue Features oder Updates können schnell und problemlos installiert werden und ebenso wichtig: Es ist einfach erweiterbar. Denn die Self-Contained Systems orientieren sich an der Customer Journey – jeder Touchpoint wird zur eigenen Domäne, wie z.B. Explore, Search, Product oder Customer Interaction. Aus den anfänglich vier Domänen sind inzwischen acht geworden. Sie werden jeweils von einem eigenen Team ganzheitlich verantwortet. So können unabhängig voneinander und schnell neue Funktionen entwickelt, umgesetzt und veröffentlicht werden.
Make and Buy – Ein Kompromiss als Wettbewerbsvorteil
Klassischerweise gilt bei der Entscheidung für eine Software “Make or Buy”. Also die Wahl zwischen einer schon existierenden Standardlösung oder der Eigenentwicklung. Beides hat Vor- und Nachteile. Doch zu den Anforderungen von CRISP passte beides nicht so richtig. Es sollte die beste technische Lösung gefunden werden, die der Konkurrenz einen großen Schritt voraus ist. In den gemeinsamen Hackathons von Phoenix Contact und INNOQ entstand schließlich die Idee von “Make and Buy”.
Technische Highlights
Software Architektur:
- Self-Contained Systems, Microservices, Asynchrone Kommunikation und Datenreplikation
- Server-seitige und client-seitige Frontend Integration, Server-Side Includes
- Security Gateway, Reverse Proxy, Legacy Backend Integration
- Continuous Delivery, Feature Flags
Software Development:
- Java, Spring Boot, Thymeleaf, Maven, JUnit
- Javascript, node.js, vue.js, HTML, CSS, NPM, Jest, Nuxt
- REST, JSON, JSON Schema, Swagger
- Gitlab, Nexus, Docker, Conduktor
Service Infrastruktur:
- AWS Cloud, Managed Service Kafka, OpenSearch, OpenLogging, Kibana
- DocumentDB, Postgres, FactFinder, Contentful, Dynatrace
- nginx, Okta, SEO URL Mapping Service, Google Tag Manager
Für einige Anwendungen gab es bereits gut funktionierende Standard-Tools auf dem Markt, z.B. Suchmaschinen oder Auftragsverwaltung. Sie konnten einfach in die Plattform integriert werden, während sich die Entwicklungsteams auf das Wesentliche konzentrieren konnten – spezielle Anwendungen, die zum Kerngeschäft und zu den Bedürfnissen von Phoenix Contact und seinen Kund:innen passen. Dazu zählt etwa die Einbindung bestehender und heterogener ERP-Systeme ausländischer Tochtergesellschaften oder das große Thema Produkt-Konfiguration.
Partnerschaft auf Augenhöhe
Die Zusammenarbeit von INNOQ und Phoenix Contact zeichnet sich durch eine strategische Partnerschaft aus, die während der Entwicklung kontinuierlich ausgeweitet wurde. Basis für das Engagement bei Phoenix Contact ist ein wichtiges Arbeitsprinzip von INNOQ: Nicht als autarkes Entwicklungsteam rein- und rausgehen, sondern Hand in Hand zusammenarbeiten. Das bedeutet nicht nur technologisches Know-how und Erfahrung weiterzugeben und die Expertise im Unternehmen gemeinsam weiterzuentwickeln. Es bedeutet auch, neue Formen der Teamarbeit vorzuleben und zu etablieren, die Menschen mitzunehmen und neue Organisationsmodelle vorzuschlagen. Davon profitieren alle. Weil die Zusammenarbeit harmonischer und von gegenseitigem Respekt geprägt ist, weil man gemeinsam schneller zu besseren Ergebnissen gelangt und – vor allem – weil das Unternehmen das Projekt langfristig auch ohne die Unterstützung von INNOQ fortführen kann.
Mit der Entscheidung, einen Dienstleister für das Projekt an Bord zu holen, welche Kriterien waren Euch dabei besonders wichtig?
Uns war vor allem wichtig, dass wir ein unabhängiges Beratungshaus haben, das uns in der Weiterentwicklung unserer Teams unterstützt und nicht nur ein Produkt verkauft oder alles selber umsetzt. Der Dienstleister sollte dazu eine hohe technische Kompetenz besitzen sowie Bereitschaft zum Wissenstransfer haben. Er sollte aber auch eine pragmatische Herangehensweise mitbringen, um ein so großes Projekt in der verfügbaren Zeit und dem geplantem Budget über die Ziellinie bringen zu können. Dabei sollte er von der Arbeitsweise zu der lockeren und liberalen Arbeitskultur passen, die wir im neuen Bereich DXM etablieren wollten, aber auch Verständnis mitbringen, dass wir kein Start-up sind, sondern Teil eines Konzerns mit all den damit verbundenen Herausforderungen.
Warum habt Ihr Euch für INNOQ entschieden?
INNOQ hat in der Vorauswahl alle unsere Kriterien erfüllt und schon beim Kennenlernen in den ersten Workshops war klar, dass die Zusammenarbeit mit den INNOQ Consultants auf fachlicher und menschlicher Ebene einfach super funktioniert. Besonders gut gefallen hat uns die pragmatische Herangehensweise: einerseits alle Möglichkeiten aufzuzeigen, andererseits im Miteinander nicht die vermeintlich beste, sondern passende Lösung im Projektkontext zu finden. Da war direkt das Vertrauen da, dass INNOQ der richtige strategische Partner für Phoenix Contact ist. Ein weiterer Grund war auch, dass wir bei INNOQ die Unterstützung für den gesamten Entwicklungszyklus aus einer Hand bekommen haben und nicht mehrere Dienstleister koordinieren mussten. Das hat uns die Projektarbeit wesentlich erleichtert. Und natürlich auch, dass wir mit INNOQ den Urheber von Self-Contained Systems (SCS) und entsprechende Kompetenz aus erster Hand mit an Bord hatten.
Was sind Eure Learnings aus dem Projekt? Was würdet Ihr genauso noch einmal tun, was anders angehen?
In der mehrjährigen Zusammenarbeit haben sowohl Phoenix Contact als auch INNOQ viel voneinander gelernt. Ein Erfolgsfaktor war sicherlich das Aufsetzen gemischter Teams, was wesentlich für den von uns gewünschten Wissenstransfer und Erfahrungsaustausch war. Das Projekt und auch die Entwickler:innen von Phoenix Contact haben dadurch stark profitiert und das würden wir genauso wieder tun. Ein anderes Learning ist die Remote Arbeit, die wir bei Phoenix Contact zunächst nicht gewohnt waren, doch besonders durch die Erfahrungen mit INNOQ im Laufe der Zeit schätzen gelernt haben. Das hat uns nicht zuletzt auch in der Coronapandemie sehr geholfen. Das würden wir heute von Anfang an so starten. Ein weiteres Learning ist, dass die Consultants zwar einen großen Einfluss auf Entscheidungen haben, doch letztlich wir in der Verantwortung sind, welchen Rat wir annehmen und wie wir unsere Vision im Unternehmenskontext verfolgen wollen.
Eine Frage zum Abschluss: Würdet Ihr es noch einmal tun?
Ja, auf jeden Fall. Der Erfolg unserer Zusammenarbeit und das gewachsene Vertrauensverhältnis bestärken uns, die strategische Partnerschaft mit INNOQ auch in Zukunft fortzusetzen.
Momentan umfasst die interne Entwicklungsabteilung DXM bei Phoenix Contact um die 40 Mitarbeiter:innen. Insgesamt arbeiten etwa 60 interne sowie externe Personen an der Plattform. Wobei INNOQ die meisten Teams mit mindestens einer Person unterstützt.
Die agilen Teams sind jeweils so konzipiert, dass darin alle Disziplinen vertreten sind, die man braucht, um ein SCS zu bauen und zu betreiben. Da nicht jedes Team immer komplett ausgelastet ist, übernehmen in einer späteren Projektphase z.B. UX- oder DevOps-Fachleute diese Rolle auch in anderen Teams. Die Team-Organisation befindet sich demnach in einem stetigen Prozess und wird dem Entwicklungsstand der Plattform angepasst.
Ein Musik-Streamingdienst als Organisationsvorbild
Wie bereits angedeutet, hat die neue Plattform auch die Arbeitsweise bei Phoenix Contact verändert. Denn das SCS-Architekturmodell funktioniert nur, wenn auch Strukturen und Prozesse angepasst werden. Vorbild war in diesem Fall die Organisation nach dem sogenannten Spotify-Modell. Diese agile Arbeitsweise, die beim Musik-Streamingdienst Spotify zuerst angewandt wurde, gilt inzwischen auch als Role Model für andere große und agil organisierte Unternehmen. Es verbessert die Zusammenarbeit und den fachlichen Austausch der eigenständig organisierten Teams und sorgt dafür, dass das Hauptziel der Plattform nicht aus dem Fokus gerät.
Das Spotify-Modell zeichnet sich aus durch die Unterteilung in Squads, Tribes, Chapter und Guilds. Ein Squad ist eine Basiseinheit der Entwicklungsabteilung mit allen nötigen Fähigkeiten von Design über den Release bis hin zu Production. Ein Tribe umfasst mehrere Squads, die in verwandten Bereichen arbeiten, um den gegenseitigen Austausch zu fördern. Chapter fassen Mitglieder verschiedener Squads zusammen, die ähnliche Fähigkeiten oder Aufgaben haben, z.B. Product Owner. Sie treffen sich regelmäßig, um besondere Herausforderungen zu besprechen. Ein Guild ist eine Art Interessengemeinschaft. Also eine tribe-übergreifende Gruppe von Personen, die Wissen und Methoden miteinander teilen wollen.
Durch die Zusammenarbeit mit INNOQ konnten wir unser Skillset ideal ergänzen. Dabei hatten wir durchaus hohe technische Ansprüche, denen INNOQ aber voll und ganz gerecht werden konnte. Zusätzlich haben wir stets auf Augenhöhe agiert und an einem Strang gezogen. Für die Umsetzung hätten wir uns daher keinen besseren Partner wünschen können.
Peter WhitmoreDirector Engineering Digital Business Platform, Phoenix Contact
Das Spotify Modell funktioniert ähnlich wie eine Fußballmannschaft. Das Team – also ein Squad – besteht aus Personen mit bestimmten Fähigkeiten: Sturm, Mittelfeld, Abwehr etc. Die Abwehrspieler:innen bilden zusammen ein Chapter. Und die Trainer:innen – die Product Owner, Chapter Leads oder Tribe Leads – sitzen nicht außen auf der Bank, sondern spielen mit. Und wenn das Team gewinnt, gewinnen nicht nur einzelne, sondern alle gemeinsam.
Bei Phoenix Contact orientiert man sich an diesem Organisationsmodell, nimmt sich aber die Freiheit, es den eigenen Bedürfnissen anzupassen. Vorreiter ist dabei die DXM-Abteilung mit CRISP. Gemeinsam ist allen der feste Glaube an selbstorganisierte Teams. Die Plattform ist unternehmensintern das beste Beispiel dafür, dass das funktioniert.
