Shopware ist nicht automatisch das führende System.

Ein Commerce-System benötigt Produkte, Preise, Bestände, Kundeninformationen, Inhalte und Bestellungen. Daraus entsteht schnell die Annahme, Shopware müsse diese Informationen auch vollständig besitzen und pflegen.

In einer integrierten Unternehmenslandschaft ist das selten sinnvoll. Produktstammdaten entstehen im PIM oder ERP, kundenspezifische Konditionen im ERP, Vertriebsbeziehungen im CRM und Rechnungen in Finance. Shopware benötigt diese Informationen für den Verkauf – ist aber nicht automatisch ihre führende Quelle.

Die zentrale Architekturfrage lautet deshalb:

„Master System" ist häufig zu grob

Die Aussage „Das PIM ist Master für Produkte" klingt eindeutig. Ein Produkt besteht jedoch aus vielen Attributen:

• Identität und Artikelnummer,
• technische Eigenschaften,
• Marketingbeschreibung,
• Übersetzungen,
• Kategorien,
• Medien,
• Preis,
• Bestand,
• Verkaufsstatus,
• Suchbegriffe,
• Cross-Selling.

Diese Informationen können unterschiedliche verantwortliche Systeme haben.

Beispiel:

Eine belastbare Architektur definiert Verantwortung deshalb auf einer geeigneten Granularität.

Führend bedeutet mehr als „liefert Daten"

Ein führendes System besitzt mehrere Rechte und Pflichten:

• Es ist die verbindliche Quelle für einen Wert.
• Änderungen müssen dort oder über einen kontrollierten Prozess erfolgen.
• Andere Systeme dürfen den Wert nicht unbemerkt überschreiben.
• Fehler und Konflikte werden dort oder in einer definierten Integrationsschicht geklärt.
• Herkunft und Aktualität bleiben nachvollziehbar.

Ein System kann Daten liefern, ohne fachlich führend zu sein. Beispielsweise kann eine Integrationsplattform den berechneten Commerce-Preis an Shopware übertragen. Die eigentliche Preisverantwortung bleibt trotzdem im ERP oder Pricing Service.

Schreibhoheit explizit machen

Besonders problematisch wird eine Integration, wenn mehrere Systeme dasselbe Feld bearbeiten dürfen.

Beispiel Marketingbeschreibung:

1. 1PIM liefert einen Text an Shopware.
2. 2Content-Team verbessert ihn direkt im Shop.
3. 3Der nächste PIM-Import überschreibt die Änderung.
4. 4Eine Rücksynchronisation schreibt den Shoptext zurück ins PIM.
5. 5Niemand weiß, welche Version verbindlich ist.

Mögliche Lösungen:

• Text ausschließlich im PIM pflegen,
• Text ausschließlich in Shopware pflegen,
• getrennte Felder für technischen Quelltext und Commerce-Text,
• expliziter Redaktions- und Freigabeprozess,
• einmalige Übernahme mit anschließendem Ownership-Wechsel.

Die Entscheidung muss im Datenmodell und in der Integration technisch durchgesetzt werden.

Ein Commerce-System darf lokale Daten besitzen

Dass Shopware nicht für alles führend ist, bedeutet nicht, dass dort keine eigenen Informationen entstehen dürfen.

Typische Shopware-eigene Daten:

• Contentseiten und Erlebniswelten,
• Shopnavigation,
• Suchkonfiguration,
• lokale Merchandising-Regeln,
• Warenkörbe,
• Checkout-Zustände,
• Kundenkonto-Einstellungen,
• Bestellinitiierung,
• kanalbezogene Sichtbarkeit.

Wichtig ist, diese lokalen Daten von replizierten Stammdaten zu unterscheiden.

Unterschiedliche Synchronisationsmuster

Push aus dem führenden System

Das Quellsystem veröffentlicht Änderungen aktiv. Geeignet für zeitnahe Updates und ereignisbasierte Architekturen.

Pull durch Integrationsplattform

Eine zentrale Komponente fragt Änderungen regelmäßig ab. Geeignet, wenn Quellen keine Ereignisse liefern oder Last kontrolliert werden muss.

On-Demand-Abfrage

Shopware ruft Informationen erst im konkreten Prozess ab, etwa einen individuellen Preis. Geeignet für aktuelle, stark kontextabhängige Werte – benötigt aber Verfügbarkeits- und Fallbackkonzept.

Replizierte lokale Kopie

Daten werden in Shopware gehalten, damit Suche und Darstellung schnell funktionieren. Die Kopie bleibt aber fachlich abgeleitet und darf nicht unkontrolliert geändert werden.

Keine Variante ist grundsätzlich richtig. Aktualität, Ausfallsicherheit, Volumen und Prozessanforderung bestimmen die Wahl.

Fehlerfälle definieren die Architektur

Im Idealzustand liefert jedes System aktuelle, vollständige Daten. Die eigentliche Qualität zeigt sich, wenn eine Quelle ausfällt oder widersprüchliche Werte sendet.

Zu klären ist:

• Darf der Shop mit dem letzten bekannten Preis weiterverkaufen?
• Wie alt darf ein Bestand sein?
• Wird ein Produkt bei fehlender Freigabe ausgeblendet?
• Darf eine Bestellung angenommen werden, wenn das ERP nicht erreichbar ist?
• Wie werden Änderungen nach einem Ausfall nachgeholt?
• Wer sieht und bearbeitet Konflikte?

Diese Regeln gehören nicht erst in den Betrieb. Sie bestimmen, welche Daten repliziert, gecacht oder synchron bestätigt werden müssen.

Verantwortung in der Oberfläche sichtbar machen

Wenn Mitarbeiter nicht erkennen, wo ein Wert gepflegt werden soll, entstehen trotz guter Architektur manuelle Umwege.

Hilfreiche UI-Prinzipien:

• replizierte Felder in Shopware read-only anzeigen,
• Herkunft und letzten Aktualisierungszeitpunkt sichtbar machen,
• Link zum führenden System anbieten,
• lokale Overrides ausdrücklich kennzeichnen,
• Konflikte und Fehler direkt am Datensatz darstellen,
• Änderungsvorgänge protokollieren.

Die Systemverantwortung muss nicht nur dokumentiert, sondern in der täglichen Bedienung verständlich sein.

Governance für neue Felder und Prozesse

Systemlandschaften verändern sich. Neue Anforderungen führen schnell dazu, dass ein Feld „vorübergehend" im Shop gepflegt wird, obwohl es eigentlich ins PIM gehört.

Eine leichte Governance verhindert neue Unklarheit:

1. 1Welche fachliche Entität betrifft die Anforderung?
2. 2Welches System ist dafür heute verantwortlich?
3. 3Benötigt der Wert mehrere Verbraucher?
4. 4Muss er historisiert oder freigegeben werden?
5. 5Ist ein lokales Shopfeld wirklich die richtige Lösung?
6. 6Wie wird die Information integriert und überwacht?

Das muss kein langwieriges Architekturboard sein. Wichtig ist, die Entscheidung bewusst zu treffen.