STARK Group

Experimental Solution

STARK MDM Concept Lab

A concept space that separates STARK MDM applications from the shared reference platform they depend on for validation, governance, and canonical translation.

Status: Draft concept walkthrough Source date: 2026-04-01
Target master domains 3
MDM prototype records 11
Open approval tasks 0
Domains in experiment DB 12
Reference values 83
Mapping entries 13
Back to David's module

MDM Prototype

Working small-scale Location MDM on top of the modular concept

New Location record
Supported now: Location Target modularity: Customer and Supplier can reuse the same core Excluded: Integration and syndication

Approval Queue

Records currently in review

No records are waiting for approval right now.

Open dashboard Open full worklist
Open runtime and architecture concept

Runtime View

How the MDM applications depend on the reference platform

01

Portal and Trusted Inputs

Customer, Supplier, and Location portals accept steward changes while approved upstream systems can submit inbound records through governed APIs and integration adapters.

02

Gateway and Access Control

The API gateway enforces authentication, authorization, tracing, throttling, and schema checks before changes reach domain services.

03

Command and Workflow Services

Write operations create draft versions, route approvals, apply SLA timers, and record business justification for every mutation.

04

Validation, DQ, and Golden Record

Validation rules, duplicate handling, survivorship logic, and versioning decide whether the next golden record version is accepted, flagged, or sent to manual review.

05

Reference and Rules Foundation

Reference domains, mapping sets, governance rules, and canonical standards provide the controlled configuration layer used by validation, UI labels, and integration translation.

06

SDM Facade and Distribution

Approved records are translated to SDM-compliant payloads, validated against canonical schema, and published through Kafka and read APIs.

07

Consumers and Reconciliation

ERP, CRM, analytics, and coexistence services consume the same canonical output while reconciliation services monitor parity with Informatica during migration.

Lifecycle

Golden record journey

01

Create or Ingest

A steward or trusted source creates a draft record with idempotent command metadata and correlation IDs.

02

Validate and Score

Synchronous field checks run immediately, then asynchronous DQ and duplicate checks enrich the task context.

03

Review and Approve

Workflow routes the record to the right approver based on domain, BU, sensitivity, and governance rules.

04

Publish Golden Record

An approved immutable version becomes active, is transformed to SDM, and is distributed to subscribed systems.

05

Reconcile and Improve

Parity checks, audit history, KPI dashboards, and steward tasks highlight drift, backlog, or rule improvements.

Interaction Contract

How the two concepts work together

Validation

MDM applications read governed reference values and format rules from the reference platform to validate portal entry, inbound API payloads, and DQ checks.

Canonical Translation

Before publish, MDM services use reference mappings and canonical standards to translate internal values into SDM-compliant output.

Governance Independence

Reference changes follow their own maker-checker lifecycle and can be versioned independently from master entity changes.

Runtime Dependency

MDM depends on reference APIs and event distribution, but the two concepts remain functionally separate so each can evolve without collapsing into one shared application.

Scalability Model

How the concept scales across domains, countries, and BUs

MDM Core

Shared services handle workflow, approvals, audit, versioning, events, access control, and reconciliation without hard-coding Location, Customer, or Supplier logic.

Domain Modules

Each master data domain contributes its own data model, UI composition, business rules, enrichment steps, and duplicate logic while reusing the shared core.

Country and BU Packs

Country-specific and BU-specific validations, formats, enrichment connectors, and attribute extensions are attached as modular rule packs rather than changes to platform-wide logic.

Reference Dependency

Validation and translation rely on the separate reference platform through stable APIs and event contracts, keeping shared dictionaries independent from domain implementation.

Modular Pipelines

Validation, enrichment, and publishing stay pluggable

Validation Pipeline

Schema validation, mandatory checks, reference lookups, duplicate checks, and domain business rules should run as composable modules registered per domain and country context.

Enrichment Pipeline

Address normalization, external registry lookups, geocoding, compliance enrichment, and source-specific processors should be attachable without altering the shared MDM core.

Publish Pipeline

Approved records pass through canonical mapping, SDM validation, and outbound event formatting in a controlled sequence that can evolve independently per domain.

Migration and Controls

Coexistence with Informatica

