DPP-Systemarchitektur: vom Quellsystem bis zum Produktpass

Diese Seite vertieft einen Baustein des Digitalen Produktpasses. Das DPP-Datenmodell definiert Felder und Nachweise; die DPP-Umsetzungsroadmap ordnet die Architektur in Pilot und Rollout ein.

Viele DPP-Projekte beginnen an der falschen Stelle: mit einer Plattformdemo, einem QR-Code oder einer Liste möglicher Pflichtfelder. Das eigentliche Betriebsproblem liegt dazwischen. Produktdaten ändern sich in PIM, ERP, PLM, LCA-Systemen, Dokumenten und Lieferantenportalen. Ein Produktpass muss diese Änderungen kontrolliert übernehmen, prüfen, freigeben, versionieren und für unterschiedliche Rollen ausliefern, ohne eine zweite unkontrollierte Datenwelt aufzubauen.

Der DPP-Überblick ordnet Rechtsrahmen, Produktgruppen und Umsetzung ein. Das DPP-Datenmodell definiert Produktidentität, Felder, Nachweise und Zugriffsregeln. Dieser Leitfaden verbindet beides mit einer Systemarchitektur, die auch dann verständlich bleibt, wenn einzelne Anwendungen oder Anbieter später wechseln.

Was rechtlich vorgegeben ist – und was Architekturentscheidung bleibt

Die ESPR-Verordnung, insbesondere Artikel 9 bis 13, gibt zentrale Eigenschaften des DPP-Systems vor. Daten sollen auf offenen Standards beruhen, interoperabel, maschinenlesbar, strukturiert, durchsuchbar und übertragbar sein. Ein Datenträger verbindet den Pass mit einer persistenten eindeutigen Produktkennung; Zugriffe richten sich nach den im jeweiligen Produktrecht festgelegten Rollen. Welche konkreten Daten, welche Granularität und welcher Datenträger verpflichtend sind, bleibt produktspezifisch.

Die Verordnung schreibt dagegen nicht vor, ob ein Unternehmen Kafka, eine bestimmte Cloud, ein vorhandenes PIM oder eine DPP-SaaS-Plattform verwendet. Systemgrenzen, Synchronisationsmuster, Datenhaltung, Freigabeprozess und Fehlerbehandlung sind Architekturentscheidungen. Sie müssen die gesetzlichen Eigenschaften unterstützen, dürfen aber nicht als EU-Vorgabe ausgegeben werden.

Seit dem 20. Juli 2026 ist das EU-DPP-Register mit Testumgebung in Betrieb. Die Kommission beschreibt weiterhin eine dezentrale Speicherung der eigentlichen Produktpassdaten; im Register werden Kennungen und zugehörige Metadaten registriert. Von acht technischen DPP-Standards sind zum Prüfdatum sechs veröffentlicht. Die Kommissionsseite zu den harmonisierten DPP-Standards bleibt deshalb ein Pflichtpunkt für Architektur-Reviews.

Die Referenzarchitektur in acht Stationen

Der folgende Datenfluss ist eine technische Referenz, kein vorgeschriebenes EU-Produkt. Jede Station hat eine eigene Verantwortung und einen klaren Fehlerausgang. Kleine Piloten können mehrere Stationen in einem Dienst bündeln. Die logischen Grenzen sollten trotzdem sichtbar bleiben, damit spätere Skalierung nicht mit einer vollständigen Neuentwicklung beginnt.

1. Quellsysteme bleiben fachlich führend

Eine DPP-Plattform sollte nicht ungeplant zum Master für alle Produktdaten werden. Das PIM kann verkaufsfähige Attribute und Übersetzungen führen, das ERP Artikel, Chargen und Lieferantenbeziehungen, das PLM Konstruktion und Stücklisten. LCA- und Compliance-Systeme liefern Berechnungen oder Nachweise; Dokumentenmanagement und Lieferantenportale halten Originaldokumente. Die tatsächliche Verteilung ist je Unternehmen anders.

