Data Mesh Radio

Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

I share my strongly held belief that every data product consumer MUST register their use case with the producer and why it is so crucial and important. I sum up with these points:

1. Data isn't ever going to be self-describing, at least not deep, context rich data and it definitely won't be as we focus on data democratization. So, you need to register your use case to make sure you and the producer are on the same page for what is truly being shared
2. Data producers don't know what data consumers want - and especially don't know what potential data consumers want - without more information/conversation. Data producers kinda suck at doing that right now so help them out and improve the information flow. Who knows, they might have something way better for ya
3. You might actually be able to get at a heck of a lot more useful information if the producer 1) understands your use case and knows they can give you access to the PII/sensitive stuff because your use case is fine on ethical/legal/regulatory checks and/or 2) you are taking on the risk around if you violate ethical/legal/regulatory bounds.
4. You need to communicate what would most effectively help you achieve a target outcome and have a reasonable, collaborative negotiation between data producers and data consumers. Just consuming from a data product as-is might not meet your needs well enough.
5. Kinda similar to #1 but just getting a much better understanding of what you are really consuming. Does it mean what you think? Did you create an amazing insight, how can you collaborate with the producer to show that off? How can you make sure you will continue to get what you need as the data product evolves. I'll be digging somewhat deeper on the next episode with a rant on data contracts.

Data Mesh Radio is hosted by Scott Hirleman. If you want to connect with Scott, reach out to him on LinkedIn: https://www.linkedin.com/in/scotthirleman/

If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

All music used this episode was found on PixaBay and was created by (including slight edits by Scott Hirleman): Lesfm, MondayHopes,

Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

Transcript for this episode (link) provided by Starburst. See their Data Mesh Summit recordings here and their great data mesh resource center here. You can download their Data Mesh for Dummies e-book (info gated) here.

Bruno's LinkedIn: https://www.linkedin.com/in/brunoaziza/

Bruno's Medium: https://medium.com/@brunoaziza

Bruno's YouTube (Carcast videos): https://www.youtube.com/@brunoaziza

In this episode, Scott interviewed Bruno Aziza, Head of Data and Analytics at Google Cloud.

Some key takeaways/thoughts from Bruno's point of view:

1. The end goal of your data strategy should be to reliably and scalably turn data into value. The best way to do that is by creating data products. How you get there might be different but don't lose focus on turning data into value.
2. "The number one barrier to your ability to drive value of data is not your technology, it's your people and how you organize your team."
3. Focus on the point of what you are trying to deliver, not the actual output. It's not about delivering a dashboard, it's about creating a sustainable way to explore, share, and consume information/insights, whatever form that takes.
4. !Controversial!: There are 3 phases to getting to data driven; 1) is building a data lake or ocean, 2) is data mesh, and 3) is getting to a data product factory equivalent.
5. It's easy to try to put the cart before the horse in data. Before doing something like data mesh, you have to think how you will develop data as a function in your organization.
6. Understanding the data product manager role and leveraging data product managers well is crucial to building an effective data product strategy and practice. They are your data product CEOs.
7. A CDO's effectiveness...

Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/

All music used this episode was found on PixaBay and was created by (including slight edits by Scott Hirleman): Lesfm, MondayHopes, SergeQuadrado, ItsWatR, Lexin_Music, and/or nevesf

Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Sponsored by NextData, Zhamak's company that is helping ease data product creation.

For more great content from Zhamak, check out her book on data mesh, a book she collaborated on, her LinkedIn, and her Twitter.

We missed our window to record so I am interpreting what Zhamak is saying in her Medium post about why did she creator her company and the general state of the tooling market around data mesh. I also added on a the full 50min recording of our second recording which I had broken up into episodes 4-7.

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Data Mesh Radio episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/

All music used this episode was found on PixaBay and was created by (including slight edits by Scott Hirleman): Lesfm, MondayHopes, SergeQuadrado, ItsWatR, Lexin_Music, and/or nevesf

Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

I will have much more to say on federated governance in data mesh but to reiterate my points:

1. Federated doesn't mean decentralize everything. Really focus on enabling fast decisions with the people who have the understanding
2. Shared ownership of responsibilities or oversight but not owned by a central team can work. Stop thinking that this shoves all the ownership to the domain on day 1, they aren't ready for that
3. Start to plan out your governance roadmap pretty concretely at the start. But don't be worried about trying to have your ideal governance setup upfront. I've talked about CYA or cover your butt - think about what makes sense and what you can build as a skeleton upfront rather than trying to build a fully functioning body
4. Start to think about interoperability at the concept level, that semantic level but you don't need to have your ultimate interoperability plan from the start. You can enhance and develop it as you go. And go talk to people about what they are doing!
5. Blueprints. Do all the blueprints. Please, find friction and find a way to make easy buttons on this. There are 10s of episodes touching on this. Go look at what AgileLab is doing especially.
6. Leave automated access control stuff for later. Focus on fast requesting and granting access
7. Create data quality standards of measurement. That way everyone can understand how much they can trust a data product and why.
8. Data contracts are about a producer/consumer relationship. This ain't a transaction. Get to know both sides and build to an understanding of what information is actually shared.

Data Mesh Radio is hosted by Scott Hirleman. If you want to connect with Scott, reach out to him on LinkedIn: https://www.linkedin.com/in/scotthirleman/

If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

All music used this episode was found on PixaBay and was created by (including slight edits by Scott Hirleman): Lesfm, MondayHopes, SergeQuadrado,

Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

