Ausgangslage – Wo lag das Problem?

USM ist kein klassischer Webshop-Case. Bei einer internationalen Design- und Möbelmarke reicht es nicht, Produkte aufzulisten und Bestellungen entgegenzunehmen. Das digitale System dahinter muss Konfigurationen, Partnerlogik, Vertriebszuordnung, Kundenkonten, CRM-Daten, Shop-Bestellungen, Länderlogik, Sprachen, Medien, Inhalte und interne Prozesse sauber zusammenspielen lassen.

Über die Jahre war eine digitale Landschaft entstanden, die viele Aufgaben erfüllte, aber zunehmend schwer wartbar wurde. Shop, Konfigurator, CRM, Partnerdaten, Kundenkonto, Content-Systeme und weitere Umsysteme hatten jeweils eigene Datenmodelle und eigene Logiken. Einzelne Anforderungen waren deshalb selten isoliert lösbar. Eine Anpassung am Checkout konnte Auswirkungen auf Partnerzuordnung, CRM-Erstellung, Konfigurator-Payloads, Kundenkonto oder Bestellverarbeitung haben.

Das Problem war nicht ein fehlendes Feature. Das Problem war die Architektur.

Ein monolithischer Ansatz funktioniert, solange die digitale Welt überschaubar bleibt. Sobald aber Shop, internationale Vertriebspartner, CRM-Prozesse, Konfigurator, Kundenportal und diverse Integrationen zusammenkommen, wird ein einzelnes grosses System zur Bremse. Releases werden riskanter. Verantwortlichkeiten verschwimmen. Daten werden mehrfach gehalten. Löschprozesse werden fehleranfällig. Alte Links müssen weiter funktionieren. Neue Systeme müssen integriert werden, ohne bestehende Prozesse zu brechen.

smartfactory entwickelte deshalb schrittweise eine Microservice-Architektur, welche einzelne Verantwortlichkeiten sauber trennt und trotzdem über APIs zusammenführt. Aus einer eng gekoppelten Systemlandschaft entstand ein digitales Ökosystem aus eigenständigen Services, die jeweils klar definierte Aufgaben übernehmen.

Dabei ging es nicht darum, möglichst viele Microservices zu bauen. Es ging darum, die richtigen Grenzen zu ziehen: Partnerdaten gehören in einen anderen Service als Kundenpräferenzen. CRM-Kommunikation gehört nicht in jedes einzelne System. Weiterleitungen und Affiliate-Logik müssen zentral gesteuert werden. Identität und Authentifizierung müssen übergreifend funktionieren. User-Löschung darf nicht manuell in jedem System einzeln passieren. Bestellungen müssen Shop, Konfigurator, CRM und Partnerlogik konsistent verbinden.

Heute ist daraus eine über Jahre gewachsene Plattformarchitektur entstanden, die über ein Dutzend eigenständige Services umfasst und zentrale digitale Vertriebsprozesse von USM trägt.

Umsetzung - Was haben wir gemacht?

smartfactory baute für USM eine modulare Architektur rund um Shop, Kundenkonto, Konfigurator, Partnerlogik, CRM-Anbindung und operative Datenflüsse.

Ein wichtiger Grundsatz war API-first. Die einzelnen Services kommunizieren über definierte Schnittstellen miteinander. Dadurch können Shop, Konfigurator, CRM, Identity-System, Partnerlogik und weitere Komponenten Daten austauschen, ohne direkt voneinander abhängig zu sein.

Ein erster zentraler Baustein war die saubere Server-zu-Server-Kommunikation. Interne Services brauchen stabile Zugriffsrechte, ohne für jede neue API-Funktion wieder aufwendig neu konfiguriert zu werden. smartfactory setzte dafür ein kontrolliertes API-Key-Konzept für interne Systeme um. Externe Integrationen erhielten dagegen ein restriktiveres Berechtigungsmodell, bei dem nur definierte Endpunkte und Aktionen freigegeben werden. So bleibt die Architektur flexibel, ohne Sicherheitsgrenzen aufzuweichen.

Darauf aufbauend entstanden verschiedene fachliche Services.

Ein Service übernimmt die Verwaltung und Bereitstellung von Vertriebspartnerdaten. Diese Daten stammen aus dem führenden CRM-System und werden regelmässig synchronisiert. Andere Systeme können dadurch auf Partnerdaten wie Land, Sprache, Status oder Identifikatoren zugreifen, ohne selbst direkt mit dem CRM kommunizieren zu müssen. Zusätzlich werden daraus Shop- und Konfiguratorlinks erzeugt, die einen Vertriebspartner korrekt in den späteren Verkaufsprozess einbinden.

