Every object is a product.

Data is managed as standalone, reusable products. Each one sits on a ladder: simple building blocks at the bottom, richer products composed from them on top.

L0 · Reference

Shared code lists

Currency, country, language, units of measure. ISO standards curated once, used by everyone.

L1 · Atomic

Smallest meaningful facts

Address, contact, identifiers (VAT, DUNS, LEI). Each one is validated against L0.

L2 · Core

Business objects

Party (organisation, person), site and location, product and offer, built from atomic parts.

L3 · Composite

Relationships

Party-address links, hierarchies and roles: how core objects relate to each other.

L4 · Master

The golden record

Business Partner composes down the whole ladder into one trusted record, consumed through a contract.

1 · Ingest

Many sources, one truth to find.

Customer and supplier records arrive from several systems: CMDM, Dynamics, Ivalua. Each one has its own format, keys and gaps.

2 · Standardise

Speak the same language

Values are cleaned and validated against the reference lists (country, currency, address standards), so like can be compared with like.

3 · Match

Same entity, many copies

Records that describe the same real-world company are matched and given one golden id. Every source key stays cross-referenced.

4 · Survive

The best value wins

For each attribute, a declarative cascade picks the winner: source precedence → recency → completeness → steward override. Every decision is auditable.

5 · Publish

One record, four ports

The golden record is exposed through output ports: batch snapshot, change feed, API and governed query view. Consumers pick the port they need.

6 · Consume

Go-live is a config swap

Planning and ERP systems consume through the contract. Moving from mock to real data needs no rework on the consumer side.

1 · Entities

Name the things first

A model starts with the business entities we care about: Party, its roles, identifiers, contacts and addresses. Agree on them before writing any schema.

2 · Generalise

Organisation is a Party

Organisations and people share one abstraction, Party. Customer and supplier are roles a party plays, not separate copies of it.

3 · Relate

Cardinality tells the story

One party plays many roles, has many identifiers and contacts, and is located at many addresses. Addresses reuse the L1 atomic product.

4 · Identify

Keys you can trust

Each party gets a golden id. A cross-reference maps every {source, key} to it, and Business Partner masters the result.

5 · Contract

Publish the model as a contract

Schema, keys, semantics, quality rules and SLAs are packaged in a versioned ODCS contract. Consumers build against it from day one.