A shared language for data and AI: why data-driven organizations align business and technology before anything else

A conversation with Skander Kouli, Lead Data Governance at Salomon, on how a shared business glossary became the foundation of data autonomy, and the forgotten prerequisite for AI at scale.

In every organization, there’s a word that changes meaning depending on who you ask. “Customer.” “Revenue.” “Active order.” Sales has one definition, marketing another, accounting a third, and customer service a fourth. Everyone is convinced they’re right. Nobody is lying.

And yet the same number in three different dashboards tells three different stories.

The hidden cost of language misalignment

This isn’t a technical problem. It’s a language alignment problem. And it’s expensive: on average, every employee loses one day a week searching for, checking, and reconciling information. Multiply that by the size of your data teams, and you get the silent bill your organization pays every year.

It gets worse. When AI enters the picture, it doesn’t invent a shared definition. It amplifies the existing mess, at its own speed and in every direction at once.

A live poll during the webinar confirmed that the vast majority of attendees said their company has no shared language. The finding cuts across every sector and every size, from SMEs and mid-sized companies to large international groups and the public sector.

The three layers of data misalignment

The gap shows up on three levels that stack up and reinforce each other.

The semantic layer. This is the most important one. It’s where definitions, KPIs, and interpretation live. If finance and sales don’t calculate “revenue” the same way, every decision based on it is fragile.

The technical layer. When a number appears in a report, nobody knows where it comes from, how it was calculated, or who’s responsible for it. Lineage is broken, and traceability is an illusion.

The organizational layer. A new hire, say a finance specialist, spends their first weeks hunting for the data they need. They discover that names differ from one team to the next, that reference data contradicts itself, and that no one can tell them who owns what.

Until these three layers are reconciled, governance stays theoretical and data autonomy stays a slogan.

The Salomon story: from the PACE program to data governance

Salomon, the French outdoor brand founded in Annecy in 1947, operates in more than 40 countries and is part of the Amer Sports group (Wilson, Arc’teryx). A growing share of its business runs through D2C channels, e-commerce and its own stores, which generates a significant volume of data to manage.

To make its teams autonomous with data analysis, Salomon launched a program called PACE (Power BI Adoption through Community and Empowerment), built on four pillars: Power BI training by skill level, a center of excellence with office hours, a community of practice, and shared data modeling best practices.

But one realization came quickly. You can train people on Power BI as much as you want: if the data behind it isn’t understandable, findable, and reliable, self-service never takes off. Teams were building dashboards, but they didn’t trust the numbers. They kept asking the same questions. What is this field? Where does this data come from? How is it calculated? Can I use it?

Skander Kouli’s conclusion: data governance isn’t a separate topic. It’s the foundation that makes self-service possible.

A five-step method: start small, then iterate

Rather than trying to govern everything at once (the classic mistake that kills most initiatives), Salomon chose a focused POC on the e-commerce scope, the domain with the highest stakes and the most friction.

Step 1: Scoping. Identify e-commerce data and critical systems, and prioritize the semantic models with the most impact on business decisions.

Step 2: Cataloging. Define business terms in a shared glossary, with a named owner and steward. The semantic view, the declarative part that requires business involvement, is documented and published.

Step 3: Lineage. Connect the business glossary (declarative) to the technical dictionary (automated through Snowflake connectors), then all the way to end usage in Power BI. This is the bridge between business language and technical language.

Step 4: Quality. Define quality rules, both technical rules on Snowflake pipelines and business rules with alert thresholds by region (EMEA, APAC, etc.). Document these rules in DataGalaxy as the central reference, then implement them in observability tools with automated alerts.

Step 5: Iteration. Replicate the method across other domains: B2B, logistics, marketing, HR. Each new domain gets at least one named owner and steward, with more added as the scope grows.

Data products: the paradigm shift that makes it all work

One paradigm shift sits underneath this whole approach: moving from a project mindset to a product mindset.

A data product isn’t a table or a schema. It’s a documented, reliable, traceable, and reusable asset with four essential properties. A named owner and steward, for accountability. Reliable documentation, accessible to every potential consumer. Quality indicators (completeness, accuracy, consistency, validity, uniqueness, integrity), measured and published. Regular monitoring to catch drift before it reaches consumers.

Once a data product is well governed upstream, everything built on it inherits that reliability: dashboards, ad hoc analyses, AI and ML projects. You stop building 50 short-lived dashboards and start maintaining a small number of data assets shared across the whole company.

The technical architecture: DataGalaxy, Snowflake, Power BI

The ecosystem Salomon put in place brings together three tools.