Ein weiterer Service löst das Problem alter und neuer Linkstrukturen. Über die Jahre waren unterschiedliche Affiliate- und Partnerlink-Formate im Umlauf. Diese einfach abzuschalten, hätte bedeutet, bestehende Partner, Websites und Kampagnen zu brechen. smartfactory entwickelte deshalb eine regelbasierte Redirect-Logik, welche verschiedene URL-Formate erkennt, relevante Partnerinformationen ausliest und Nutzer an den richtigen Zielort weiterleitet. Alte Links funktionieren weiter, neue Linkformate können kontrolliert eingeführt werden.

Für nutzerspezifische Daten entstand ein eigener Service zur Speicherung von Präferenzen und Konfigurationen. Dieser nimmt strukturierte JSON-Daten aus anderen Anwendungen entgegen, speichert sie einem Nutzer zugeordnet und stellt sie später wieder bereit. Damit konnten beispielsweise Konfigurationen aus dem Produktkonfigurator mit dem Kundenkonto verbunden werden, ohne dass der Konfigurator selbst zur zentralen Datenhaltung werden musste.

Ein weiterer zentraler Baustein war das Identity- und Access-Management. USM brauchte eine saubere Grundlage für Login, Benutzeridentitäten, Service-Authentifizierung, Rollen und spätere Kundenkonto-Funktionen. smartfactory integrierte dafür eine zentrale Identitätslösung und baute darauf ein eigenes Kundenkonto-Frontend auf. So konnten Standardfunktionen wie Login, Registrierung und Zugriffssicherheit mit einem markenkonformen Nutzererlebnis kombiniert werden.

Die CRM-Anbindung wurde ebenfalls entkoppelt. Statt dass jeder Service direkt mit dem CRM spricht, entstand eine zentrale Kommunikationsschicht. Diese stellt definierte Endpunkte für Adressen, Bestellungen, Accounts, Vertriebspartner und weitere CRM-nahe Prozesse bereit. Dadurch wird die Kommunikation vereinheitlicht: Andere Services müssen nicht alle Eigenheiten des CRM kennen, sondern sprechen mit einer stabilen internen API.

Ein besonders heikler Bereich war der Umgang mit doppelten oder uneindeutigen Kundendaten. Das CRM verhindert nicht in jedem Fall, dass mehrere Einträge mit derselben E-Mail-Adresse existieren. smartfactory entwickelte deshalb Logiken zur Dublettenprüfung und Priorisierung. Wenn ein neuer Account oder eine Bestellung erstellt wird, prüft das System, ob bereits passende Einträge existieren, und entscheidet nach klaren Regeln, ob ein neuer Datensatz erstellt oder ein bestehender verwendet wird.

Auch der Shop- und Checkout-Prozess wurde weiterentwickelt. Dazu gehörten Rechnungs- und Lieferadressen, die Unterscheidung zwischen Privat- und Firmenkunden, dynamische Formularlogik, CRM-Mapping und konsistente Opportunity-Erstellung. Ziel war, dass alle Services, die vertriebsrelevante Vorgänge erzeugen, nach derselben Datenstruktur arbeiten.

Für Bestellungen aus externen Shop-Systemen wurde eine Synchronisationslogik aufgebaut. Bestellungen werden abgeholt, gespeichert, dedupliziert, relevante Daten werden serialisiert und anschliessend an die passenden Zielsysteme weitergegeben. Besonders wichtig war dabei die Zuordnung zum richtigen Vertriebspartner. Dafür wurde ein Mechanismus entwickelt, der Partnerinformationen aus der Nutzerreise bis in den Bestellprozess übernimmt.

Ein weiteres Thema war die automatische und konsistente Löschung von Nutzerdaten. In einer Microservice-Landschaft liegen Userdaten nicht zwangsläufig an einem einzigen Ort. Früher mussten Daten in mehreren Services manuell gesucht und gelöscht werden. Das ist fehleranfällig und kann zu ungültigen Zuständen führen. smartfactory entwickelte deshalb einen zentral gesteuerten Löschprozess: Eine Löschanforderung wird angestossen, die betroffenen Services werden nacheinander informiert, Rückmeldungen werden protokolliert und fehlgeschlagene Löschungen automatisch erneut versucht.

