Afleveringen
-
The conversation explores the debate between centralized and federated operating models, highlighting the impact of behavior on the success of these models. It emphasizes the need for a mature hybrid operating model that balances consistency and agility, with a focus on clarity and coordination across distributed ownership.
Takeaways
Centralized vs. federated operating modelsBehavioral impact on operating models🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
In this episode, Roland Brown discusses the critical distinction between architecture and operating model, emphasizing the importance of aligning these two layers for successful execution of data and AI initiatives. The role of architecture in enterprise transformation, the significance of operating models in data and AI initiatives, and the impact of aligning architecture and operating models are explored in detail.
Takeaways
Architecture vs Operating ModelExecution and StrategyAlignment of Architecture and Operating Model🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
Zijn er afleveringen die ontbreken?
-
The conversation delves into the journey of data products as intentional units of value, the gap between architecture and execution, the role of the operating model in execution, friction in the operating model, the danger of execution failure, and the importance of the operating model in creating value through consistent execution.
Takeaways
Data products as intentional units of valueExecution is where value is realized or lost🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
The conversation delves into the challenges and considerations of transitioning AI systems to production, emphasising the organisational commitment, alignment, and maturity required for successful operation. It highlights the importance of trust, context, and intelligence in production AI, and the distinction between experimentation and real systems.
Takeaways
AI in production is a commitmentProduction AI requires organisational alignmentTrust, context, and intelligence are crucial in production AI🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
The conversation explores the concept of AI theater, where visibility masquerades as progress, and the value of AI is measured by sustainable impact rather than impressive demos. It emphasizes the importance of discipline in AI, focusing on trust, context, and intelligence as key factors in building real value.
Takeaways
AI TheaterValue of AIDiscipline in AI🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
The conversation explores the role of AI in architecture, emphasising the importance of architectural decision-making, complexity, clarity, data patterns, AI in policy-driven environments, risk and consequences of AI, ownership and governance of AI, and restraint in AI implementation.
Takeaways
Architectural decision-making is crucial in determining the necessity of AI implementation.Restraint in AI implementation is essential for maintaining coherence and trustworthiness in systems.🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
The episode introduces the concept of explainability and its importance in AI systems. It emphasizes that explainability is not an AI feature but an architectural outcome, and it's about being able to retrace intent. The conversation sets the stage for a deep dive into the topic of explainability and its practical implications in the context of customer 360.
Takeaways
Explainability is not an AI feature, it's an architectural outcomeExplainability is about being able to retrace intent🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
The conversation explores the failure of AI governance, the need to move governance closer to where decisions are made, and the shift to product-centric governance. It also discusses the importance of specificity and context in governance, grounding governance in architecture, and enabling speed and scalability through product-based governance.
Takeaways
AI governance fails due to a product problem, not a policy problemGovernance needs to move closer to where decisions are madeProduct-based governance enables speed and scalability🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
The episode explores the concept of responsible AI and the role of humans in AI systems. It discusses the seduction of automation, the danger of full automation, effective human in the loop design, and common anti-patterns in AI systems. The importance of context, trust, and governance in AI systems is emphasized, highlighting the need for operational governance of AI as a product.
Takeaways
Human in the loopResponsible AI🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
In this episode, Roland introduces the Data Journey and discusses the importance of observability in AI systems. He explains the significance of observability in detecting gradual failures in AI systems and emphasizes the need for observability in data, model, and decision behavior. Roland also highlights the importance of ownership and response in observability and its role in supporting the AI ready architecture framework. He concludes by discussing the challenges of retrofitting observability and the critical role of observability in keeping AI systems aligned with reality.
Takeaways
Observability is crucial for detecting gradual failures in AI systems.Observability in AI systems encompasses data behavior, model behavior, inference data, ownership, and response.🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
The podcast episode explores the critical importance of data quality in the context of AI and machine learning. It delves into the nuances of data quality for training and inference, the impact of contextual quality, and the need for continuous quality observation and observability in AI systems.
Takeaways
Data quality for machine learning follows different rules than traditional data quality frameworks.Quality in AI systems is inseparable from observability and is more precise, contextual, dynamic, and architectural.🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
In this episode, Roland Brown discusses the importance of explainability in AI systems, emphasizing that it begins in the architecture. He highlights the significance of metadata as the architecture of meaning and lineage as a key factor in establishing trust and responsibility in AI systems.
Takeaways
Explainability begins in the architectureMetadata is the architecture of meaningLineage is about responsibility🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
The podcast episode explores the distinction between training data and inference data, highlighting the architectural discipline required for each type of data. It emphasises the challenges and root causes of architectural issues, and introduces the three-layer model for trust and the importance of metadata and lineage for AI systems.
Takeaways
Training data and inference data require different architectural discipline and trust guarantees.Metadata and lineage are crucial for AI systems, more so than for analytics.🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
The podcast episode explores the concept of AI-readiness and the architecture required for successful AI implementation. It emphasises the importance of trust, context, and intelligence in building a robust AI-ready architecture.
Takeaways
AI-readiness is about building a disciplined architecture from the ground up, with trust, context, and intelligence as the foundational layers.Trust, context, and intelligence are essential components of AI-readiness, and each layer must be established in a specific order for successful AI implementation.🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
When AI initiatives fail, the model is usually blamed.
But that explanation is structurally wrong.In this episode, Roland reframes AI failure as a data architecture accountability problem, not a mathematical one. AI doesn’t invent new issues, it faithfully exposes the decisions, trade-offs, and ambiguities that already exist upstream.
This conversation moves the focus from model performance to:
meaningfitness for useownershipobservabilitytrustBecause accuracy is downstream.
Architecture is upstream.🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
Most organisations believe they’re starting their AI journey by choosing tools, models, or use cases.
In reality, they’re starting a foundation test they’ve been postponing for years.In this series transition episode, Roland Brown connects everything explored from Episode 1 through Episode 70 to a single, uncomfortable truth: AI does not fix data it exposes it.
AI removes the human buffer that allowed inconsistency, unclear definitions, and silent quality issues to survive inside dashboards and reports. It consumes data continuously, learns from it, and acts on it. Whatever ambiguity exists in the data estate is no longer hidden it is operationalised.
The episode reframes AI as an amplifier rather than a solution.
Strong foundations accelerate value.
Fragile foundations accelerate failure.Roland walks back through the long arc of the podcast platforms, the Medallion Architecture, governance, metadata, lineage, operating models, reliability, SLAs, observability, and data products showing that none of these were isolated topics. Together, they form the minimum conditions for AI to work safely and sustainably.
The core shift is this: traditional analytics tolerated uncertainty because humans added context informally. AI cannot do that. It forces organisations to answer questions they were previously able to defer:
• Why does this data exist?
• What decision does it support?
• Which definition is correct?
• Who is accountable when something goes wrong?
• How is quality measured not assumed?These are not new questions.
They are the same unresolved issues data teams have lived with for years.The episode identifies the first points where weak foundations break under AI pressure:
• purpose that was never explicit
• definitions that were never reconciled
• ownership that was always implied
• quality that was never observableIn BI, these show up as debates.
In AI, they become outcomes.Roland then positions data products as the trust boundary for AI.
AI should not consume raw pipelines. It should consume products with:• a clear purpose
• an accountable owner
• known consumers
• explicit and measurable quality expectationsThis is where the Medallion Architecture quietly becomes critical again.
Bronze preserves truth.
Silver enforces consistency.
Gold expresses intent.AI belongs at the Gold layer where meaning is explicit and responsibility is clear.
The episode closes the data product chapter and opens the AI series by redefining what AI readiness actually means. It is not about model sophistication or tooling maturity. The organisations succeeding with AI are the ones with the least fragile data foundations, not the most advanced algorithms.
This is not a series about AI trends.
It is a series about architecture, operating models, governance, and trust in an AI-scale world.Discover insights on:
• Why AI is an amplifier, not a data solution
• How AI removes the human buffer that hid data problems
• Where weak data foundations fail first
• Why unresolved definitions become AI outcomes
• How ownership becomes unavoidable in AI-driven decisions
• Why data products form the minimum viable trust boundary for AI
• What AI readiness really means beyond tooling“AI doesn’t introduce new data problems.
It removes your ability to ignore the old ones.”🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
Most data initiatives don’t fail because they were badly executed. They fail because success was defined as delivery instead of value.
In this episode, Roland Brown brings the entire data products series together by tackling the foundational shift that determines whether everything discussed in Episodes 64 through 71 actually sticks: moving from project delivery to product thinking.
Roland explains why traditional project models dominate data work — clear scope, fixed timelines, sign-off milestones — and why these structures are deeply misaligned with how data products behave in real organisations. While projects optimise for completion, data products exist in environments that constantly change: business rules evolve, decisions shift, and consumer needs never stay still.
The episode highlights the hidden assumption that breaks most data products:
once something is delivered, its value is fixed.Data products don’t work that way. The moment a product goes live, it begins to age. Without ongoing ownership, feedback loops, and deliberate evolution, even well-designed products quietly decay.
Roland shows how project thinking surfaces in familiar behaviours:
“that was out of scope,”
“we delivered what was agreed,”
“that’s phase two.”These statements are reasonable in project contexts but destructive in product environments. Product thinking assumes change, while project thinking resists it.
Building on earlier episodes, Roland connects product thinking directly to:
• consumer-first design
• ownership and accountability
• data contracts
• honest success measurement
• sunsetting and lifecycle management
• discovery and marketplacesNone of these can survive in a delivery-only mindset.
The episode reframes success as something ongoing rather than binary. Instead of asking whether something was delivered, product thinking asks whether it is still useful, still trusted, and still relied upon. Ownership no longer expires at go-live, and feedback becomes an input rather than a disruption.
A practical reframe is introduced:
projects can still build capabilities — but products sustain value.Projects create motion.
Products create stability.Confusing the two is how organisations stay busy while trust erodes.
The episode closes with a leadership-level reminder:
value lives after go-live. When organisations continue to fund, measure, and reward delivery instead of confidence, data products will always underperform — no matter how modern the platform.Discover insights on:
• Why delivery is not the same as value
• How project thinking quietly undermines data products
• What product thinking changes in practice
• Why ownership cannot expire at go-live
• How feedback and evolution sustain trust
• What leaders must change for product models to stick“Delivery is an event.
Value is a responsibility.”🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
Almost every organisation claims to have a Customer 360.
Very few trust it. Even fewer use it consistently to make better decisions.In this episode, Roland Brown takes one of the most familiar and most misunderstood concepts in data and walks through it end-to-end as a true data product. Building on the principles established in Episodes 64 through 70, he shows why Customer 360 initiatives so often fail, and how product thinking fundamentally changes the outcome.
Roland explains that Customer 360 usually collapses under its own ambition. Teams try to create a single, complete view of the customer, integrating every possible source into one massive model. The result is technically impressive but operationally fragile. Definitions vary, ownership is unclear, trust erodes, and different teams quietly revert to their own versions of the truth.
The episode reframes the problem with a simple but powerful shift:
Customer 360 is not one product it is a family of data products, each designed for a specific decision and consumer.Instead of asking “what data should go into Customer 360?”, Roland shows why teams must start with the decisions they are trying to support, such as:
• retention teams deciding who to intervene with
• sales teams prioritising customers
• service teams understanding interaction history
• risk teams assessing exposureFrom there, distinct Customer 360 products emerge each with clear intent, scope, cadence, and interface all supported by shared underlying data rather than one monolithic asset.
The episode walks step-by-step through how Customer 360 changes when treated as a product:
• Intent shifts from completeness to decision support
• Ownership moves to the teams accountable for outcomes
• Contracts make definitions and expectations explicit
• Measurement focuses on adoption, reuse, and trust
• Sunsetting removes outdated views before they damage confidence
• Discovery surfaces the right customer product for the right decisionRoland highlights why ownership is the turning point for Customer 360. When accountability sits with “the data team,” ambiguity becomes normal. When it sits with retention, sales, service, or risk leaders, clarity becomes non-negotiable.
A practical walkthrough shows how the same customer data can power multiple high-confidence products — without duplication — when reuse happens beneath the surface rather than at the interface.
The episode closes by dismantling a long-held assumption:
a single view of the customer is useless if no one trusts what they are seeing.Customer 360 only delivers value when it is designed as a set of owned, trusted, decision-ready products — not as a technical artefact or platform milestone.
Discover insights on:
• Why most Customer 360 initiatives fail despite heavy investment
• How product thinking changes Customer 360 outcomes
• Why Customer 360 should be multiple products, not one
• How ownership clarifies definitions and trust
• The role of contracts, measurement, and lifecycle in customer data
• How discovery makes Customer 360 usable at scale“Customer 360 isn’t about seeing everything.
It’s about seeing enough to decide with confidence.”🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
Most organisations don’t struggle to find data.
They struggle to find data they can trust.In this episode, Roland Brown reframes one of the most hyped topics in modern data architecture, data marketplaces and discovery and explains why discovery is never a tooling problem on its own. Building on the foundations laid in Episodes 64 through 69, he shows why effective discovery is the last mile of trust, not the starting point.
Roland challenges the common belief that better search, richer metadata, or AI-powered recommendations automatically solve discovery. He explains why marketplaces fail when they are treated as inventory systems instead of signal amplifiers, surfacing noise rather than clarity.
The episode makes a critical distinction:
data marketplaces do not create trust they expose it.When ownership is unclear, contracts are implicit, products are poorly measured, and outdated products are never retired, discovery becomes guesswork. Users compensate by asking colleagues, copying old queries, or defaulting to whatever they used last regardless of correctness.
Roland defines what a data marketplace actually is in practice:
a curated environment where consumers can discover trusted data products, understand the decisions they support, see who owns them, assess fitness for purpose, and act with confidence.Crucially, the episode explains why only data products belong in marketplaces. Datasets are ingredients necessary, reusable, and powerful but exposing everything directly creates confusion. Marketplaces work when they surface a small number of high-confidence products, not every possible asset.
Drawing on earlier episodes, Roland shows how disciplined product practices make discovery possible:
• Consumer-first design clarifies intent
• Ownership provides accountability
• Contracts make expectations explicit
• Measurement surfaces what actually matters
• Sunsetting removes ambiguityWhen these foundations are in place, discovery becomes fast, contextual, and reliable.
A practical revenue example illustrates how weak discovery environments lead to conflicting definitions and endless searching while strong marketplaces guide users directly to the right product for the decision at hand.
The episode closes with a counter-intuitive insight:
organisations that focus on building marketplaces often fail while those that focus on building disciplined data products find that marketplaces emerge naturally as a reflection of maturity.Discovery is not a feature to be implemented.
It is a capability that must be earned.Discover insights on:
• Why discovery problems are really trust problems
• The difference between data inventories and data marketplaces
• Why products not datasets belong in discovery layers
• What signals actually matter in a marketplace
• How sunsetting improves discovery quality
• Why good discovery is an outcome, not a starting point“You don’t discover data.
You discover confidence.”🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
-
Most organisations are very good at building data products.
They are far less good at stopping them.In this episode, Roland Brown tackles one of the most uncomfortable yet essential capabilities of mature data organisations: sunsetting data products properly. Building directly on the failure modes discussed in Episode 68, he explains why keeping bad or outdated data products alive quietly damages trust far more than removing them.
Roland shows that most data products don’t linger because they are still valuable they linger because organisations avoid difficult conversations. “Someone might still be using it.” “We might need it later.” “It took effort to build.” These well-intentioned hesitations result in products that are neither alive nor dead, creating ambiguity, confusion, and false confidence.
The episode reframes sunsetting not as deletion or failure, but as a deliberate lifecycle stage one that was already implied in the anatomy of a good data product introduced in Episode 62. Products are born, they mature, they evolve and eventually, they should retire.
Roland outlines the clearest signals that a data product should be considered for retirement:
• The decision it supported no longer exists
• Trust has eroded to the point of constant validation
• No one is willing to own the outcome
• A clearer, better product has replaced itNone of these are failures. They are signals of change.
The episode then walks through what responsible sunsetting actually looks like in practice:
• Making the decision explicit instead of letting decay continue
• Identifying who is still impacted and how
• Providing a clear replacement or exit path
• Running a managed transition period
• Retiring interfaces cleanly and visiblyRoland explains why silent decay is far more dangerous than visible retirement. Products that quietly rot teach consumers that data products can’t be trusted not just the bad ones, but all of them.
A practical revenue example illustrates how sunsetting, when done transparently, actually increases confidence rather than disrupting it. Consumers know where to go, what to use, and what no longer applies.
The episode closes with a powerful maturity signal:
healthy data ecosystems are not defined by how many products they have but by how confidently they can let go of the ones that no longer serve decisions.Sunsetting is not an admission of failure.
It is an act of respect for consumers, for clarity, and for trust.Discover insights on:
• Why bad data products linger longer than they should
• The hidden cost of keeping outdated products alive
• How to recognise when a product should be retired
• Why sunsetting is a lifecycle capability, not cleanup
• What responsible, low-risk retirement actually looks like
• How killing bad products strengthens the entire ecosystem“A product you’re afraid to kill
is a product that’s already dangerous.”🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com
- Laat meer zien
