Governing the Data Model: A Best-Practice Operating Model for inRiver PIM Programs
inRiver PIM programs rarely fail because of the platform — they fail because of ambiguous ownership. Here's a three-way operating model, a full RACI matrix, and a Data Governance Office charter to fix it.
Executive Summary
inRiver PIM programs rarely fail because of the platform — they fail because of ambiguous ownership. When IT makes business calls (what an attribute means, what "complete" means), the model reflects system convenience, not the business. When business makes technical calls (ad hoc configuration requests), the system accumulates unmanaged complexity.
The core argument: IT builds and operates the system. Business defines what the data means and how it's used. Neither owns the data model outright — a governance function positioned between them does.
The PIM Challenge: Why Programs Stall After Go-Live
Most inRiver programs look clean at go-live. The erosion that follows over the next few quarters is predictable:
Individually minor, collectively these show a data model drifting from a standard no one actively owns.
Root Cause: Blurred Ownership Between IT and Business
Without a deliberate operating model, programs default to one of two failure patterns.
Pattern A: IT becomes the default decision-maker on taxonomy and attributes simply because it's the only group with full visibility — producing a model that's technically coherent but disconnected from the business.
Pattern B: business requests changes directly with no technical or governance review — individually reasonable requests accumulate into a system no one can fully explain.
Both share the same root cause: no function was ever assigned to hold technical feasibility and business meaning at once.
Recommended Operating Model
The remedy is a three-way separation of responsibility, not a two-way split between "IT" and "the business."
Technical (IT) Team — Builds and Operates the Platform
IT owns how the system works, not what the data means, across six areas: System Administration (licenses, roles, permissions, security profiles), Core Data Model (building Link Types and Entity Types once approved), Upstream Integrations (ingestion pipelines from ERP, PLM, or MDM), Downstream Syndication (outputs to e-commerce, print, marketplaces), Code & Extensions (server, scheduled, inbound, and outbound extensions), and Environment Management (Control Center, test, and production).
IT executes; it does not decide what the model should contain, what "complete" means, or how a category should be classified — those are business-meaning decisions, even when implemented through configuration.
Business Ownership — Defines What the Data Means
Business data owners are responsible for content and product-readiness judgment, not configuration, across six areas: Taxonomy & Hierarchy (designing categories and navigation, for governance approval), Data Enrichment (descriptions, translations, marketing attributes), Digital Asset Management (uploading and linking images, video, PDFs), Data Quality Rules (mandatory fields, completeness, validation criteria), Workflow & Approval (onboarding, enrichment, and sign-off execution), and Channel Readiness (approving when a product is ready to publish).
Business proposes and executes content decisions; new structures, fields, or workflow states still require Data Governance Office approval before IT builds them. Requests should go to governance — never straight to Control Center or an individual developer.
Responsibility Matrix (RACI)
Introducing the Data Governance Office
The missing function in most PIM programs is a standing body accountable for the data model itself, independent of delivery and any single brand — the Data Governance Office (DGO).
Charter and Mandate
The DGO needs real decision authority, not an advisory role — a function that can only recommend gets bypassed the first time a deadline is tight.
Composition and Placement
A practical starting composition: a governance lead, category data stewards from the business, and a technical liaison from IT. To arbitrate impartially, the DGO should report outside both technical delivery and any single business unit.
Where the DGO Sits in the Change Flow
Every proposed change — from business or IT — routes to the DGO first. It approves, modifies, or rejects, and only then does the technical team implement. This single control prevents both failure patterns described above.
Core Governance Artifacts
Three artifacts form the governance backbone, each deliberately platform-agnostic so the investment survives a future platform decision:
A taxonomy architecture, an authoritative data model, and a data dictionary remain valid regardless of which PIM or MDM platform enforces them — a deliberate hedge for organizations facing a future platform evaluation, not an afterthought.
Applying the Model Inside inRiver
inRiver provides the specific mechanisms that enforce this model technically:
Key challenge — undeliberated extensions are a maintenance liability, not a one-time cost. Every extension approved without deliberation is custom code the organization owns indefinitely, through every upgrade, staff turnover, and downstream change. Quickly built, thinly documented extensions accumulate into undocumented logic that makes the system progressively harder and more expensive to maintain. Treat every extension request as a governed decision, not just a technical one.
Worked Examples from a Live inRiver Environment
Core Data Model — a custom Entity Type requires a governance decision. The problem: inRiver has no hard-coded entity types, so "add a Supplier entity" looks like a routine build — and gets built the same week with no one defining what it means. Governed approach: the DGO confirms the definition, its links, and who may create one, and documents it in the Master Data Dictionary before IT builds the approved Entity and Link Type.
Data Quality Rules — a CVL change looks small and rarely is. The problem: a shared CVL like color spans dozens of categories; IT adds a requested value directly, not realizing the same CVL is also used elsewhere as a mapping table. Governed approach: CVL changes go on the same change-control path as any model change. The DGO checks every Fieldset and mapping that references it before approving.
System Administration — content segmentation as the RACI, enforced by the platform. The problem: a brand wants access locked down; IT configures something ad hoc with no documented policy, while a backend extension runs with system-level rights nobody reviewed. Governed approach: the DGO defines the access policy; IT implements it via Segments, Roles, and the ChangeEntitySegment permission. Extensions are reviewed for security footprint before they're built.
Channel Readiness — completeness groups mapped to channel readiness. The problem: every category has its own idea of "ready to publish," so completeness scores look inconsistent from brand to brand. Governed approach: criteria are grouped by destination (e.g., "Print ready," "Web ready"). Business defines what belongs in each group; the DGO approves for consistency; IT configures the view.
Data Quality Rules — a channel rule that encodes "ready to publish." The problem: each brand's publication logic gets hard-coded ad hoc by whichever developer picks up the ticket, with no record of why the rule exists. Governed approach: a shared query (e.g., product needs a linked Item and enrichment-complete = true) plus per-brand rules. Business defines it, the DGO reviews for consistency, IT builds exactly what's specified.
Integrations — listener extensions and syndication adapters. The problem: a developer adds a quick transformation inside an outbound adapter to derive a missing field. A year later, three more extensions are layered the same way, each understood only by its author — and every upgrade risks breaking one. Governed approach: IT builds the extensions and adapters that move data. Before approval, the DGO asks: does this just move data, or also decide what it means? The latter goes through the same approval path as a Dictionary change, and every approved extension is logged as a standing maintenance obligation, not a one-time build.
Governance Operating Cadence
A minimal, sustainable cadence:
Common Pitfalls and Anti-Patterns
Conclusion: Standing Up the Model
A well-run inRiver PIM program is the product of clear, durable ownership, not better configuration. Five steps to start:
- Charter the DGO with real decision authority over the data model.
- Baseline the three core governance artifacts as the starting standard.
- Publish the RACI matrix so IT and business know where authority begins and ends.
- Configure Roles, Segments, and Control Center/Enrich boundaries to enforce that RACI technically.
- Establish a governance cadence before the program's first anniversary, not after the first sign of drift.
Platforms change. Governance, properly separated from any one platform's configuration, is what keeps a PIM program trustworthy and extensible — long after go-live.