Coexistence with Informatica

During migration, ownership remains explicit by domain, attribute, and BU. Non-owner updates create reconciliation work instead of silently overwriting one platform with the other.

Dual-Run Guardrails

Cutover depends on parity thresholds, freeze windows, and rollback capability. Kafka synchronization stays active until the domain or BU is fully transferred.

Operational Controls

Target controls from the design docs include 99.9% business-hours availability, sub-2-second portal/API interactions, daily backups, encrypted storage, and full traceability.

Walkthrough Guide

Questions to use with the developers

01

Which responsibilities must stay in STARK MDM applications, and which should move into the separate reference platform?

02

What does MDM need to read from reference services at runtime for validation, translation, and UI guidance?

03

Which approval flows should be independent for reference changes versus master entity changes?

04

How do we want teams, APIs, and release cadence to reflect this functional separation?

Open MDM concept documentation

Concept Framing

Two Functional Concepts

The concept is now split into two functional layers: STARK MDM applications that manage Customer, Supplier, and Location records, and a separate reference platform that supplies controlled values, mappings, and validation inputs.

Concept Framing

Clearer Ownership and Control

This makes it easier to discuss which capabilities belong in domain MDM flows versus which belong in shared reference governance. It also creates a cleaner path for access control, lifecycle management, and team ownership.

Prototype Framing

Visual concept, not the final STARK implementation

Prototype Only

This site is a visual concept prototype for architecture and workflow discussions. It is not intended to become the final STARK production implementation.

Target Rebuild

The patterns shown here are meant to be lifted into the real STARK platform stack and reimplemented in the target runtime environment such as Azure and Kubernetes.

Current Scope

The prototype currently implements Location as the first walkthrough domain. Customer and Supplier are intentionally deferred until the Location SDM model and modular MDM foundation are in place, but the target platform must still support all three domains through the same shared core.

API and Integration Ownership

API contracts, endpoint design, integration patterns, and syndication flows are not being finalized in this prototype. Those parts should be designed and implemented by the developers who own the target runtime environment and know the surrounding platform integrations best.

Functional Split

Separate the MDM applications from the reference platform

Two concepts, clear contracts

STARK MDM Applications

Responsibility: Own domain workflows, golden record lifecycle, steward tasks, approvals, duplicate handling, DQ dashboards, and syndication of master entities.

Includes: Customer, Supplier, and Location portals, BFFs, command services, workflow engine, golden record engine, reconciliation, and SDM publishing.

Excludes: Should not own the definition of shared reference codes, external code mappings, or canonical validation dictionaries.

Reference Platform

Responsibility: Own governed reference domains, canonical values, mapping sets, hierarchy support, standards metadata, and deterministic translation rules.

Includes: Reference stewardship UI, value lifecycle, mapping lifecycle, import/export, approval controls, audit trail, and distribution contracts.

Excludes: Should not own master entity workflows, survivorship decisions for business records, or portal task handling for customer/supplier/location changes.

MDM Scope

Location is implemented first on a three-domain target foundation

Location now, Customer and Supplier later

Customer Domain

Focus: Customer onboarding, enrichment, duplicate control, and CRM/ERP syndication.

Golden record: Golden record for legal entity, contacts, segmentation, consent, and regional attributes.

Stewardship: BU steward enters and fixes data, approver validates governed changes, downstream systems consume SDM output.

Supplier Domain

Focus: Supplier onboarding, compliance attributes, bank details, PEPPOL, and risk controls.

Golden record: Golden record for supplier identity, sourcing attributes, payment details, and regulatory flags.

Stewardship: Sensitive fields stay policy-controlled with explainable approvals and audit history.

Location Domain

Focus: Branch, warehouse, and site hierarchy management with localized business-unit context.

Golden record: Golden record for address structure, usage type, operational flags, and ownership metadata.

Stewardship: Portal workflow supports local updates while preserving group-wide canonical structure.

Location Model

Text version of the extracted target structure

Target Structure In The Prototype

The Location walkthrough now follows the extracted model as four related structures inside one prototype record: Location, Facility, Branch, and Contact.

Address Embedded In Facility

In the supplied diagram, address fields are grouped inside Facility rather than shown as a separate Address entity. The prototype now reflects that structure.