Zusätzlich wurden Konfigurator-Flows integriert. USM-Produkte können konfiguriert und je nach Fall direkt in den Warenkorb gelegt oder als Anfrage weitergeführt werden. Dabei müssen Preis, Bild, Konfigurationsdaten, Sprache, Land, Vertriebspartner, Hash-Prüfung und Weiterleitung korrekt zusammenspielen. smartfactory definierte und implementierte die nötigen Schnittstellen, damit der Konfigurator sicher mit Shop und weiteren Systemen interagieren kann.

Später kamen weitere Prozesslogiken hinzu: automatische Vertriebspartner-Zuordnung nach Lieferadresse, faire Verteilung von Aufträgen in Gebieten mit mehreren Partnern, Speziallogiken für Kleinmengenbestellungen, Synchronisation von Liefer- und Rechnungsadressen sowie Weiterleitung projektrelevanter Dateien an nachgelagerte Systeme.

Das Projekt ist dadurch nicht ein einzelner Shop, sondern eine laufend weiterentwickelte Architektur für digitale Vertriebsprozesse.

Systemarchitektur und technische Tiefe

Die technische Tiefe des USM-Projekts liegt im Zusammenspiel vieler Systeme mit klar getrennten Verantwortlichkeiten.

Der Shop ist nur die sichtbare Oberfläche. Dahinter laufen Partnerlogik, Konfigurator-Integration, CRM-Kommunikation, Kundenkonto, Authentifizierung, Bestellverarbeitung, Redirect-Regeln, Datenhaltung, Löschprozesse und Synchronisationen. Jedes dieser Themen hat eigene Regeln, eigene Datenquellen und eigene Fehlerfälle.

Die Microservice-Architektur hilft, diese Komplexität kontrollierbar zu machen. Jeder Service übernimmt eine abgegrenzte Aufgabe:

• Partnerdaten bereitstellen und synchronisieren
• Partner- und Affiliate-Links erzeugen und weiterleiten
• alte Linkformate in neue Zielstrukturen überführen
• Kundenpräferenzen und Konfigurationen speichern
• Benutzeridentitäten und Authentifizierung verwalten
• CRM-Kommunikation kapseln
• Accounts, Adressen und Bestellungen synchronisieren
• Shop-Bestellungen mit Partnerdaten anreichern
• Konfigurator-Daten sicher in Shop- und Anfrageprozesse überführen
• Nutzerdaten über mehrere Services hinweg konsistent löschen
• Vertriebspartner anhand Adresse und Regeln automatisch zuweisen
• projektrelevante Dateien zwischen Systemen weiterleiten
• Admin- und Backoffice-Prozesse unterstützen

Wichtig ist dabei nicht die reine Anzahl der Services. Entscheidend ist, dass jeder Service eine klare fachliche Grenze hat. Genau das unterscheidet eine belastbare Microservice-Architektur von einer verteilten Monolithen-Landschaft.

Ein Beispiel: Die CRM-Kommunikation wurde nicht überall einzeln implementiert. Stattdessen gibt es eine zentrale Schicht, welche CRM-spezifische Eigenheiten kapselt und anderen Services eine stabilere interne API bietet. Das reduziert Fehler, vereinfacht Tests und verhindert, dass jedes System dieselbe Speziallogik nachbauen muss.

Ein weiteres Beispiel ist die Partnerlogik. Partnerdaten werden aus dem CRM synchronisiert, Links werden daraus generiert, Weiterleitungen werden regelbasiert ausgewertet, Checkout-Sessions übernehmen Partnerinformationen, Bestellungen speichern diese Zuordnung und CRM-Prozesse erhalten daraus verwertbare Daten. Das ist ein durchgängiger Prozess über mehrere Systeme hinweg — aber nicht als ein grosser Block gebaut, sondern über klar getrennte Services.

Auch das Identity- und Access-Management ist zentral. In einem Ökosystem mit mehreren Services reicht ein einzelnes Login-Formular nicht. Es braucht Benutzeridentitäten, Service-Authentifizierung, Rechte, externe API-Zugriffe und klare Berechtigungen für interne und externe Kommunikation. smartfactory hat diese Ebene so aufgebaut, dass sowohl Nutzer als auch Services kontrolliert mit dem System arbeiten können.

Dazu kommt Betrieb und Wartung. Eine Microservice-Architektur muss überwacht, deployed, gesichert und versioniert werden. Neue Services dürfen bestehende Prozesse nicht destabilisieren. Bestehende Services müssen weiterlaufen, während einzelne Teile angepasst oder erweitert werden. Genau deshalb ist die Architektur nicht nur Entwicklungsarbeit, sondern auch Betriebsdisziplin.