DataGalaxy handles governance: business glossary, technical dictionary, lineage, documentation. It’s the shared knowledge layer. Snowflake is the data platform where analytical models are exposed while Power BI is the visualization tool at the end of the chain.

DataGalaxy acts as the unifying platform. Snowflake technical metadata flows in automatically through a native connector, and Power BI models come in through another connector. Only the business view, declarative by nature, is maintained manually by data stewards.

The result: when a user sees a KPI in a Power BI dashboard, they can click the DataGalaxy browser extension to instantly get the business definition, full lineage, owner, and calculation rules. No more messaging the data team to ask “what is this field?”

Five key lessons for a successful data governance program

Skander shared five lessons learned that apply to any organization getting started.

Start small. The e-commerce POC proved value quickly, generated quick wins, and built the buy-in needed to expand to other domains. Trying to govern everything at once is the best way to never get started.

The business glossary is the foundation. No shared language, no reliable self-service. Paradoxically, it’s often the most neglected building block because it looks simple. In practice, that’s the worst mistake you can make.

One unifying platform, not a patchwork of tools. A single reference that connects the business view, the technical view, and end usage. It keeps information from fragmenting and gives every team the same source of truth.

Lineage builds trust. When users can see where data comes from and how it’s transformed, they use it. Without transparency, they doubt it and keep going back to the data team.

Adoption is a culture change, not a tool rollout. This is the daily battle. You need a strong business sponsor (at Salomon, the e-commerce team), trained relays (the stewards and owners), and an initial training campaign which is important to solidify the change within the organization.

Why a shared language is also the prerequisite for AI

The conclusion is worth underlining: everything Salomon did to enable Power BI self-service is exactly what makes AI possible at scale.

An AI agent querying a well-governed data catalog through an MCP server inherits the business context, sensitivity classifications, and access rules. A model trained on a certified data product inherits its quality. A decision-maker validating an AI recommendation can trace it back to its source through lineage.

Without these foundations, AI projects stay isolated POCs that never scale. With them, every new AI initiative moves faster, because it plugs into a foundation that’s already reliable.

The “secret” of data-driven organizations in 2026 isn’t a secret at all. It’s the patient discipline of building a shared language, making it the technical and organizational foundation of the company, and gradually connecting every new use case to it, business and AI alike.

Watch the full conversation on the webinar replay, and discover how DataGalaxy helps organizations build a shared language around data and AI.

Q&A

What is a shared data language in an organization?

A shared data language is a common set of definitions, KPIs, business terms, and calculation rules that every team in the company refers to. It usually lives in a business glossary hosted in a data catalog, with an identified owner and steward for each term. Without this shared foundation, each team builds its own definitions and every dashboard tells a slightly different story, which erodes trust in data and blocks self-service.

Why is the business glossary the foundation of data governance?

Because it’s the only layer that reconciles the business view and the technical view. The business glossary defines what a term means in the context of the company (a customer, an active product, recognized revenue), with an owner for accountability and a steward for maintenance. Technical layers such as tables, schemas, and dashboards connect to it through lineage. Without a glossary, technical data has no shared meaning, and analyses produced by different teams become impossible to compare.

What is a data product, and how is it different from a data table?

A data product is a documented, reliable, traceable, and reusable data asset, with an identified owner and steward, measured quality indicators, and regular monitoring. Where a data table is a technical object with no owner and no guarantees, a data product is a business asset with contractual quality. This product mindset, as opposed to a project mindset, lets you maintain a small number of data assets shared across the company instead of multiplying short-lived dashboards.

How did Salomon build its data governance program?

Salomon worked iteratively, starting with a focused POC on the e-commerce scope, the domain with the highest stakes and the most friction. The five-step method covered scoping critical data, cataloging in a shared glossary, lineage between the business glossary and the technical dictionary through Snowflake connectors, quality with documented rules and regional alert thresholds, and gradual expansion to other domains. The key: prove value first with a narrow scope before scaling.

What is the link between a shared language, data governance, and AI?

The same foundations that enable self-service BI enable AI at scale. An AI agent querying a well-governed data catalog through an MCP server inherits the business context, sensitivity classifications, and access rules. A model trained on a certified data product inherits its quality and traceability. Without a shared language and governance, AI projects remain isolated POCs. With these foundations, every AI initiative can plug into a reliable base and move faster.

About the author: Skander Kouli

Lead Data Governance at Salomon

Skander Kouli is Data Product Manager and Lead Data Governance at Salomon. He leads data governance and data product management initiatives to improve the quality, reliability, and value of data across the company. His expertise helps teams put effective data practices in place, aligned with business priorities and the organization’s strategic goals.

About the author: Skander Kouli

Tech Team