PIM architecture and integration: decide data ownership first

Why decide data ownership before choosing a PIM?

Decide data ownership first, because the attribute-ownership map determines what the PIM must do. In the PIMvendors view, the PIM selection starts with one question per attribute group: which system is the master. Integration scope, data model requirements and even the vendor shortlist follow from that answer.

The house thesis of PIM Selection applies directly to architecture. Most PIM selections fail before the first demo, because buyers compare software before they define their data model. In architecture terms, that means comparing PIM features before agreeing which data the PIM owns.

Three problems appear when ownership is left open:

• Two systems edit the same attribute, and nobody knows which value is correct.
• Integration is designed interface by interface, so every change needs a new project.
• Vendors are evaluated on functions the PIM will never use, such as price management already handled by ERP.

An attribute-ownership map prevents all three. It takes a few workshops with the enterprise architect, the product data manager and the ERP and PLM owners. The result is one table that every later decision refers to. The PIM business case pillar uses the same map to scope cost.

Which system masters which attribute group?

Each attribute group has exactly one master system. ERP masters commercial and logistic data, PLM masters engineering data, PIM masters marketing and channel content and classification, and DAM masters assets. The other systems receive, reference or display the data.

The last row needs the most discussion. Packaging composition may come from PLM or packaging specifications. Consumer-facing safety and sustainability information is often published from the PIM. Make the decision per group and record it in the map.

How does the PIM fit in the product data stack?

The PIM sits between the systems that create product data and the channels that consume it. ERP and PLM feed it with commercial, logistic and engineering data. DAM supplies assets by reference. The PIM adds marketing content and classification, then publishes to commerce platforms, marketplaces, retailers and data pools.

Sources

• ERP: price, stock, logistics
• PLM: engineering data
• Suppliers: files and portals
• DAM: images and documents

PIM

System of record for marketing, channel and classification data, under governance

• Data model
• Enrichment
• Quality rules
• Workflow

Channels

• Own webshop
• Marketplaces
• Retailers and data pools
• Print and catalogues
• AI shopping assistants

Two boundaries cause most debate. The first is PIM and DAM: the PIM links to assets, and the DAM manages versions, rights and renditions. The second is PIM and commerce: the commerce platform owns prices, carts and customer data, and the PIM owns the content it displays.

The product data stack guide describes each layer, the typical stack shapes in European manufacturing and distribution, and how to document your own stack before selection.

How should the PIM integrate with ERP?

PIM and ERP integration should follow the ownership map: ERP sends identification, commercial and logistic data to the PIM, and the PIM sends enriched content where ERP or downstream systems need it. Most flows run from ERP to PIM. Few run back.

Four integration patterns are common:

ERP timing matters for the plan. SAP Business Suite 7 mainstream maintenance ends on 31 December 2027, with extended maintenance for EHP6 to EHP8 until 31 December 2030. Organisations on SAP ECC should design PIM integration so it survives an ERP migration. The PIM and ERP integration guide covers each pattern and data flow.

How do PLM and engineering data reach the PIM?

Engineering data reaches the PIM from PLM after release. PLM masters specifications, bills of material and revision status. The PIM receives the released values it needs for channels and adds marketing content around them.

Three design rules keep the PLM flow clean:

• Transfer only released revisions, so channels never show draft specifications.
• Map PLM attributes to the PIM data model once, including units and classification codes.
• Keep engineering attributes read-only in the PIM, with change requests routed back to PLM.

Many mid-market manufacturers have no PLM. Engineering data then lives in ERP, CAD files or spreadsheets kept by the engineering team. The ownership map still needs a master for these attributes. In that case, the PIM can become the master for technical specifications, provided engineering owns the approval step.

Compliance data often starts in the same place. Material composition and packaging specifications sit with engineering or packaging teams. The ESPR has been in force since 18 July 2024 and introduces the Digital Product Passport. That passport draws on engineering, sourcing and content attributes, so its master decisions must be explicit.

Should the PIM be SaaS, private cloud or on-premise?

The hosting choice trades control against upgrade effort and run cost. SaaS gives continuous upgrades and predictable subscription cost with less control over release timing. Private cloud and on-premise give more control and customisation, with upgrades and hosting as your own cost.