Reference-Driven Attributes

Domain types, classes, statuses, facility types, branch types, contact types, capabilities, countries, and pricing regions are all read from the shared reference store.

Entity Structure

Location to Facility, Branch, and Contact

Location

Role: Top-level entity

Fields: LocationID, LocationSource, LocationName, LocationDomainType, LocationClass, ParentLocationID, CreatedDate, LastUpdateDate, Latitude, Longitude, GLN, Region, BU context.

Facility

Role: Child of Location

Fields: FacilityID, LocationID, FacilitySource, address fields, Country, FacilityManager, PhoneNumber, OperationalHours, OperationalStatus, FacilityType, Capabilities, BUOwnership, Capacity, FirmaCode, PricingRegion.

Branch

Role: Operational sub-entity under the location structure

Fields: BranchID, BranchName, BranchType, BranchSource, OperationalStatus, OpeningHours, ManagerContact, Capabilities, CostCenter, CreatedDate, LastUpdateDate.

Contact

Role: Linked to Facility and/or Branch

Fields: ContactID, BranchID, FacilityID, ContactSource, ContactName, ContactType, ContactEmail, ContactMobile, CreatedDate, LastUpdateDate.

Open Target State Location SDM

Target State

How the Location SDM should be understood

Target State, Not Flat Record Editing

The target state for Location SDM is a nested business structure, not a single flat form. One Location can own multiple Facilities, and each Facility can own multiple Branches, Addresses, and Contacts.

Operational Collections Are First-Class

Addresses and Contacts are collections because the same location structure must support country differences, business-unit extensions, alternate addresses, and several operational contact roles.

Prototype Direction

The prototype should therefore guide developers toward repeatable collections and modular validation per entity type, even if the current persistence layer still stores the structure as one versioned payload.

Golden Record Separation

The target solution should explicitly separate the Golden Record from local or source-specific master data. The Golden Record is the governed cross-domain representation, while local master data or source views can still exist as operational context without being treated as the Golden Record itself.

Cardinality

Relationship model for the target structure

Location -> Facilities

Cardinality: 1 -> 0..n

A single logical location record can contain one or many facilities, for example several operational footprints or country-specific facility nodes under the same governed location.

Facility -> Addresses

Cardinality: 1 -> 1..n

Each facility needs at least one address, but may carry several addresses for operational, legal, delivery, or country-specific use cases.

Facility -> Branches

Cardinality: 1 -> 0..n

A facility can have no branches or several branches, which is the key target-state requirement for the Location domain.

Facility -> Contacts

Cardinality: 1 -> 0..n

Facility-level contacts support shared operational ownership and roles that are not specific to one branch.

Branch -> Contacts

Cardinality: 1 -> 0..n

A branch can carry one or many role-based contacts such as branch manager, logistics lead, or customer pickup contact.

Data Model

Target State Location SDM entities

Location, Facility, Address, Branch, Contact

Location

Purpose: The governed top-level master record for the site concept.

Key attributes: LocationID, LocationSource, LocationName, LocationDomainType, LocationClass, ParentLocationID, GLN, Latitude, Longitude, Region, BU context.

Design note: Carries the cross-domain identity and the attributes that should stay stable regardless of how many child facilities or branches exist.

Facility

Purpose: The primary operational node under a location.

Key attributes: FacilityID, FacilitySource, CountryCode, OperationalStatus, FacilityType, Capabilities, FacilityManager, PhoneNumber, OperationalHours, BUOwnership, Capacity, FirmaCode, PricingRegion.

Design note: Facilities are the anchor for local operational data and the parent of facility addresses, facility contacts, and branches.

Facility Address

Purpose: Address collection attached to a facility.

Key attributes: AddressLine1, AddressLine2, PostalCode, City, RegionState, CountryCode.

Design note: The model should support more than one address because operational and legal usage can differ by country or business process.

Branch

Purpose: Operational sub-entity under a facility.

Key attributes: BranchID, BranchName, BranchType, BranchSource, OperationalStatus, OpeningHours, Capabilities, ManagerContact, CostCenter.

Design note: This is where the target state explicitly needs 0..n instances per facility.