Transcript for this episode (link) provided by Starburst. See their Data Mesh Summit recordings here and their great data mesh resource center here. You can download their Data Mesh for Dummies e-book (info gated) here.

Neda's LinkedIn: https://www.linkedin.com/in/neda-abolhassani-ph-d-61354329/

OSDU Ontology: https://github.com/Accenture/OSDU-Ontology

In this episode, Scott interviewed Neda Abolhassani PhD, R&D Manager at Accenture Labs. To be clear, she was only representing her own views in this episode.

There's some very specific language about ontology in this episode but I think it's quite approachable for most people as a good understanding of ontology, the difference with taxonomies, and some specific insight into developing and applying an ontology.

Some key takeaways/thoughts from Neda's point of view:

1. When starting developing an ontology, it's best to start from the business questions you want to answer. It is okay to choose bottom up or top down, but the business applicability is the main point.
2. You can convince people ontologies and knowledge graphs aren't scary or that hard to learn and leverage with a small demo of what they do and how to use them.
3. Look for open ontologies that have already been created around your domain or area you are trying to model. They can usually be easily augmented and extended but there's no reason to reinvent the wheel.
4. Data people need to learn enough about the domain to build the right ontologies and data models but data people learning domain knowledge can "discombobulate" them :) Get the data people with the subject matter experts to learn what's necessary.
5. Try to keep your ontology as generic as possible but still encapsulate what you need; that way it is much easier to apply the ontology to other...

Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/

All music used this episode was found on PixaBay and was created by (including slight edits by Scott Hirleman): Lesfm, MondayHopes, SergeQuadrado, ItsWatR, Lexin_Music, and/or nevesf

Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

Transcript for this episode (link) provided by Starburst. See their Data Mesh Summit recordings here and their great data mesh resource center here. You can download their Data Mesh for Dummies e-book (info gated) here.

Ryan's LinkedIn: https://www.linkedin.com/in/ryandolley/

In this episode, Scott interviewed Ryan Dolley, an Independent Business Intelligence (BI) Consultant.

Before we jump in, lots of things in the key takeaways are marked as potentially controversial. Because much of what Ryan covered hasn't really been stated by a lot of people. So until we have more consensus, of course things _could_ be controversial.

Some key takeaways/thoughts from Ryan's point of view:

1. Begin with the end in mind. It's easy to lose focus on what you are trying to accomplish instead of what steps you are taking. Focus on what the target outcome is and use that as a North Star to measure if you need to course correct.
2. BI people need to brace themselves for a wave of innovation coming. There is so much - hopefully positive - change coming up the stack and BI people can embrace it or get washed over by the wave. Embrace and ride that wave and upskill!
3. ?Controversial?: Data mesh - and just about every other paradigm - does not focus enough on the last mile of analytics, at least not explicitly. So we need to get a lot more specific about what is necessary to actually take advantage of upstream improvements in data to deliver better analytics.
4. !Important!: We need to get more specific on who does cross-domain BI in a decentralized world. Otherwise, we have interoperable data but no one specifically leveraging that interoperability for improving our understanding of the overall organization.
5. BI as a practice needs to be much better at understanding and implementing iterative feedback. It's not been part of the playbook to date.
6. ?Controversial?: If domains develop BI...

Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Sponsored by NextData, Zhamak's company that is helping ease data product creation.

For more great content from Zhamak, check out her book on data mesh, a book she collaborated on, her LinkedIn, and her Twitter.

We wrap up another recording of Zhamak's corner talking about how do we actually start to look to build data products in a post pipeline data world. Data tools right now are kind of duct taped to each other and duct taped to the pipeline - how do we rethink starting from the end product - that mesh data product - and hook the tools to that to make interacting with it better. If you build a system that truly focuses on intentionality and responsibility that people can see, it creates trust. Away with the data black box!

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Data Mesh Radio episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/

All music used this episode was found on PixaBay and was created by (including slight edits by Scott Hirleman): Lesfm, MondayHopes, SergeQuadrado, ItsWatR, Lexin_Music, and/or nevesf

Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

Transcript for this episode (link) provided by Starburst. See their Data Mesh Summit recordings here and their great data mesh resource center here. You can download their Data Mesh for Dummies e-book (info gated) here.

Kineret's LinkedIn: https://www.linkedin.com/in/kineret-kimhi/

Kineret's Blog Post 'Do’s and Don’ts of Data Mesh': https://medium.com/blablacar/dos-and-don-ts-of-data-mesh-e093f1662c2d

In this episode, Scott interviewed Kineret Kimhi, Analytics Lead at BlaBlaCar.

Some key takeaways/thoughts from Kineret's point of view:

1. !Interesting Decision!: BlaBlaCar reorganized their data organization but did not fully decentralize by embedding people into domains. Instead, they kept a central team but combined multiple functions into a squad around domains - a key domain might have a data engineer, data analyst, data scientist, and a software engineer.
2. !Scott Mantra Too!: Sharing your experience - data mesh or otherwise - early and often with the broader data community means better and quicker feedback, not just internal experience. It's okay to be vulnerable about what didn't go well, you can get better info and help save others the same pain.
3. ?Crucial?: It's very important that when you split up your teams from functional data role teams, people keep in contact with functional role peers. If not, it can be very lonely as the only data engineer inside a domain. There is a significant turnover risk and a risk to not having scalable learning and knowledge transfer of data work if not handled well.
4. Data mesh will lead to a lot of potential changes to people's ways of working, especially with each other. Don't shy away from that, people need to know you aren't forgetting they need career development and that you'll support them as they learn and get...