AArvindExecutive Cockpit

Ontology & Data Mesh

The logical layer that lets a half-migrated roll-up still answer one question consistently — model once, federate the data, generate insights anyway.

Arvind Limited · FY26 (Mar'26, actuals)
Among the world's largest denim makers
25,800 employees · 12+ plants & units · 30 export markets
🌱 Sustainability & circularityStep 1 of 7 · the data mesh behind the metricsCompany HierarchyAll journeys
🌐 Enterprise 360 modules· on Ontology & MeshBrowse all 31 views ▾
● LiveBuilt forKulin Lalbhai (VC) / Data· integrate logically, not physicallyCFO / FP&A· one number across many ledgersTransformation PMO· insight before full SAP migration

Arvind can't wait for every mill and export desk to migrate to SAP before it gets answers. The fix isn't one warehouse — it's a shared ontology (so everyone means the same thing) over a data mesh (each division owns its data as a product), with a semantic layer that federates them. Insights generate today; they just carry a confidence flag where a division isn't on SAP yet.

Data backing: enterprise ontology · knowledge graph · semantic layer · division registry · plant · org
Shared meaning (T-Box)

The enterprise ontology — what the words mean

Ten classes everything maps to. The Plant is the keystone: it's where division, leader, entity and geography reconcile.

Company
Company1
Arvind Limited (listed parent)
operates ▾ / owns ▾
The 'who' — accountability & ownership
Division5
Woven · Denim · Garments · AMD · Env
Growth engine / Entity10
divisions & growth engines
Leader (Person)16
org / accountability
operates ▾ (division → plant)
The keystone
Plant17
the reconciliation point
located in / serves / produces ▾
The 'what & where' — production & demand
Geography7
India hub + export rollup
Brand customer10+
apparel brands & B2B buyers
Order / Program
fabric orders · multi-year programs
Machine412k
looms · spindles · garment lines
Supplier6
cotton · MMF · dyes · machinery
Relationships (predicates)
Arvind operates DivisionArvind owns Growth engine / EntityGrowth engine rolls up to DivisionDivision operates PlantLeader accountable for Division / enginePlant located in GeographyPlant serves Brand customerBrand customer holds Order / ProgramProgram runs on MachinePlant produces Product / FabricSupplier supplies Plant / Order
Federate, don't centralize

Each division is a data product on the mesh

70% of revenue is already plant-grain actual; the rest is read in place from legacy mill/export systems and reconciled — no big-bang migration required.

Woven / Shirting
Woven / Shirting · division data product
Actuals
data quality / grain78%
Denim (core)
Denim · division data product
Actuals
data quality / grain74%
Garments
Garments · division data product
Allocated
data quality / grain72%
AMD – Human Protection
Advanced Materials · division data product
Allocated
data quality / grain94%
Knits
Knits · division data product
Actuals
data quality / grain71%
AMD – Composites / Industrial
Advanced Materials · division data product
Allocated
data quality / grain82%
Environmental (Envisol)
Environmental & Others · division data product
Region-only
data quality / grain80%
Digital & New Businesses
Environmental & Others · division data product
Region-only
data quality / grain45%
Defence & Aerospace push (AMD)
Advanced Materials · division data product
Allocated
data quality / grain75%
PAMI — circularity (PurFi JV)
Environmental & Others · division data product
Region-only
data quality / grain45%
10 division data products (above)
Federated semantic layer
entity resolution · canonical metrics · grain tags
Consumers
Story · Briefing · 360s · Simulator
Defined once, computed everywhere

Governed metrics — the logical layer

Every metric has one definition and a grain. The layer federates it across on-SAP and legacy domains, flagging where a value is allocated.

MetricDefinitionGrainHow it federates across divisions
RevenueΣ recognized revenueplant · orderactuals where on SAP; allocated from area where not
Adjusted EBITDArevenue − COGS − SG&A (+ add-backs)division · entityentity P&L normalized to one chart of accounts
Value-added & AMD revenueannuity-like program revenueprogramfrom SAP SD / MES across all divisions
Value-added mixvalue-added ÷ revenuedivisionfederated — same formula, many sources
DSOAR ÷ revenue × 365entity · plantlegacy/export entities measured at area grain, flagged
Gross margin(revenue − COGS) ÷ revenueorder · divisionmapped via canonical cost categories
Repeat-order rateexpansion − attrition on basebrand customerresolved across duplicate customer records
The payoff

How insights generate before integration finishes

1 · Resolve

Entity resolution matches legacy mill / division / plant codes to one canonical node — so the AMD data lines up with everything else.

2 · Federate

Query reads each division's data product in place; the semantic layer maps native SAP/MES fields to canonical metrics.

3 · Allocate + flag

Where a division reports at area level, allocation disaggregates to plant on learned drivers and marks it an estimate with a confidence band.

4 · Reconcile

Allocated parts must tie back to the source total; anomalies and duplicate brand-customers/suppliers across divisions are surfaced.

This is not theoretical — it's how this cockpit already works. The Story, Briefing and 360 views read the same governed metrics over on-SAP and legacy divisions alike; 70% of the numbers are plant-grain actuals and the balance is SAP-allocated and labelled. As each division migrates to SAP, its data product's grain rises and estimates flip to actuals — the mesh closes itself.