Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
What data silos are, the three types and why they form, which ones to break and which to leave, and how to fix them by centralising context rather than moving data.
Updated on
A data silo is a body of data that is separated in a way that stops someone with a legitimate reason to use it from doing so. The separation can be physical, so the data sits in a system the person cannot reach. It can be human, so the data exists in a reachable system but a team controls who may look at it. Or it can be conceptual, so the person can reach the data and read it but the numbers do not agree with the numbers they already have.
The word is used far too loosely, and that vagueness is why silo projects fail. Having data in several systems is not a silo, it is how software works. A payments platform, a support desk and a marketing tool each hold their own records and always will. The silo is the blocked use, not the multiplicity.
That definition has a practical edge to it. Before you spend a quarter on a silo project, name the specific use that is blocked, the person who is blocked, and what they would do if they were not. If you cannot fill in those three blanks, you have found separation rather than a silo, and the work will not pay for itself.
These three behave differently, break differently and are fixed by different people. Treating them as one problem is why so many consolidation programmes deliver a warehouse and change nothing about how the business argues over numbers.
| Type of silo | What is separated | How you notice it | What actually fixes it |
|---|---|---|---|
| Technical | The storage. Data sits in systems that do not connect, in different formats, behind different interfaces. | An analyst says the data is in a system they have no way to query, so they export a spreadsheet instead. | Integration, a shared catalogue, or a pipeline. This is the only one a tool purchase fixes on its own. |
| Organisational | The access. The data is technically reachable but one team decides who may use it and answers requests slowly or not at all. | Requests for access sit unanswered, or they are granted for one project and revoked after it. | Ownership rules, a documented request path, and an executive decision that access is the default rather than the favour. |
| Semantic | The meaning. The same term describes different things in different places, so two correct reports disagree. | Two teams present the same metric with different values and both can defend their working. | Agreed definitions, written down and attached to the fields that carry them. No amount of pipeline work touches this one. |
A useful diagnostic: ask two people in different teams to produce the active customer count for last month. If one of them cannot get the data, you have a technical or organisational silo. If both produce a number and the numbers differ, you have a semantic silo, and moving the data into one warehouse will simply put both wrong answers in the same place.
Most articles on this subject imply that silos are the result of carelessness. That is rarely true, and saying it costs you the reader who knows exactly why their silo exists. Here is the honest version.
| Origin | What it looks like | Was it a mistake? |
|---|---|---|
| Acquisition | Two customer tables, two definitions of a subscription, two identity systems, and a migration that was descoped when the deal closed. | No. The alternative was delaying the acquisition to rebuild the data estate first. |
| Compliance boundary | Health, payment card or resident data held in a separate environment with its own access controls and its own region. | No. The separation is the control. This one is supposed to be there. |
| A team shipping fast | A product team stood up its own database because waiting for the central platform would have cost them the launch date. | Usually not at the time. It becomes one when nobody goes back and registers it. |
| A system nobody can retire | A legacy platform that still runs something critical, with the people who understood it long gone. | No. The risk of switching it off is real and the business is right to be cautious. |
| Departmental buying | Marketing, support and finance each bought the tool that suited them and each tool became the system of record for something. | Partly. Each purchase was defensible alone; nobody owned the sum of them. |
| Ownership held as influence | A team treats its data as a source of standing and controls access to preserve it. | Yes, and this is the only cause on the list that is a management problem rather than an engineering one. |
The reason this matters is that the cause determines the fix. An acquisition silo is resolved by a mapping and a definition, a compliance silo should not be resolved at all, and an ownership silo is resolved by a conversation between two executives rather than by anything anyone builds.
This is the section most silo articles skip, and skipping it is why so many programmes lose credibility halfway through. Some separation is load bearing. Merging it does not make the organisation faster, it makes it more exposed.
Run each silo through these four questions in order. The first Yes decides the outcome.
| Question | If yes | Why |
|---|---|---|
| Is the separation required by a regulator, a contract or a residency rule? | Leave it. Document the boundary instead. | Merging it creates a compliance failure. What you can do is publish the metadata so people know the data exists, without exposing the data itself. |
| Would merging it widen the blast radius of a breach or an outage? | Leave it, and connect the metadata only. | Separation limits damage. A single store holding credentials, payments and health records together turns one incident into a much larger one. |
| Is there a named person, today, whose work is blocked by it? | Break it, starting with that use. | A blocked use is a measurable payback. Work backwards from the person, never forwards from the architecture diagram. |
| Does it produce conflicting versions of a number the business reports? | Fix the definition first, before touching any pipeline. | This is a semantic silo. Consolidating storage without agreeing the meaning simply relocates the disagreement. |
| None of the above applied. | Leave it and revisit in six months. | A silo nobody is blocked by is not costing you anything yet. Spend the quarter on one that is. |
The decision rule in one line: break a silo when a named person is blocked from a named use, leave it when the separation is a control, and never merge storage to settle an argument about definitions.
There is a widely repeated figure for the annual cost of poor data quality that appears in almost every article on this subject and that nobody can trace to a method. We are not going to repeat it. The cost of your silos is measurable inside your own organisation, and these four symptoms are how you measure it.
| Symptom | What it looks like in practice | How to put a number on it |
|---|---|---|
| The same figure reported three ways | Finance, product and the board deck each carry a different revenue or active user number for the same month. | Count the recurring meetings whose main purpose is reconciling numbers, and multiply the hours by the seniority of the people in the room. |
| The analyst who cannot find the data | A question that should take an hour takes three days, most of it spent identifying who owns a table and asking for access. | Sample ten recent analyses and record the time from question asked to data in hand. The gap between that and the time spent analysing is the tax. |
| The duplicated pipeline | Two teams independently build the same extract from the same source system because neither knew the other had one. | Count distinct pipelines writing near identical outputs. Each duplicate is build cost paid twice and maintenance paid forever. |
| The decision that gets deferred | A pricing or inventory decision waits a fortnight because nobody trusts the number enough to act on it. | This is the expensive one and the hardest to quantify. Log the decisions delayed for data reasons over one quarter and ask the owner what the delay cost. |
These four are worth measuring before you start, because they are also how you will prove the work landed. A silo programme that cannot show the reconciliation meetings getting shorter has not finished.
The order matters more than the tooling. Teams that start by moving data spend a year building pipelines and arrive at a warehouse full of numbers people still argue about. Teams that start by writing down what exists usually discover that far less has to move than they assumed.
| Step | What you do | What done looks like |
|---|---|---|
| 1. Inventory what exists | List every system holding data anyone asks about, with an owner, a rough description and whether anyone outside the owning team can currently reach it. | A list that surprises at least one executive. It always does. |
| 2. Agree the shared definitions | Take the ten to twenty terms the business actually reports on and get one written definition for each, signed by a named person. | Two teams independently produce the same number for the same term. |
| 3. Connect the metadata before the data | Make what exists searchable: names, owners, descriptions, freshness, where a field came from. Not the rows, the description of the rows. | An analyst can answer where does this number come from without messaging anybody. |
| 4. Decide what genuinely has to move | Only now, and only for the uses that are still blocked once people can find and understand the data. | A short list of movements with a named beneficiary each, rather than a migration plan. |
| 5. Close the loop on new silos | Register new systems at the point they are created, so the inventory does not go stale within two quarters. | Registration is part of shipping, not a quarterly cleanup exercise. |
The insight worth carrying out of this article is in steps three and four. You often do not need to centralise the data. You need to centralise the context about it: what exists, what it means, who owns it and where it came from. A shared catalogue of that context removes most of the daily friction while the data stays exactly where it is, which is also the only approach compatible with the silos you are not allowed to merge. If that idea is new to you, our explainer on data context sets out what the term covers and why it is the layer that makes distributed data usable.
Two supporting pieces make step three real. Knowing where a value came from is data lineage, and it is what lets someone accept a number they did not produce. Knowing what a field means is what a data dictionary holds, and it is the artefact that turns an agreed definition into something a person finds at the moment they need it.
Technical and organisational silos are visible. Semantic silos hide, because everyone involved is doing correct work. Two analysts pull from the same warehouse, apply different but defensible definitions of the same term, and produce different numbers. Nothing is broken. The disagreement is real and it is about meaning.
The classic case is a term everyone assumes is obvious.
| Team | What they mean by active customer | Consequence downstream |
|---|---|---|
| Finance | Has an invoice paid in the last calendar month. | Excludes trials and annual accounts billed in a different month, so the count runs low against everyone else. |
| Product | Logged in at least once in the last 30 days. | Includes free users and internal test accounts, so the count runs high. |
| Sales | Has an open contract, whatever the usage. | Includes accounts that have not logged in for six months, which is exactly the group that is about to churn. |
| Support | Raised or replied to a ticket in the period. | A small subset of everyone else, which is why support side retention numbers never match. |
All four are defensible and none is wrong. The failure is that the same two words carry four meanings, so a board pack containing all four looks like a data quality problem when it is a definitions problem. No pipeline, warehouse or integration repairs that. The repair is a business glossary: one written definition per reported term, a named owner who can change it, and that definition attached to the fields and dashboards that use it so a reader meets it at the point of use rather than in a document they never open.
Deciding who owns a definition and how it changes is governance work rather than engineering work. If you want the wider structure that sits around this, our guide to data governance concepts covers ownership, stewardship and the operating model that keeps definitions current once they are agreed.
Decube is built around the argument this article makes. The platform catalogues what exists across your systems, records what each field means and who owns it, and traces where values came from, so people can find and trust data without it being moved into one place first. Decube data governance covers the ownership, definition and access side of that, which is the part of silo work that no pipeline resolves.
If you want to see what your own inventory looks like before committing to a programme, book a walkthrough with the Decube team and bring the two teams whose numbers disagree. That conversation tends to be more useful than any architecture review.
A data silo is a body of data that is separated in a way that stops someone with a legitimate reason to use it from doing so. The separation can be physical, so the data sits in a system the person cannot reach, human, so a team controls who may look at it, or conceptual, so the data is readable but the numbers do not agree with the numbers they already have. Data simply living in several systems is not a silo. The silo is the blocked use.
Technical silos separate the storage, so data sits in systems that do not connect. Organisational silos separate the access, so the data is reachable but one team decides who may use it. Semantic silos separate the meaning, so the same term describes different things in different places and two correct reports disagree. They need three different fixes, and the semantic one is the hardest because no pipeline work touches it.
Most of them are the residue of a reasonable decision. Acquisitions leave two of everything, compliance boundaries deliberately separate regulated data, product teams stand up their own storage to make a launch date, legacy systems survive because switching them off is risky, and departments each buy the tool that suits them. Only one common cause is really a failure, which is a team controlling access to its data as a form of influence.
They show up as four measurable symptoms: the same figure reported three ways, an analyst who spends days finding data rather than analysing it, duplicate pipelines built because nobody knew one already existed, and decisions deferred because nobody trusts the number enough to act. Each of those can be counted inside your own organisation, which is a better basis for a business case than any published market statistic.
No. Some separation is a control rather than a defect. If a regulator, a contract or a residency rule requires the separation, or if merging the data would widen the blast radius of a breach, the silo should stay and you should publish the metadata about it instead. Break a silo when a named person is blocked from a named use, and leave the rest.
In this order: inventory what exists with an owner for each system, agree written definitions for the terms the business reports on, connect the metadata so people can find and understand data without moving it, then decide what genuinely has to move for the uses still blocked, and finally register new systems as they are built so the inventory stays current. Starting with data movement is the common mistake.
Usually not. What has to be centralised is the context about the data: what exists, what it means, who owns it and where it came from. A shared catalogue of that removes most of the daily friction while the data stays where it is, and it is the only approach that works for the silos you are not permitted to merge in the first place.
A semantic silo is when the same term means different things in different parts of the business, so two teams produce different numbers and both are correct. Active customer might mean paid an invoice to finance, logged in to product, holds a contract to sales and raised a ticket to support. The fix is a business glossary with one owned definition per reported term, attached to the fields and dashboards that use it, not a data migration.
It solves technical silos and only those. Moving everything into one warehouse does nothing about a team that controls access, and it actively hides semantic silos by putting two conflicting definitions of the same term in the same place, where the disagreement now looks like a data quality problem. Agree the definitions before or alongside any consolidation.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Book a 30-min demo with us and see how lineage, quality, governance, and compliance come together in a single platform.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)