Five criteria decide the choice: control, upgrades, cost profile, data residency and customisation. Product data is mostly non-personal, which eases residency questions. User accounts, supplier contacts and some workflow data are personal data and still need an EU hosting answer.

Exit terms have changed. Under the EU Data Act, switching provisions apply from 12 September 2025. Cloud switching charges are prohibited from 12 January 2027. The SaaS vs on-premise guide compares the three hosting models in a table.

What does composable commerce mean for PIM selection?

Composable commerce means assembling the commerce stack from separate, API-connected services. For PIM selection, that raises the bar on APIs, events and data model access. The MACH Alliance, founded in June 2020, promotes microservices-based, API-first, cloud-native SaaS and headless architecture.

In a composable stack, the PIM becomes a content service that other services call. That requires complete API coverage, webhooks or events on change, documented rate limits and a data model that front-ends can query. A PIM built mainly around file exports fits less well.

Test composability in the demos with your own front-end team. Ask the vendor to expose one product family through the API, with variants, translations and asset links. Measure how many calls a product detail page needs. That single scenario shows more than any architecture slide.

Composability also has a cost. More services mean more contracts, more integrations and more internal architecture capacity. The composable commerce guide explains which requirements to add to the RFP and when a suite fits better.

How does product data reach marketplaces, retailers and data pools?

Product data reaches external channels through syndication: PIM-native exports, feed tools, retailer portals and GS1 GDSN data pools. The right mix depends on the number of channels and on what each recipient requires. Retailers in food, health and DIY often require GDSN, while marketplaces use their own formats and APIs.

GDSN is a network of interoperable data pools governed by GS1 standards. According to Wikipedia, 44 data pools are GDSN-certified. A brand publishes once to its own data pool, and the network distributes to subscribed retailers.

PIM-native syndication suffices when channels are few and formats stable. A feed tool or syndication platform becomes worth its cost when channels multiply and rules change often. The product data syndication guide covers each route and when to add one.

How do supplier data and standards enter the PIM?

Supplier data enters the PIM through portals, templates and standard formats such as BMEcat and ETIM-classified files. For distributors, supplier onboarding is often the largest data flow in the architecture. The quality of that flow sets the quality of the catalogue.

Classification standards keep moving. ETIM 10.0 was published in December 2024, with 119 new classes created and 33 deleted. Every release needs mapping updates in the PIM and in supplier templates. Plan that effort as a recurring task.

Validation belongs at the gate. Mandatory attributes, units, value lists and classification are checked before supplier data reaches the master record. The supplier data onboarding guide explains portals, templates, validation and BMEcat and ETIM imports in detail.

How do you document the target architecture before selection?

Document the target architecture in four artefacts that every vendor and partner receives. Clear artefacts produce comparable answers. Vague ones produce generic demos that predict nothing.

Keep each artefact to one page or one table. A data flow inventory with 10 to 20 rows is typical for a mid-market manufacturer, as a PIMvendors estimate. Larger organisations with several ERP instances can reach well beyond that.

Share the artefacts with vendors before the scenario demos. Ask each vendor to mark which flows its product covers with standard connectors and which need custom work. That answer feeds the integration line of the TCO.

Which architecture decisions belong in the PIM requirements?

Architecture decisions become integration and platform requirements before vendors are invited. PIMvendors cross-checks requirements against a 4-domain checklist of more than 400 requirements. Two of those domains carry the architecture: Integration and syndication (IN) and Platform and vendor (PL).

Translate each architecture decision into a testable requirement:

1. The attribute-ownership map becomes data model and import requirements.
2. Each data flow becomes an integration requirement with pattern, frequency and volume.
3. Hosting and residency decisions become platform requirements.
4. Channel and data pool targets become syndication requirements.
5. Supplier onboarding becomes portal, template and validation requirements.

{{list:requirements:IN}}

Test the critical flows in scenario demos on your own sample data. An ERP import, a channel export and a supplier file are three scenarios that reveal integration fit quickly. The requirements checklist holds the full set across all four domains.