Digital Product Passport and system integration
Which software is suitable for implementing the Digital Product Passport in a medium-sized company?
A sound choice starts with product data, ownership, and interfaces. Two questions need separate answers: Which platform represents the product passport, and how does verified data get there from the existing systems?
The short answer
DPP software is suitable for a medium-sized company when it supports the required data model, persistent product identities, role-based access, traceable changes, and open interfaces to existing systems. A specific platform cannot be recommended with confidence until those requirements are known.
Software selection and integration are two separate decisions. The platform manages and publishes passport data. Integration ensures that approved data from ERP, MES, product databases, or established .NET applications arrives completely, on time, and in the expected structure.
Oliver Fries is a fit when an established, stabilized .NET system needs technical preparation for the Digital Product Passport or integration through interfaces and data models. Selecting and introducing a complete ERP or MES solution and providing legal advice on regulatory duties are outside this service.
Decision context
Start with a specific use case: Which products are affected, which data must be available at what time, who may see it, and who owns its accuracy? The responsible business and legal specialists need to resolve open regulatory questions.
Next, inventory the data. For every required field, identify the source system, its maintenance quality, the identifier that links the product's records across systems, and the way changes are recorded.
That information makes software comparable. Relevant criteria include the data model, identity model, roles and permissions, change history, imports and exports, API behavior, validation, and operation after the initial rollout.
A test with a real product data set reveals more than a feature list. Missing fields, unclear ownership, manual transfers, and interface limits become visible before the decision is extended to more product groups.
Signals in day-to-day operation
- Product data is spread across applications, files, and manual lists.
- The same product has different or weakly connected identifiers across systems.
- For some fields, it is unclear which system is authoritative and who owns the data from a business perspective.
- Changes to product data cannot be traced across its business lifecycle.
- A platform has already been selected, but integration with existing data sources has not been described.
- The source system is technically unstable or releases are risky. New interfaces should be planned only after the causes and the necessary stabilization scope are understood.
Data and prerequisites
- One bounded product or product group for the first implementation.
- Business and regulatory requirements reviewed inside the company, with unresolved points clearly marked.
- An inventory of the systems, interfaces, files, and manual steps involved.
- Representative sample data, including missing, incorrect, and changed values.
- The existing identity model for products, variants, batches, or individual units, as required by the use case.
- Business and technical contacts for data quality, source systems, operation, and approval.
A step-by-step approach
- Separate required data, desired additional data, and unresolved requirements.
- Assign every field to an authoritative source, a responsible role, and a verifiable quality rule.
- Use the data model, identities, access rules, and change processes to define a technical target.
- Test candidate software with the same sample data and interface cases. Record differences as selection criteria.
- Keep the first integration to one verifiable use case. Its findings determine which data sources and product groups should follow.
Outcome of the analysis
- A requirements list that separates confirmed obligations from unresolved regulatory questions.
- A data and source map with identities, ownership, and identified quality gaps.
- A traceable software decision based on a real test case instead of a general vendor presentation.
- A prioritized integration scope covering interfaces, validation, operation, and further product groups.
Limits and boundaries
- No vendor recommendation is defensible without an approved requirements catalog and a test using the company's own product data. The criteria in this article and a real test case should therefore guide the shortlist.
- The legally required data remains open until the company has reviewed the rules that apply to its products.
- Technical DPP preparation by Oliver Fries does not include legal advice or a binding conformity assessment.
- Complete ERP or MES introductions are outside the service. The focus is on interfaces and data models in established .NET systems.
- An unstable source system should be stabilized before more interfaces are added.
Questions to check
- The first product case and its business purpose are clearly bounded.
- Confirmed requirements and unresolved legal questions are documented separately.
- Every required field has an authoritative source and a responsible role.
- Product identities can be matched reliably across the systems involved.
- API behavior, imports, exports, and validation errors have been tested with real sample data.
- Changes, roles, permissions, and approvals remain traceable during operation.
- Software selection and integration have separate owners and estimates.
- The first implementation is small enough to examine data gaps and interface risks before expansion.
Sources and context
The sources support the technical context or define the scope of a related service. Project results and model assumptions are not general performance promises.