Facility or Branch Contact

Purpose: Role-based contact collection attached to a facility or branch.

Key attributes: ContactID, ContactSource, ContactName, ContactType, ContactEmail, ContactMobile.

Design note: Contacts must be repeatable because one operational node can require several maintained roles and escalation paths.

Physical ERD

Normalized target tables

location (location_id PK) facility (facility_id PK, location_id FK -> location.location_id) facility_address (facility_address_id PK, facility_id FK -> facility.facility_id) facility_contact (facility_contact_id PK, facility_id FK -> facility.facility_id) branch (branch_id PK, facility_id FK -> facility.facility_id) branch_contact (branch_contact_id PK, branch_id FK -> branch.branch_id)

Target SQL

Physical table skeleton for the real platform

CREATE TABLE location ( location_id UUID PRIMARY KEY, bu_code TEXT NOT NULL, location_source TEXT NOT NULL, location_name TEXT NOT NULL, location_domain_type TEXT NOT NULL, location_class TEXT NOT NULL, parent_location_id UUID NULL REFERENCES location(location_id), gln TEXT NULL, latitude NUMERIC(9,6) NULL, longitude NUMERIC(9,6) NULL, region TEXT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); CREATE TABLE facility ( facility_id UUID PRIMARY KEY, location_id UUID NOT NULL REFERENCES location(location_id) ON DELETE CASCADE, facility_source TEXT NOT NULL, country_code TEXT NOT NULL, operational_status TEXT NOT NULL, facility_type TEXT NOT NULL, capabilities TEXT NULL, facility_manager TEXT NULL, phone_number TEXT NULL, operational_hours TEXT NULL, bu_ownership TEXT NULL, capacity TEXT NULL, firma_code TEXT NULL, pricing_region TEXT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); CREATE TABLE facility_address ( facility_address_id UUID PRIMARY KEY, facility_id UUID NOT NULL REFERENCES facility(facility_id) ON DELETE CASCADE, address_line_1 TEXT NOT NULL, address_line_2 TEXT NULL, postal_code TEXT NOT NULL, city TEXT NOT NULL, region_state TEXT NULL, country_code TEXT NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); CREATE TABLE branch ( branch_id UUID PRIMARY KEY, facility_id UUID NOT NULL REFERENCES facility(facility_id) ON DELETE CASCADE, branch_name TEXT NOT NULL, branch_type TEXT NOT NULL, branch_source TEXT NOT NULL, operational_status TEXT NULL, opening_hours TEXT NULL, capabilities TEXT NULL, manager_contact TEXT NULL, cost_center TEXT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); CREATE TABLE facility_contact ( facility_contact_id UUID PRIMARY KEY, facility_id UUID NOT NULL REFERENCES facility(facility_id) ON DELETE CASCADE, contact_source TEXT NOT NULL, contact_name TEXT NOT NULL, contact_type TEXT NOT NULL, contact_email TEXT NULL, contact_mobile TEXT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); CREATE TABLE branch_contact ( branch_contact_id UUID PRIMARY KEY, branch_id UUID NOT NULL REFERENCES branch(branch_id) ON DELETE CASCADE, contact_source TEXT NOT NULL, contact_name TEXT NOT NULL, contact_type TEXT NOT NULL, contact_email TEXT NULL, contact_mobile TEXT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() );
Open document alignment notes

Document Alignment

What is aligned and what needs confirmation

Aligned with FD/TDD

Domain-oriented modularity

The documents already describe domain-specific portals, shared platform services, SDM alignment, and reusable backend capabilities. The modular architecture in this prototype is a presentation of those same principles.

Aligned with FD/TDD

Country and BU variability

The functional design explicitly calls for multi-BU support, localization, configurable workflows, and governance by domain and BU. Country and BU packs are a scalable interpretation of that requirement.

Aligned with FD/TDD

Location-first phased rollout

Implementing Location first while Customer and Supplier follow later is a delivery sequencing choice, not a contradiction to the target design. The documents describe a broader MDM capability set, and this prototype now makes clear that Location is the first implemented SDM slice on top of that target direction.

Needs confirmation

Golden Record versus local master data separation