Warum Standardsoftware hier nicht gereicht hätte

USM hätte einzelne Teilprobleme mit Standardsoftware lösen können: Shop, CMS, CRM, PIM, DAM, Identity Provider, Partnerportal, Redirect-Tool oder Konfigurator-Anbindung.

Aber das eigentliche Problem lag nicht in einem einzelnen Tool. Es lag im Zusammenspiel.

Ein internationaler digitaler Vertriebsprozess braucht konsistente Daten über viele Systeme hinweg. Ein Kunde konfiguriert ein Produkt, gelangt über einen Vertriebspartnerlink in den Shop, wird im Checkout einem passenden Partner zugeordnet, erstellt oder aktualisiert Kundendaten im CRM, löst eine Bestellung oder Anfrage aus, erhält eine korrekte Zuordnung im Hintergrund, speichert eventuell eine Konfiguration im Kundenkonto und erwartet, dass seine Daten später sauber verwaltet oder gelöscht werden können.

Diese Kette lässt sich nicht mit einem Standardtool erschlagen. Jedes System deckt einen Teil ab, aber niemand löst automatisch die Übergänge dazwischen.

Genau dort lag die Aufgabe von smartfactory: nicht ein weiteres Tool hinzufügen, sondern die Verbindungslogik zwischen bestehenden und neuen Systemen bauen. Die Plattform musste akzeptieren, dass USM mit unterschiedlichen Systemen arbeitet — und trotzdem eine stabile digitale Prozesskette daraus machen.

Darum war der modulare Ansatz entscheidend. Bestehende Systeme konnten weiter genutzt werden, während fehlende Verbindungsstücke als eigene Services ergänzt wurden. So entstand keine komplette Neuentwicklung aller Unternehmenssysteme, sondern eine gezielte Architektur rund um die Stellen, an denen Standardsoftware nicht sauber zusammenspielt.

Resultat – Was hat sich verändert?

Mit dem USM Microservice-Ökosystem entstand eine stabile technische Grundlage für langfristige digitale Weiterentwicklung.

Die Plattform ist heute modularer, wartbarer und besser erweiterbar. Einzelne Funktionen können unabhängig weiterentwickelt werden. Neue Anforderungen lassen sich gezielter platzieren. Schnittstellen sind klarer definiert. Die Kopplung zwischen Shop, Konfigurator, CRM, Kundenkonto, Partnerlogik und Umsystemen wurde reduziert.

Für USM bedeutet das:

• stabilere digitale Vertriebsprozesse
• bessere Wartbarkeit der Plattform
• klarere Systemgrenzen
• unabhängige Weiterentwicklung einzelner Services
• weniger Risiko bei Erweiterungen
• saubere Integration von Shop, Konfigurator, CRM, CMS, PIM und DAM
• bessere Grundlage für internationale Anforderungen
• strukturierte Partner- und Affiliate-Logik
• konsistente Zuordnung von Bestellungen und Vertriebspartnern
• kontrollierte Speicherung von Nutzerpräferenzen und Konfigurationen
• einheitlichere Account- und Adressprozesse
• automatisierte Löschung von Nutzerdaten über mehrere Services hinweg
• bessere Grundlage für Betrieb, Monitoring und Support
  

Der Nutzen liegt besonders in der Langfristigkeit. USM muss digitale Anforderungen nicht jedes Mal in ein überladenes Kernsystem drücken. Neue Services können dort entstehen, wo sie fachlich hingehören. Bestehende Services können stabilisiert oder erweitert werden, ohne die gesamte Plattform neu zu denken.

Damit wurde aus einer gewachsenen Systemlandschaft eine wartbare Architektur, die laufende Weiterentwicklung überhaupt erst sauber möglich macht.

Highlight des Projektes

Das Highlight des Projektes ist die Entflechtung einer gewachsenen digitalen Plattform in ein wartbares Microservice-Ökosystem.

smartfactory hat nicht einfach einen neuen Shop gebaut, sondern die technische Grundlage rund um Shop, Konfigurator, Kundenkonto, Partnerlogik, CRM-Anbindung und operative Datenflüsse neu strukturiert.

Aus vielen eng gekoppelten Einzelproblemen entstand eine modulare Architektur mit klaren Schnittstellen, eigenständigen Services und stabilen Betriebsprozessen. Genau das macht den Unterschied: USM kann digitale Anforderungen heute schrittweise weiterentwickeln, ohne bei jeder Änderung das ganze System zu gefährden.