Why is your data strategy broken? The cost of silos
Digging into the cost of silos and introducing on how to fix them
In a fast-paced business world, companies are increasingly dependent on data to make strategic decisions. However, when you ask three different teams within the same organisation for the same data, you may receive three different answers. This isn’t just a technical problem, it’s a systemic issue caused by poor alignment between teams. This disconnect, often referred to as "silos," can have significant consequences, including inefficiencies, slow decision-making, and costly delays in data product development.
In this article, we’ll explore why siloed data strategies are broken and how nurturing transversality by adopting Domain-Driven Design (DDD) can provide a solution.
A hard truth in organisations
Data conscience within an organisation involve being able to answer the following questions:
Does the business understand the operational impact of data?
Does the business understand how to test the data?
Does the data engineer align with the business?
In large organisations, teams are often divided by specialised areas of expertise, such as business, software, and data. As a result, they tend to operate in isolation, leading to a lack of coordination and the creation of silos.
The siloed structure directly influences common understanding leading to substantial differences in the data conscience level across teams. Among your own organisation, how many of your teams can answer the 3 questions above mentioned?
Increasing complexity with transversal silos
To facilitate operations, teams are often structured around ‘organisational units’, intentional silos designed to focus on specific functions or domains. Within each unit, operational processes are optimized for that particular scope, making the structure both efficient and effective in its original context. This setup brings clarity, accountability, and operational focus.
While this structure might have made perfect sense when designed, the company’s business model and complexity evolve. And to enable stability and avoid disruptive change, they are not regularly challenged even when they no longer reflect how the organisation creates value. Over time, these legacy silos can become barriers to collaboration, creating friction across teams and slowing down initiatives that span multiple domains. We then observe a very complex system to operate transversally !
Several examples in the following graph:
In this context, Data Product Managers creating transversal products, notice that processes become fragmented and scattered across siloed teams.
Symptoms of a siloed organisation
The teams silos result in:
Knowledge sharing that consumes significant time and energy
Misunderstanding and misalignment between business processes and the data products being developed
Inflexibility in software architectures
Increased risk of bad decision-making
The lack of alignment among all stakeholders in the development of a data product typically results in a product that is difficult to use, hard to access, and governed inefficiently. When the architecture of the data product does not reflect the operational process, it creates a disconnect between engineering teams and the business. These data products are built on inflexible architectures that are costly to maintain, and business changes take far too long to be implemented.
To summarise, products and data products suffer from:
Lack of exploitability
Governance misalignment
Extremely long time to market
An example: product listed, product available or article sold?
As a user, I would like to buy a product.
My user-journey is the following:
I search for recommendation
I look at an influencer review on youtube
I search for its price on my favorite sports store website
I find it in my local store
Can you imagine what could go wrong?
Just for fun, I wrote this as a prompt on Chat GPT. The results felt like it already faces human daily struggles.
I might struggle to find relevant or trusted recommendations.
I could be overwhelmed by too many contradictory opinions.
The information could be outdated or biased (influencers or websites might have partnerships with brands).
The review might not be detailed enough or doesn't cover aspects I care about (e.g., quality, pricing, pros, and cons).
The influencer might have an undisclosed sponsorship or be biased towards a particular brand.
I may not fully trust the review if it feels overly promotional or unrealistic.
The video could be too long, making it hard to quickly assess the product.
The website might be slow or difficult to navigate.
The product might be out of stock, or I could find incorrect availability.
The price may vary from the information I saw in the review or YouTube video, which could be misleading.
The website might have poor search functionality, making it hard to find the exact product.
Shipping and handling fees might not be clear at first glance.
The product might not be available in-store even though it’s listed online.
The store might not have the right size, color, or model I want.
The product might be on sale online, but in-store it’s priced higher or with limited discounts.
There could be issues with store hours or availability.
I might not be able to reserve the product ahead of time, leading to disappointment if it’s sold out.The reality is that writing the business definitions of :
the product brief
the designed model and its different versions
the products promoted on the website
the models ordered for production
the actual item produced
the item available
the actual item sold
the item returned and maybe re-sold
Is everything but trivial, especially if processes are carried by different ‘organisational units’, not well defined and not described across the organisation.
In order for the company to operate, the teams coming from different perspectives (e-commerce, supply chain, conception) but managing the listing, eligibility to the e-commerce and sold articles must agree on a common ground. The necessity to spend time, money and brain juice to tackle this problem in a ‘one team’ approach is obvious.
This investment is for the sake of both internal teams who are struggling to operate their daily jobs, to use data, but also for end-users who will certainly be impacted as well.
Why is Domain-Driven Design a solution?
Driving a data transformation within an organisation requires cultivating strong collaboration across all teams involved in product development.
For leaders, this means intentionally addressing silos by fostering a collaborative culture, enabling cross-functional ways of working and designing transversal processes that are agnostic to the organisation. In particular, ensuring that every team member has both access to, and a clear understanding of, the relevant business knowledge.
That is especially where Domain-Driven Design can help. Domain-Driven Design is an approach to software development and data management that focuses on creating clear, structured domains within an organisation. By adopting DDD, organisations can break down silos and foster greater collaboration between business and tech teams, ultimately improving data management and decision-making.
The core idea of DDD is to break down large, monolithic structures into well-defined, independent domains. Each domain is responsible for a specific area of business, with a clear understanding of its responsibilities and boundaries. This approach allows teams to focus on solving problems within their domain, without constantly relying on other departments for data or resources.
Example with clear domain and subdomain responsibility:
From a governance perspective, ownership is grounded in a specific functional responsibility. Teams take ownership of a specific bounded context, which becomes a scoped business area.
This ownership includes:
Clarifying the domain model: Ensuring a shared understanding of key business concepts and terms within their bounded context.
Maintaining the integrity of the model: Making sure that changes within the context remain consistent with its purpose and do not introduce ambiguity or coupling with other domains.
Defining interfaces and dependencies: Explicitly managing how their context interacts with others, often through well-defined APIs or events, to maintain autonomy while enabling collaboration.
Aligning with the Ubiquitous Language: Using a consistent, business-aligned vocabulary across both technical and non-technical stakeholders to reduce miscommunication.
As the company’s business model evolves, so do domains, subdomains and bounded contexts. The key is to make sure that teams regularly and proactively revisit these definitions. This reflection becomes a natural part of their daily operations, ensuring that their context remains relevant, coherent, and aligned with the broader business strategy.
What’s next?
Silos hinder efficiency, slow down decisions, and complicate data usage. Adopting Domain-Driven Design breaks these silos by defining clear functional responsibility based on the company’s business model. In addition, the practice enhances the team autonomy to discuss, align, change and improve their existing domains.
Now that we’ve explored the why, we will try to explore the how!
If you have specific points that you would like to address, here is how to contact us:
