RADICAL five bullet friday • 2026-04-10
Your data is not an asset — until you treat it like infrastructure!
This week I had a revealing conversation with the CTO of a mid-size industrial company. They had invested significantly in a generative AI initiative; good model, solid use case, genuine business need. Yet nine months in, the project had barely moved beyond a demo. The culprit was not the AI. It was the data underneath it. Different teams were working from different versions of the same metrics. Pipelines were undocumented. Nobody was sure whose numbers were authoritative. The model was fine; the foundation was not.
This is the pattern I see most often when AI projects stall. Organizations have treated data as a byproduct of their operations rather than as a deliberate, engineered asset. Data gets collected as a side effect of doing other things, stored wherever it lands, and queried whenever someone thinks to ask a question. There is no ownership. There is no design. There are no contracts between producers and consumers. And then, when AI or advanced analytics arrive and demand something reliable, the cracks appear everywhere at once.
The companies that are pulling ahead are doing something structurally different. They treat data the same way they treat software: with versioning, testing, ownership, governance, and explicit interfaces. They invest in shared data infrastructure the way they invest in CI/CD pipelines or cloud platforms. Not as overhead, but as the foundation that makes everything else possible. A team that cannot trust its data cannot learn from it. A learning loop built on fragile inputs produces noise, not insight. And an AI agent operating on incoherent data will make confidently wrong decisions at machine speed.
The shift from "data we happen to have" to "data as infrastructure" is not primarily a technology project. It is a governance and accountability question. Someone must own the data. Quality must be measured. Schemas must be explicit. Pipelines must be observable. And access must be broad while ownership remains clear. None of this is glamorous, but all of it is load-bearing.
|
|
|
In this issue:
RADICAL update • External news • Thinking • Offer • Experiment
|
|
01 • RADICAL
RADICAL Principle #7: Data as Infrastructure
Data as infrastructure is the foundational layer beneath everything else in the RADICAL model. Continuous value delivery, AI-driven learning loops, superset platforms, and autonomous cross-functional teams only scale when they are built on a shared, reliable, and evolving data substrate. Without that foundation, these concepts remain aspirations rather than operational realities. In RADICAL organizations, data is not something teams simply "use". It is what the organization is structurally built around. Like code, data must be governed, versioned, tested, and evolved. Schemas, pipelines, and contracts must be explicit. Changes must be observable. Ownership must be clear, but access must be broad. Many organizations apply rigorous engineering discipline to software while leaving data as an unmanaged side-effect. The result is fragile analytics, brittle AI models, and endless internal debates about "whose numbers are right." The fix is to apply the same rigor to data that you do to software. Because in an AI-driven world, data is the infrastructure.
Deep dive here.
- Learn more about
RADICAL
- Work with us to assess your organization's data maturity
- Partner with us to design a data infrastructure roadmap and execute your transformation
|
|
02 • External news
News you can use - What happened in the world?
Below some news items about data as infrastructure and the challenge of AI-ready data.
•
The state of data mesh in 2026: From hype to hard-won maturity (Thoughtworks)
— A thorough field report on where data mesh is actually working and where it is not. The key finding: the biggest obstacles are organizational, not technical. The central data office must evolve from gatekeeper to enabling center of excellence — a pattern that maps directly to RADICAL's accountability thinking.
|
|
|
03 • Thinking
Data debt is the new technical debt — and it compounds faster
"The organizations winning with AI are not the ones with the best models. They are the ones with the most liquid data. "
The industry spent a decade talking about technical debt: the accumulated cost of shortcut software decisions that eventually slow everything down. I am increasingly convinced that data debt is a more serious and less-understood version of the same problem. Every undocumented pipeline is a liability. Every ambiguous metric definition is a future internal conflict. Every dataset with no clear owner is a risk that grows quietly in the background.
What makes data debt particularly dangerous in 2026 is that AI amplifies it. When a human analyst works with poor data, they usually notice something is off and slow down. When an AI agent works with poor data, it produces fluent, confident, wrong outputs at high speed. The compounding effect is not linear. It is multiplicative. And unlike technical debt, data debt is often invisible until something critical breaks.
I am thinking about what it would mean for organizations to measure data debt the same way they measure technical debt: tracking it, owning it, budgeting to reduce it and making it a board-level concern. What would your data debt balance sheet look like today?
|
What is your take? Is data debt on your leadership agenda, or is it still hidden in engineering backlogs? And what would it take for your organization to treat data quality as a board-level concern?
|
|
04 • Offer
Is your data foundation holding your AI ambitions back?
We run a focused Data Infrastructure Readiness Assessment — a structured session in which we work with your team to map your current data landscape, identify the critical gaps in ownership, governance, and pipeline reliability, and produce a prioritized roadmap for turning your data into a genuine strategic asset. This can be run online or in person, and is designed to produce actionable output, not a long consulting report. Contact us for a first exploratory chat!
|
Format: online video meeting or on-site
|
|
Audience: CTOs, CDOs, data leaders, heads of AI and product
|
|
Limited slots available — book by emailing jan@janbosch.com!
|
|
|
05 • Experiment
The "one metric, one owner" experiment
The fastest way to surface data infrastructure problems is to try to act on data. This experiment does exactly that.
Protocol: One metric, one owner
Time: 30 minutes of investigation, one week of observation
Steps: Pick one metric that matters to your business — customer retention rate, onboarding completion, support ticket volume, feature adoption, whatever is actively being discussed in your leadership conversations right now. Then do the following investigation:
Who is the single named owner of this metric? If you cannot name one person or team, you have found your first problem.
Where does this number come from? Trace the pipeline from the number back to the raw event or source system. Document every step. Count how many undocumented or informally maintained steps you find.
Ask three different teams to independently pull this metric for the same time period. Compare the numbers. If they differ, find out why.
What would it take to improve this metric by 10%? Could a team actually run an experiment to test an intervention — or would data access, unclear ownership, or pipeline fragility block them before they start?
What you are looking for is not just whether the number is correct today. You are looking at whether your data infrastructure is fit to learn from. A metric that exists but cannot be trusted, traced, or acted on is not infrastructure — it is an illusion of insight.
Share back: If you are willing, I would love to hear what you found. Send me an email at jan@janbosch.com — especially if the results were surprising.
|
|
|
You're receiving this because you subscribed at
janbosch.com.
|
|
|