Entscheidend ist eine Source-of-Record-Matrix pro Feld. Sie nennt führendes System, fachlichen Owner, technischen Zugriff, Aktualisierungsereignis und Konfliktregel. „Kommt aus dem PIM“ reicht nicht, wenn dieselbe Materialangabe im PLM abweicht oder ein Lieferantennachweis abgelaufen ist.

• Produktidentität: Schema, Kennung, Modell-, Chargen- oder Artikelebene und verantwortlicher Wirtschaftsakteur;

• Fachwert: führendes System, Einheit, zulässiger Wertebereich und Übersetzungslogik;

• Nachweis: Dokument oder Datensatz, Aussteller, Version, Gültigkeit und Zugriffsklasse;

• Änderung: fachliches Ereignis, erwartete Lieferzeit, Wiederholung und Eskalationsweg.

Die nächste Vertiefung der Roadmap wird diese Quellenarbeit für PIM, ERP, PLM, LCA, Dokumente und Lieferanten separat behandeln. Bis dahin liefert das DPP-Datenmodell mit seinem Feldvertrag die notwendige Grundlage.

2. Eine Integrationsschicht übersetzt, statt Daten blind zu kopieren

Die Integrationsschicht verbindet Quellmodelle mit dem DPP-Feldvertrag. Sie normalisiert Identifikatoren, Einheiten, Sprachwerte und Nachweisreferenzen. Mapping-Regeln gehören versioniert in Code oder eine kontrollierte Konfiguration, nicht ausschließlich in eine undokumentierte Oberfläche des Plattformanbieters.

Ein unveränderter Quellwert kann nach einer Regeländerung zu einem anderen DPP-Ergebnis führen. Deshalb muss jede veröffentlichte Version festhalten, mit welcher Mapping- und Schema-Version sie erzeugt wurde. Nur so lässt sich eine ältere Ausgabe später erklären oder reproduzieren.

Für einen ersten Prototyp zeigt das versionierte DPP-JSON-Beispiel, wie Identität, Fakten, Evidenz, Governance und Zugriff getrennt werden. Die Datei ist eine Illustration und keine universelle Feldliste.

3. Quality Gates stoppen falsche Daten vor der Veröffentlichung

Nicht jeder Fehler braucht KI und nicht jeder Fehler darf automatisch korrigiert werden. Format, Datentyp, Einheit, Pflichtstatus, Eindeutigkeit und bekannte Wertebereiche lassen sich deterministisch prüfen. Ein fehlendes Komma in einer Dezimalzahl kann unter klaren Bedingungen normalisiert werden; ein widersprüchlicher Rezyklatanteil aus zwei Quellen braucht fachliche Klärung.

Ein brauchbares Quality Gate liefert mindestens drei Ergebnisse:

• akzeptiert: Wert und Nachweis erfüllen die aktuell geltenden Regeln;

• blockiert: Veröffentlichung oder Registrierung wird verhindert und ein Owner erhält eine konkrete Aufgabe;

• Warnung: Der Wert darf weiterlaufen, bleibt aber sichtbar mit Risiko, Frist und Verantwortlichkeit verknüpft.

KI kann unstrukturierte Dokumente vorsortieren oder Feldkandidaten vorschlagen. Die veröffentlichte Tatsache sollte jedoch an Quelle, deterministische Regeln und – wo nötig – eine menschliche Freigabe gebunden bleiben. Sonst skaliert die Architektur plausible Fehler schneller als die heutige Handarbeit.

4. Freigabe ist ein eigener Systemzustand

Ein erfolgreicher Import bedeutet nicht automatisch, dass ein Wert veröffentlicht werden darf. Änderungen an regulierten oder nachweisgebundenen Feldern brauchen einen Freigabestatus. Die Architektur hält Antragsteller, fachlichen Prüfer, Entscheidung, Kommentar, Zeitpunkt und betroffene Felder fest. Für kleine Teams kann dieselbe Person mehrere Rollen tragen; die Rollen sollten im Datenmodell dennoch getrennt bleiben.

Ein Audit Trail ist mehr als ein technisches Log. Ein Serverlog zeigt, dass ein API-Aufruf stattfand. Die fachliche Historie erklärt, warum ein Wert geändert wurde, welcher Nachweis galt und wer die Veröffentlichung genehmigte. Beides wird benötigt, aber nicht im selben Datenobjekt.

