Global Beauty Leader: engineering a federated data fabric for global growth
A Global Beauty Leader had grown into a fragmented estate where 'customer' meant different things in eCommerce and in retail. Unolabs assessed the domains, designed domain-oriented data products on Databricks, and paired federated governance with a master data management hub. Golden customer and product records now anchor analytics across every market.
A concise view of impact and engineering focus.
client-estimated 30-40% faster analytics delivery
Trusted single customer & product view
AI-ready beauty insight foundation
What expansion did to the definition of a customer
Rapid international expansion left a major beauty leader with a fragmented data estate spanning eCommerce, retail, marketing, supply chain and finance. Each market and channel had grown its own systems, and with them its own definitions. 'Customer' meant one thing to the eCommerce team and another to retail; product hierarchies diverged between markets.
The cost showed up as friction at every level: analysts reconciling numbers instead of analysing them, duplicated business logic maintained in parallel, and no single view of the global customer or product. No dashboard makes that kind of disagreement visible until somebody tries to reconcile the totals.
For a brand whose ambitions included predictive personalisation and autonomous demand forecasting, that was a hard blocker rather than a housekeeping item. Models are only as coherent as the entity definitions beneath them, and those definitions did not yet exist at enterprise scale. No amount of modelling effort compensates for two teams meaning different things by the same noun.
Inconsistent master data is not a reporting nuisance — it is a structural ceiling on every AI initiative downstream. Fixing definitions is the prerequisite, not the follow-up.
A 6–8 week assessment that surfaced the real conflicts
We completed a 6–8 week architectural assessment covering the customer, product, eCommerce, marketing, supply chain and finance domains. It deliberately went deeper than an inventory, tracing where silos had formed, where business logic was duplicated across teams, and where master data definitions conflicted. Each of those is a distinct engineering problem with a distinct remediation path.
From that evidence base we designed the target state: a unified platform scope covering the core domains; domain-oriented data products built on Databricks with shared analytics services; a federated governance model pairing central enablement with domain autonomy; and a Master Data Management hub producing golden customer and product records.
The sequencing mattered more than any single component. Governance and MDM were designed alongside the platform rather than bolted on after the data had landed, because retrofitting a definition onto data already in production means renegotiating it with every team that has since built on it.
- Unified platform scope covering customer, product, marketing and supply chain
- Domain-oriented data product design using Databricks and shared analytics services
- Federated governance model with central enablement and metadata controls
- Master Data Management (MDM) hub for unified golden customer and product records
A 6–8 week assessment is short enough to keep momentum and long enough to surface the real conflicts in domain definitions — the deliverable is an evidence-backed target state, not a slideware vision.
Where federation ends and central guardrails begin
The target state pairs domain-owned data products with standardised ingestion layers, so domains keep authority over their business logic while sharing common mechanics for landing and processing data. Security, metadata and observability guardrails are centralised, because those are the areas where fragmentation does the most damage. Analytical modelling stays with the teams closest to the business questions.
The design also names authoritative sources for customer and retail master data. For any given entity there is now exactly one place the enterprise agrees is correct, and every downstream product traces back to it.
That boundary — central guardrails, domain content — is what lets a global organisation scale analytics without either a central bottleneck or a slow drift back into silos. It holds only while it is explicit. Where the line is left implied, both sides assume the other owns the awkward middle, and the awkward middle is where definitions rot.
Federated governance is an operating model, not a technology choice: central teams own guardrails and enablement, domain teams own their data products — and the boundary between the two must be explicit.
The outcome: reconciliation removed, definitions agreed
The engagement delivered client-estimated 30–40% faster analytics delivery and a trusted single view of customers and products across the enterprise ecosystem. The second of those outlasts the first.
That velocity gain is measured against the fragmented prior estate, which is exactly the point: the platform removed the reconciliation work that had consumed analyst time in every market. It is a client-side estimate rather than an instrumented benchmark, and it should be read that way in diligence: the heavier the reconciliation burden beforehand, the larger any such figure looks afterwards.
Beyond the immediate analytics gains, the platform established the synthetic data factory required to train autonomous marketing agents, giving the brand high-fidelity production twins with which to simulate global growth scenarios before committing spend. Data stopped being an expansion by-product and became the substrate the next phase of growth is built on, which is a different kind of asset to defend at budget time.
What we'd flag: federated governance holds only as long as domain teams staff real data-product ownership — central enablement can support that accountability, but it cannot substitute for it.
Technical blueprint of the solution
This diagram visualises the core architectural pattern, data flows, and security boundaries implemented during this engagement.
What to carry into the next sprint
Takeaway
Fix conflicting entity definitions before funding the models that depend on them.
Takeaway
Write down where central guardrails stop and domain ownership starts.
Takeaway
Name one authoritative source per entity and make every product trace back to it.
Frequently asked questions
- Why does master data have to be fixed before AI, not after?
- Because models inherit whatever incoherence sits beneath them. Where eCommerce and retail mean different things by 'customer', a personalisation or demand-forecasting model trained across both learns a blend of two entities rather than one. For this global beauty leader, a Master Data Management hub producing golden customer and product records was designed alongside the platform rather than retrofitted afterwards.
- What does a 6–8 week architectural assessment actually produce?
- An evidence-backed target state rather than a slideware vision. The assessment traced where silos had formed, where business logic was duplicated across teams, and where master data definitions conflicted across the customer, product, eCommerce, marketing, supply chain and finance domains. That window is short enough to keep momentum and long enough to surface the conflicts that matter.
- Is the 30–40% faster analytics delivery independently measured?
- No. It is client-estimated 30–40% faster analytics delivery, assessed by the client against their own fragmented prior estate rather than against an independent benchmark. The comparison is honest but relative: the heavier the reconciliation burden beforehand, the larger the apparent gain afterwards. Read it as directional evidence, and ask us what was measured — the answer depends on your own baseline.
- What makes federated governance fail after go-live?
- Under-staffed domain ownership. Federation holds only as long as domain teams resource genuine data-product ownership: someone accountable for definitions, for quality and for change. Central enablement can support that accountability with metadata controls and shared guardrails, but it cannot substitute for it. Where ownership is a title rather than a funded role, definitions drift apart again.
- Does a single global platform remove local market autonomy?
- Not in this design. Domains and markets keep authority over their business logic and their analytical modelling, while ingestion, security, metadata and observability are standardised centrally. What they give up is the freedom to hold a private definition of a shared entity, because customer and retail master data now have named authoritative sources every downstream product traces back to.
Find out which of your entity definitions actually conflict
We will trace customer and product definitions across your markets and channels, and show you where they diverge, where logic is duplicated, and which conflicts block the models you are already planning.
Book a Data Fabric Review