Skylotec

Die Plattformentscheidung war bereits gefallen, als wir dazukamen. Skylotec suchte keinen Berater für die Auswahl, sondern einen verlässlichen Umsetzungspartner. Entschieden haben am Ende zwei Dinge. Zum einen erste Entwürfe für die Startseite – anspruchsvoll gestaltet, mit Animationen und mehrfarbig bewegter Typografie, technisch alles andere als trivial. Zum anderen, und das war für Skylotec der wichtigere Teil, mehrere Termine, in denen wir erklärt haben, wie wir arbeiten.

Skylotec schaut sehr genau auf Entwicklungspraxis und Software-Delivery. Wie ist der Lifecycle organisiert, wie kommt Code nach Produktion, wie sieht Qualitätssicherung aus. Unsere Prozesse haben ihre Erwartungen erfüllt, in Teilen übertroffen. Dass eine Agentur an diesen Fragen gemessen wird und nicht nur am Pitch-Deck, kommt seltener vor, als man denkt.

Neben Magento, der bisherigen Plattform, hat Skylotec mehrere Enterprise-Systeme verglichen. Entscheidend waren drei Kriterien: Mandantenfähigkeit, ein API-first-Ansatz für die tiefe Anbindung des ERP von Microsoft Dynamics und flexible Content-Commerce-Funktionen. Im B2B-Geschäft von Skylotec müssen kundenindividuelle Preise und Konditionen aus dem ERP kommen, das war nicht verhandelbar.

Die Wahl fiel auf Shopware 6 Evolve, weil diese Edition zentrale Anforderungen schon im Standard abdeckt. Dazu gehören native B2B-Funktionen wie Angebotsanfragen (Request for Quote), Schnellbestellung und Logins für den Außendienst.

Ein großer Vorteil ist das Verkaufskanal-Konzept von Shopware. Skylotec betreibt darüber die Hauptwebsite und den zentralen B2B-Shop, dazu eine eigenständige Website und einen weiteren B2B-Shop für den Outdoor-Bereich, alles auf derselben Instanz. Über den Rule Builder und das integrierte CMS steuert das Team produktspezifische Zugriffsrechte, zielgruppengerechte Inhalte und B2B-Regeln für beide Geschäftsbereiche an einer Stelle.

Der erste Commit ist am 22. Juli 2024 um 15:26 Uhr gefallen. Soft Launch war im Februar 2025, der vollständige Go-live im März 2025. Das Team bestand aus zwei Backend-Entwicklern, einem Frontend-Entwickler, Projektleitung, QA und DevOps.

Ein Relaunch mit drei Vertriebskanälen lässt sich nicht an einem Stichtag umlegen. Deshalb der gestaffelte Ansatz: erst weich starten, beobachten, nachziehen, dann vollständig übergeben.

Drei größere. Das ERP von Microsoft Dynamics haben wir über REST-Schnittstellen angebunden. Das PIM, ein iPIM-System, läuft über eine Datenintegrationsplattform. Dazu kommt ein Media Service für Dokumente, Garantien und Bedienungsanleitungen, der über einbettbares JavaScript in den Shop kommt.

Die eigentliche Arbeit lag nicht in einer einzelnen Integration, sondern im Datenmodell. Alle drei Systeme liefern nach Shopware hinein, und ihre Strukturen passen nicht automatisch auf die von Shopware. Ein Beispiel: Skylotecs PIM bildet Produkte anders ab, als Shopware Produkte und Varianten versteht. Wir lösen das so, dass auch ein einzelnes Produkt technisch eine einzelne Variante bekommt – pragmatisch, aber es hält das Modell konsistent. Solche Anpassungen mussten auf Importebene passieren, für jedes System einzeln.

Was das Projekt getragen hat, war die enge Abstimmung mit den technischen Ansprechpartnern der drei Anbieter. Und dass jede Änderung erst über ein Stage-System und dann nach Produktion ging.

Die kundenindividuellen Preislisten. Skylotec kalkuliert Preise über hunderte von Kundengruppen mit sehr feiner Abstufung. Der Mechanismus, den Shopware dafür mitbringt, funktioniert für eine überschaubare Zahl von Kunden gut – bei tausenden gerät die Regelberechnung an ihre Grenzen.

Gelöst haben wir es über eine zusätzliche Caching-Schicht für berechnete Preise. Die wird neu aufgebaut, sobald Preisaktualisierungen synchronisiert werden, statt bei jedem Seitenaufruf zu rechnen. Interessantes Nachspiel: Mit Shopware 6.7 kam eine vergleichbare Funktion in den Standard, und das Problem hat sich erledigt. Das ist typisch für eine Plattform, die sich schnell entwickelt – man baut etwas, weil es fehlt, und ein Release später ist es da.