5. Versionen bilden Änderungen und Korrekturen ab

Der gedruckte Datenträger bleibt oft unverändert, während sich Produktdaten, Nachweise oder Zugriffsregeln ändern. Die persistente Produktkennung sollte deshalb nicht direkt an eine kurzlebige CMS-URL oder eine einzelne Dateiversion gekoppelt werden. Ein Resolver führt von der stabilen Kennung zur aktuellen erlaubten Darstellung; ältere Versionen bleiben nach der festgelegten Aufbewahrungslogik nachvollziehbar.

Die Architektur muss zwischen fachlicher Änderung, Korrektur, Ersatz, Widerruf und Archivierung unterscheiden. Eine Korrektur überschreibt nicht still die Geschichte. Sie verweist auf den vorherigen Stand, dokumentiert den Grund und löst nur die erforderlichen Folgeprozesse aus.

6. Hosting, Resolver und Register sind drei verschiedene Aufgaben

Das DPP-Hosting liefert HTML, maschinenlesbare Daten und geschützte Dokumente aus. Der Resolver ordnet eine persistente Kennung der passenden Ressource oder Sicht zu. Das EU-Register ist der zentrale Index für Kennungen und vorgeschriebene Metadaten; es ist nicht automatisch das Hosting für den vollständigen Produktpass. Die Kommission beschreibt diese Registerfunktion ausdrücklich.

Diese Trennung schützt vor einem typischen Architekturfehler: QR-Code, URL, Produktkennung, DPP-Datensatz und Registereintrag als dasselbe Objekt zu behandeln. Die Seite zu QR-Code, GS1 Digital Link und Resolver erklärt die Zugriffsschicht. Der Leitfaden zum DPP-Register und zur Registrierung vertieft Verifizierung, Metadaten und Registrierungsablauf.

Für den Betrieb braucht jede Schicht einen Exit-Pfad: exportierbare DPP-Daten, kontrollierte Kennungen und Domains, dokumentierte Resolverregeln, Backups, Wiederanlauf und eine getestete Migration zu einem anderen Anbieter. Die DPP-Software- und Anbieterauswahl sollte diese Anforderungen vor Vertragsabschluss prüfen.

7. Zugriff wird vor der Oberfläche modelliert

Ein einzelner öffentlicher JSON-Endpunkt ist kein Rollenmodell. Verbraucher, Händler, Reparaturbetriebe, Recyclingunternehmen, Marktüberwachung und Zoll können unterschiedliche Daten sehen. Öffentliche Produktinformationen lassen sich per URL ausliefern; geschützte Nachweise benötigen Authentisierung, Autorisierung und protokollierten Zugriff. Welche Rolle welches Feld sehen darf, ergibt sich aus dem einschlägigen Produktrecht und dem eigenen Schutzbedarf.

Zugriffsregeln werden am Feld oder an einer stabilen Datengruppe dokumentiert und automatisiert getestet. Die Frontend-Komponente setzt diese Regeln nur um. Geschäftsgeheimnisse dürfen nicht versehentlich öffentlich werden, weil eine API lediglich zwischen „eingeloggt“ und „nicht eingeloggt“ unterscheidet.

8. Synchron und asynchron sinnvoll kombinieren

Ein Seitenaufruf sollte nicht live fünf Quellsysteme abfragen. Diese Kopplung macht die DPP-Verfügbarkeit vom langsamsten ERP, Lieferantenportal oder Dokumentenspeicher abhängig. Für veröffentlichte Produktpassdaten ist ein versionierter Read Store meist sinnvoll: Freigegebene Daten werden vorbereitet, validiert und anschließend schnell ausgeliefert.

Änderungen, Massenimporte, Nachweisprüfungen und Registrierungen laufen besser als idempotente Hintergrundprozesse mit Wiederholungen und einer Fehlerwarteschlange. Synchron bleiben Vorgänge, bei denen ein Nutzer sofort eine verbindliche Antwort braucht, etwa das Lesen einer veröffentlichten Sicht oder eine einfache Berechtigungsprüfung.

