CaSE: Conversations about Software Engineering

The episode is packed with substantive concepts and practical distinctions - data marketplace vs. catalog, source-aligned vs. aggregated vs. consumer-aligned data products, producer-driven vs. consumer-driven contracts, open standards vs. proprietary tooling. The hosts ask clarifying follow-ups that elicit specific technical and organizational insights. However, some conversational padding (greetings, tangents about heat/air conditioning, brief side anecdotes) dilutes density moderately.

“The data marketplace to me is the system. This is where everybody meets. ah the The owner of data who shares data on. Simon ah The consumer can look for data, can request access, and then ah use the data.”

“The bottleneck is always domain knowledge. it's not ah send not so So it's not the knowledge of ah how to do data analysis, but it's more like you have to have the domain knowledge, and then you can be supported to do the analysis on your own.”

Simon presents a coherent, well-articulated framework linking data mesh principles to practical implementation via data products and contracts. The reframing of data contracts as governance + SLA enforcement (beyond schema) is thoughtful. However, much of the foundational thinking - domain-driven design, federated data ownership, the data mesh itself - originates from established prior work (Zhamak Dehghani, Gregor Hohpe). Simon's contribution is refinement and standardization, not radical novelty. The conversation is substantive but iterative rather than contrarian.

“I'm totally against putting automatically creating data products because this this has to be a step where say, I do this, I can help with a lot of tools to make it easy to do that, of course, but it should be a conscious step.”

“The data marketplace to me is a system. This is where everybody meets... everybody kind of meets in this in this marketplace. And that's why I think this is so such an essential component.”

Simon Harrer is a credible, hands-on practitioner: PhD in computer science, long-time consultant at InnoQ, author/maintainer of open-source tools (mob.sh, data-contract-cli), co-author of the Data Mesh book translation, and recently founded Entropy Data with a working product already deployed at customers. He speaks from real implementation experience (Breuninger case study, logistics shipments data product) and is embedded in standards bodies (Linux Foundation Technical Steering Committee for Open Data Contract Standard). This is not a career podcaster or pure theorist.

“We just founded in August 2025 together with Jochen Christ. It's a spin-off from InnoQ. And um it markets the data mesh manager that's a data marketplace built on data products and data contracts.”

“I'm also part of the Technical Steering Committee driving this open standard.”

Simon grounds key points in concrete examples: the Breuninger e-commerce distributed order management project, the logistics company's shipments data product with four output ports (REST API, Kafka, SQL, S3), user data products in e-commerce, and employee/application datasets internally at InnoQ. He cites specific technical tools (BigQuery, Snowflake, Kafka, OpenAPI specs, YAML). However, he is sometimes vague on customer deployment scale, pricing/cost tradeoffs (mentions $5 - 10 per terabyte scans in BigQuery but doesn't detail typical contract-checking frequency or cost impact), and does not name specific non-flagship customers.

“So we pumped our data from our operational systems that we um and we've built, like safe-contained systems. We pumped that to BigQuery from all the safe-contained systems into one one BigQuery project.”

“a large logistics company, and that most important data product was the shipments data product. Because it's a large logistics company, they have shipments for the road, Heinrich yeah. Heinrich Yeah. Simon ah sea, air, water, I don't know, several ah well there' have systems for each of that... it has four different output ports, so the same data. Simon But it's available through a REST API, a Kafka topic, on SQL tables on Snowflake, and as um I think JSON files on a AWS S3.”

The three hosts ask reasonably intelligent follow-up questions and occasionally push back (e.g., Alex probing whether data contracts differ from regular API specs, Heinrich raising practical concerns about tooling overhead and low-tech starting points). However, many questions are soft or exploratory rather than challenging. The hosts rarely press Simon on trade-offs, customer objections, or limitations of his approach. For example, when Simon says 'data monitoring can be really expensive,' the hosts accept a brief answer rather than drilling into real-world cost/benefit calculations or failure modes. The conversation is pleasant but lacks the adversarial edge that would sharpen claims.

“Alex It sounds really interesting. Simon And it's really an interesting situation right now.”

“Alex Would it help maybe? Let's just assume listeners have heard about the term data data products, but they are used to, let's say, classical ah API publishing.”