Es sind zwei B2B-Kanäle – einer für den professionellen Bereich, einer für Outdoor und Klettern – plus ein B2C-Kanal. Jeder mit eigener Zielgruppe, eigener Preislogik, eigenem Verhalten.

Der Schlüssel waren Feature Toggles. Der überwiegende Teil der Funktionen liegt bereits im Produktionscode, aber abgeschaltet. Das Geschäft entscheidet dann, wann eine Funktion aktiv wird und für wen – nur B2B, nur B2C, zeitgesteuert. Damit ist der Relaunch kein Ereignis mehr, sondern eine Folge kleiner Schalter. Jeder Kanal konnte einzeln und mit praktisch null Ausfallzeit weich starten, und wenn etwas nicht wie erwartet lief, war der Rückweg ein Toggle statt eines Deployments.

Skylotec verkauft international – Europa, USA, Australien und darüber hinaus. Der Shop läuft in fünf Sprachen: Englisch, Deutsch, Spanisch, Französisch und Italienisch. In Kombination mit den drei Vertriebskanälen ergibt das eine Matrix, in der fast jede Funktion die Frage mitbringt, für welchen Kanal in welcher Region sie in welcher Sprache gilt.
Das ist weniger ein technisches als ein Sorgfaltsproblem.

Das war eine der interessanteren Aufgaben im Projekt. Wir deployen auf einen Kubernetes-Stack, den Skylotec betreibt. Beide Seiten hatten eingespielte Routinen, und die waren nicht deckungsgleich. So etwas löst man nicht, indem eine Seite sich durchsetzt.

Das Ergebnis ist ein geteiltes Verantwortungsmodell: Skylotecs Kubernetes stellt die Infrastruktur für die Shop-Anwendung, während Konfiguration und Auslieferung der Anwendung nach unserem Ansatz laufen. Skylotecs DevOps-Team behält damit vollen Überblick über Bausteine und Komponenten, und wir bleiben dafür verantwortlich, wie unsere Anwendung ausgeliefert und installiert wird. Beide Seiten sehen, was passiert, und niemand muss die Arbeitsweise der anderen übernehmen.

Für die Überwachung der Applikation setzen wir auf laufendes Monitoring mit Alarmierung und auf Application Performance Monitoring, um Performance-Probleme auf Codeebene zu finden, bevor sie im Betrieb auffallen.

Wir haben die Migration der Kubernetes-Umgebung von einem Hyperscaler zu einem europäischen Hosting-Anbieter begleitet. Unsere Standardplattform ist AWS, aber wir bauen unsere Lösungen so, dass sie ohne Vendor Lock-in funktionieren – das ist keine Marketingaussage, sondern wird genau in solchen Momenten geprüft.

Die Migration lief unauffällig, was vor allem daran lag, dass vor der Anwendung ein CDN sitzt, dessen Konfiguration flexibel genug war, um den Wechsel abzufedern. Eine Infrastrukturmigration im laufenden Betrieb ist der ehrlichste Test dafür, ob eine Architektur wirklich portabel ist. Diese hat ihn bestanden.

Shopware ist leistungsfähig und entwickelt sich schnell. Trotzdem stößt man auf fehlende Funktionen oder auf Stellen, an denen die Performance besser sein könnte.

Konkret drei Punkte. Die Preislisten habe ich erwähnt – bis 6.7 war das ein echtes Problem. Produktbundles fehlten uns. Und das Produkt-Varianten-Datenmodell passt nicht zu jedem PIM, was Umwege erzwingt.

Der Punkt, der bis heute unbequem bleibt, ist Plugin-Installation und Templating. Wir liefern deterministisch aus, über Container und mit schreibgeschützten Dateisystemen – das ist aus Betriebssicht richtig, macht aber vieles unbequemer. Wer aus der Shopware-Welt gewohnt ist, ein Plugin im Backend anzuklicken und auszuprobieren, muss bei uns warten, bis es durch die Pipeline gelaufen ist. Das dauert von der Entwicklung bis in die Produktion rund 20 Minuten. Für ein Deployment ist das schnell. Für jemanden, der eine Idee ausprobieren will, fühlt es sich lang an. Dieser Zielkonflikt zwischen verlässlicher Auslieferung und schnellem Ausprobieren ist nicht gelöst, und ich bin nicht sicher, ob er sich vollständig lösen lässt.