Fehlerpfade gehören zur Referenzarchitektur

Ein Flussdiagramm ist erst belastbar, wenn jede Kante auch scheitern darf. Die Architektur sollte mindestens folgende Fälle vor dem Pilot abbilden:

• Quellsystem nicht erreichbar: letzten freigegebenen Stand weiter ausliefern, Änderung verzögert markieren und eskalieren;

• Kennung unbekannt oder doppelt: Verarbeitung blockieren, keine neue Identität still erzeugen;

• Nachweis abgelaufen: betroffene Aussage und Rolle ermitteln, Veröffentlichung je Regel warnen oder sperren;

• Mapping oder Schema geändert: betroffene Pässe gezielt neu validieren statt alle Daten blind neu zu veröffentlichen;

• Register nicht erreichbar: Registrierung idempotent wiederholen und Produktstatus nicht fälschlich als bestätigt anzeigen;

• Resolver oder Hosting gestört: Gesundheitsprüfung, Alarm, Wiederanlauf und getesteten Fallback auslösen;

• Berechtigung unklar: Zugriff verweigern und Entscheidung protokollieren, statt sensible Daten vorsorglich freizugeben.

Diese Fälle gehören in Abnahmetests. Ein Pilot, der nur den erfolgreichen Happy Path zeigt, prüft die Oberfläche, nicht die Betriebsfähigkeit.

Drei sinnvolle Bereitstellungsmodelle

Bestehende Systeme plus Integrationsschicht

PIM, ERP, PLM und Dokumentensysteme bleiben führend. Eine eigene Integrationsschicht bildet den DPP-Feldvertrag ab, erzeugt Versionen und beliefert Hosting, Resolver und Register. Dieses Modell bietet viel Kontrolle, verlangt aber eigene Betriebsverantwortung.

DPP-Plattform als Auslieferungs- und Betriebsdienst

Eine spezialisierte Plattform übernimmt Datenhaltung, Zugriff, Resolver, Registeranbindung oder Teile davon. Das kann die Einführung beschleunigen. Der Feldvertrag, die Identifikatoren, Exportwege und fachlichen Freigaben sollten trotzdem außerhalb proprietärer Funktionen dokumentiert bleiben.

Hybride Architektur

Viele Unternehmen werden ein hybrides Modell nutzen: eigene Masterdaten und Governance, eine kontrollierte Integrationsschicht und ausgewählte Plattformdienste für Auslieferung oder Registrierung. Die richtige Grenze hängt von vorhandenen Kompetenzen, Produktvolumen, Zugriffsanforderungen, Änderungsrate und Exit-Risiko ab.

Die DPP-Umsetzungsroadmap ordnet diese Entscheidung in Scope, Pilot und Rollout ein. Wenn Datenmodell, Systemgrenzen und Plattformwahl gemeinsam geklärt werden müssen, beschreibt DPP-Beratung und technische Umsetzung den passenden Projektrahmen.

Architektur-Check für den ersten Pilot

1. Pilotprodukt, anwendbaren Rechtsrahmen und Modell-/Chargen-/Artikelebene festlegen.

2. Pro Feld führendes System, Owner, Nachweis, Qualität und Zugriff dokumentieren.

3. Persistente Kennung von URL, Datenträger, DPP-Version und Registereintrag trennen.

4. Mapping, Schema und Freigabe als versionierte Verträge behandeln.

5. Veröffentlichten Read Store und asynchrone Änderungsverarbeitung festlegen.

6. Registeraufrufe idempotent machen und Statusrückmeldungen speichern.

7. Mindestens einen abgelaufenen Nachweis, eine Korrektur und einen Systemausfall testen.

8. Export, Domainkontrolle, Backup, Monitoring und Anbieterwechsel abnehmen.

Das Ergebnis des Piloten sollte kein statisches Architekturdiagramm sein. Es sollte ein reales Produkt mit nachvollziehbarer Identität, einem versionierten Feldvertrag, echten Lücken, einer geprüften Veröffentlichung und dokumentierten Fehlerwegen durch die gesamte Kette führen.