After nearly two decades working as a data architect, I’ve noticed a consistent pattern. When business stakeholders are frustrated with data, they're rarely talking about data platform components and architecture. They describe the symptoms rather than pointing to the root cause: data architecture issues.
Some of the main data issues business stakeholders get frustrated with are:
- Data is hard to access or painfully slow
- Simple questions take weeks to answer
- Numbers don’t agree across reports
- Teams don’t trust the data
- The platform costs a lot, but delivers little
What’s interesting is that these problems always originate much earlier, at the data architecture level.
The Business Symptoms Are Well Known
If you speak to CTOs, Heads of Data, or senior business leaders, the complaints are remarkably consistent.
- Trust in the data has eroded. The data is low quality or just wrong, Teams export data into spreadsheets because “it’s need to be worked on” to be useful.
- Data delivery is slow and brittle. Small changes take weeks and frequently break something else.
- Trust in the data team has been lost. Stakeholders no longer believe features delivered by the data team are correct, timely or worth their involvement. Leading to them build elsewhere because “it’s quicker to do it ourselves.”
These are often framed as caused by a lack data maturity, poor tech selection or resources are lacking capability.
But they are not – they are architecture problems.
A CEO at a care service company had been told, in no uncertain terms, that one more data issue with their major client would be the last and to stop adding new features to stabilise the product. However, without any clear data architecture the developers were firefighting defects, and the client leads were still promising more features to other clients. There was no prioritisation of automated testing, was no validation of the transformation patterns that continually produced number that fluctuated. This is where data architecture helped.
Data Issues Are Definitions of Testing Failures
When stakeholders say “we don’t trust the numbers”, they are describing an architectural failure.
Data issues are caused by:
- Data being defined differently in different teams; without identifying this the numbers will be wrong to one team or the other
- Data transformation defects that are fixed one month are broken the next; if a code defect has been made once, is more likely to be made again.
- Data Quality; “rubbish in, rubbish out” is true but it must be the data platform responsibility to make the stakeholder aware of these issues.
Without sticking to architectural processes to create data models that business and developers understand and architectural principles to automatically test transformation and validate data, trust degrades rapidly no matter how good the tools are.
In a large oil company, the fundamental concept of how to count petrol stations differed between countries. This issue was “fixed” back and forth and until nobody trusted the number, only by creating a conceptual data model was this misalignment identified and addressed.
IFRS17 and Solvency II regulation forced insurance companies to standardise their reporting, this opened the lid on widescale data quality issues across the industry. By incorporating robust and clear data validation the data platform we created for our client was not only able to handle the data quality issue, but it was essential in identifying them to be resolved.
Data Agility Depends on CI/CD, Not 10x Engineers
One of the most common hidden causes of slow delivery is the absence of proper CI/CD practices in the data platform.
Many platforms are “running”, but:
- Changes are deployed manually – not automated
- Environments drift over time – no infrastructure as code
- Testing is minimal and selective – not automated
- Deployments are high-risk events – not consistent between environments
This creates fear. Fear creates extra processes and checks. This creates delays.
A well-architected platform assumes constant change and is designed to make that change safe, repeatable, and reliable.
Business Stakeholder Engagement is Key
When trust in the data team has eroded, stakeholders stop engaging. They no longer believe that the data platform will be fit for their purposes and that their data use cases be best delivered within it.
The warning signs start subtle but escalate quickly:
- Business teams rebuild logic in spreadsheets or downstream tools
- Parallel data pipelines and tools emerge “because it is quicker”
- Funding in the platform stops as its been sidelined
It is easy for data team to be frustrated that the business stakeholders have low data maturity, but this is where a data platform roadmap helps. By collaborating with business stakeholders to build the data platform roadmap they know their needs are being priorities and they build data maturity through the more hands on experiences.
A Final Thought
When business stakeholders complain about data platforms, they are rarely wrong.
But the fix is almost never found in dashboards, tools, or overtime.
It starts with architecture; clear, pragmatic, evolving data architecture that exists to serve the business by delivering high-quality data platform feature and use cases quicker.
If you’re seeing the symptoms described above, the most valuable next step is a data platform architectural health check.
That’s how the root causes are identified and meaningful improvement begins.