The prototype now calls out the need to distinguish Golden Record data from local or source-specific master data. That separation is consistent with the intent of the target design, but it should be made explicit in the target architecture if this is how downstream persistence, stewardship, and publish decisions are expected to work.

Needs confirmation

Functional separation of MDM and reference platform

The design documents strongly support reference/config stores and canonical mapping capabilities, but they do not yet state as explicitly as this prototype that reference management should be treated as a separate functional product area. If that separation is desired, either the solution description or the documents should make it explicit.

Needs confirmation

Prototype versus production platform

The documents describe target production architecture and operations. This prototype now explicitly states that the current implementation is only a visual aid and must be recreated on the real platform stack. That clarification is not a design conflict, but it should be documented so no one mistakes the prototype for the delivery target.

Aligned with FD/TDD

API and integration scope boundary

The current omission of final API contracts, endpoint structure, and syndication implementation in the prototype is intentional. Those concerns belong to the target platform realization and should be detailed by the developers who own the runtime environment, integration layer, and publish architecture.

Gap Analysis

How the current Location MDM prototype maps to FD and TD

Area, current state, next step
FD/TD Area Prototype Status Recommendation

Aligned

Location workflow and stewardship

Implemented and demonstrable. The prototype supports draft handling, validation, approval flow, version history, and steward-facing workbench behavior for Location.

Keep this as the baseline walkthrough and use it to validate role flows, UX, and core MDM lifecycle expectations before expanding into more domains.

Partial

Customer and Supplier domains

Not implemented yet by design. The current prototype only runs Location as the first SDM slice.

Document this as a phased rollout: stabilize the shared MDM core with Location first, then onboard Customer and Supplier onto the same modular foundation.

Gap

Golden Record separation

Only partially expressed today. The prototype shows versioned master data, but it does not yet make a fully explicit structural split between Golden Record data and local or source-specific master data.

Make Golden Record separation explicit in the target architecture and data model so stewardship, survivorship, storage, and publish rules can distinguish governed GR content from local context.

Partial

Location target data model

Functionally represented. The prototype now supports Location, Facilities, Facility Addresses, Branches, and Contacts in the target-state walkthrough, but persistence still uses a versioned payload structure rather than the full physical target model.

Use the documented ERD and SQL skeleton as the handoff model for the target platform implementation, while keeping the prototype payload approach only as a visualization aid.

Aligned

Validation architecture

Strongly aligned. Validation is modularized into reusable rules and a registry-based pipeline, with shared logic for references, addresses, contacts, GLN, and coordinates.

Continue growing the rule registry with country packs, BU overrides, and future business-rule modules instead of adding domain logic directly into route handlers or one-off scripts.

Aligned

Reference platform dependency

Aligned in concept and in prototype behavior. MDM reads reference-driven values and validations from the separate reference concept rather than hard-coding dictionaries into the domain workflow.

Preserve this contract boundary and let the target platform realize it with formal APIs/events owned independently from MDM workflow services.

Gap

Match, merge, and survivorship

Not implemented. The prototype does not yet behave like a full Golden Record engine with duplicate resolution, survivorship rules, or merge outcomes.

Treat this as a major next capability for the real platform design, and model it as a dedicated engine or service layer rather than folding it into simple CRUD or UI validation logic.

Partial

Workflow/state machine depth

Simplified. The current flow is enough for draft, submit, review, and approve, but it is not yet a configurable workflow/state machine per domain, BU, or sensitivity profile.

Let the target platform own richer workflow configuration and orchestration so approval rules can evolve independently of the portal UI.

Aligned

API, integration, and syndication

Intentionally out of scope in this prototype. The current app demonstrates user-facing behavior and concept boundaries, but it does not define the final endpoint structure, runtime contracts, or publish implementation.

Document these as target-platform responsibilities and let the developers who know the integration landscape define the production APIs, event contracts, and syndication patterns.

Gap

Target runtime and non-functional design

Not implemented in target form. The prototype is a single concept application and does not realize the production runtime concerns from TD such as service decomposition, OIDC/RBAC, observability, SLOs, or resilience patterns.

Use the prototype as a functional walkthrough only, and treat infrastructure, security, telemetry, and runtime topology as implementation work for the real platform environment.