Ask this question in any large company: "who's responsible for the quality of your product data?" Nine times out of ten, the answer points to an IT team, a data team, or a project manager acting as go-between. Rarely the product manager, sales team or merchandiser who spend their days working with that data.
This isn't an accident. It's the result of a decade of centralized architectures where technical skill was the entry ticket to accessing data, changing it, or simply understanding where it came from. Business teams found themselves as passive consumers: they voice requests, wait for delivery, and often find the result doesn't quite match what they had in mind. The decision waits. The ticket stays open.
Why centralization failed
For a long time, centralizing data in a single IT-managed warehouse seemed like the right answer: one source of truth, controlled pipelines, specialized teams. In theory, it's solid.
In practice, data silos aren't just the product of disparate systems: they reflect siloed mindsets, where each department focuses on its own priorities at the expense of collaboration. The outcome is well known: missed opportunities, rising operational costs, hampered innovation.
The hidden cost is rarely measured: by the most common estimates, an employee spends between a quarter and a third of their time looking for reliable information. Not analyzing it, not deciding. Just finding it. Most companies don't track it. They should. You don't build intelligent systems on semantically poor foundations.
What "taking back control" actually means
The approach the industry is starting to adopt under the name data mesh rests on a simple principle: data ownership should return to the teams closest to its creation and use. Business domains stop being mere consumers: they become responsible for the production, quality and documentation of their data. The product team owns product data, sales owns customer data, supply chain owns stock data. It isn't a transfer of workload, it's a specialization of responsibility where it makes the most sense.
The benefits are direct: shorter time-to-availability, improved quality through clear ownership, fewer IT bottlenecks, better interoperability between domains.
But decentralizing without orchestration just trades a centralized silo for uncontrolled fragmentation.
The most common example is revenue. Marketing, finance and sales all use the same term to mean different scopes: with or without returns, gross or net, by order date or delivery date. Without a shared definition, each domain optimizes on its own and the overall view disappears. It isn't a goodwill problem, it's a semantic infrastructure problem: the missing layer between distributed data and aligned decisions.
It would be tempting to think a new architecture alone makes silos disappear. Data quality still depends on the quality of the processes that produce it. Business teams must accept a more active role in governance, and formalizing an ontology requires an upfront clarification effort that often surfaces divergences that were previously invisible. These constraints aren't obstacles to work around: they're precisely the work needed to turn scattered data into a company-wide usable asset.
Handing control back to business teams, without sacrificing rigor
GraphForge: the ontology without the complexity
The first obstacle to regaining control is technical. Defining an ontology, a formalized glossary of concepts, their relationships and their rules, used to require semantic-web expertise few teams have. The usual outcome: either it's delegated to IT and loses business precision, or teams give up and document it in a file no one maintains.
GraphForge removes that barrier. Teams capture their business knowledge and formalize the relationships between their concepts without writing a line of code. It's no longer IT deciding what a "finished product" or a "substitution relationship" is: it's the product team, with the tools to encode that decision in a way machines can use and executives can audit. Data stays in its source systems, the semantic layer is built on top, with no migration.
Explore: seeing what dashboards hide
Once the graph is built, navigation changes nature: you traverse data like a territory, following relationships, tracing chains of causality, spotting what stays invisible in a flat table. For a supply chain team, that means directly seeing which nodes are under stress, which alternate routes exist, where congestion risk concentrates. For marketing, it's the difference between a static segmentation report and a living exploration of purchase behavior. For HR, it's mapping real influence networks, not the official org chart.
KPI Forge: metrics that reflect business reality
Traditional KPIs measure what the tools allow you to measure. KPI Forge flips the logic: teams define what matters, and the metric is built from the paths traced in the graph. Supply chain tracks congestion link by link rather than a global average. Product tracks in real time the impact of a reference change on conversion. HR measures how talent complements each other within a team, instead of checking whether a profile fits a role.
AI Chatbot: an AI you can finally trust
This is the most differentiating component, and the one addressing enterprise AI's most documented failure. The main cause of that failure isn't technical: LLMs are exposed to data with no semantic context. When the model doesn't know what a "primary product" is in the company's own frame of reference, it produces a plausible answer, not a correct one.
By grounding the LLM in a precise business ontology, every answer becomes traceable and auditable back to its source in the graph. This isn't a promise of infallibility: it's an architecture that makes errors detectable and correctable, including in regulated environments. In practice, an employee can ask "which suppliers in our network are at risk if this supply route is blocked?" and get a sourced answer, with no data ticket, no weekly report, no intermediary.
What teams gain, domain by domain
In every case, the value doesn't come from a new dashboard. It comes from a clear view of the relationships between the data, letting you understand what's happening to act faster, something tabular architectures structurally can't provide.
Where to start: a four-step roadmap
Semantics is a business issue, not a technical one
The underlying shift taking shape in mature organizations isn't a technology revolution, it's a governance revolution. Data has long been treated as an IT by-product: something you extract, clean, store, and hand back on request. The knowledge graph, combined with data mesh principles, lets you treat it for what it really is: a business asset, carrying meaning, belonging to those who produce and understand it.
For a product or sales team, taking back control of your data doesn't mean learning to code in SPARQL. It means having a semantic infrastructure that speaks the business's language, applies its rules automatically, and reports back with no intermediary.
Next time your product team spends an hour figuring out why two systems don't agree on the definition of an "active product," remember: it isn't a bug, it's an architecture symptom. And like any architecture symptom, it has an architecture solution.
Sources
- Salesforce (2024): 62% of IT leaders cite data silos as a barrier to digital transformation, 44% can't fully leverage AI.
- Gartner: at least 30% of generative AI projects abandoned after proof of concept, mainly due to data quality.
- IT for Business: data silos as invisible barriers to business performance.
- Semsimo: knowledge graph and enterprise architecture, the semantic layer laid down with no migration.