After 13 years leading data organizations across staffing, telecom, retail, and career services, I've watched the same pattern repeat at every company I've worked with: the data team builds something technically sound, and the business doesn't trust it.
Not because the data is wrong. Not because the engineering is bad. Because the data speaks a different language than the people who need to use it.
The gap nobody talks about
Your ERP system calls it a "sales order line item." Your finance team calls it "revenue." Your VP of Sales calls it "a deal." Your CRM has yet another term. When a data team builds a dashboard, they have to pick one of these languages, and whichever they pick, most of the organization won't recognize it as their own.
This is the language problem. And it's the reason most data investments produce dashboards nobody trusts, reports nobody reads, and "single sources of truth" that spawn competing spreadsheets.
Why this keeps happening
The standard approach to data modeling focuses on technical correctness: normalized schemas, efficient queries, proper indexing. These are necessary. But they're insufficient. A technically perfect data model that uses the wrong vocabulary is worse than a messy spreadsheet that uses the right one, because the spreadsheet, at least, speaks the language of the person making the decision.
Even within the same industry, every company features a distinct language that has evolved from its unique history, leadership, and diverse business mix. One recruiting company says "candidates." Another says "talent." A third says "associates." But all three might use the same applicant tracking system, which has its own, different, vocabulary.
Data teams are forced to translate. They build what amounts to an ad-hoc semantic layer, a mapping between what the source system calls things and what the business calls things. This translation work is invisible, undocumented, and lives in the heads of the people who built it. When those people leave, the translation leaves with them.
The semantic architecture approach
The fix isn't more technology. It's designing your data architecture around the language of the business from the start. I call this semantic architecture.
Semantic architecture means that your data model, your transformation logic, your dashboards, and your LLM-powered natural language queries all use the same vocabulary. When a business user asks "show me revenue by region," the system understands what "revenue" means in this company, because the semantic layer was designed to encode that definition once and propagate it everywhere.
This is different from a traditional data warehouse approach in three ways:
- Instead of starting with tables and columns, you start with the words the business actually uses and work backward to the physical storage. Language comes first.
- The model itself becomes the documentation. When you name things in the language of the business, you don't need a separate data dictionary that nobody reads.
- A semantic layer built on business language is inherently better for natural language queries. The AI doesn't need to learn a mapping that the humans already struggle with.
What this looks like in practice
At The Adecco Group, I led the data organization serving 60,000+ employees. The company operated across dozens of countries, each with their own terminology for the same business concepts. "Placement" in one market was "assignment" in another was "engagement" in a third.
Building a global data model required first building a global vocabulary, agreeing on what words meant before agreeing on what columns to create. That vocabulary work, which most data teams skip or rush through, turned out to be the most valuable deliverable of the entire program.
Starting the conversation
If your data team is spending more time explaining their dashboards than people spend using them, you might have a language problem. If your "single source of truth" has competing spreadsheets, you almost certainly do.
The good news is that semantic architecture doesn't require replacing your data platform. It requires rethinking how you model data, starting with language, not technology.
That's what we help organizations do at Eloquent Analytics. If this resonates, I'd like to hear about your situation.