Artwork for podcast Data Mesh Radio
#127 A Quest for Readiness: The Importance of Capacity to Change in Data - Interview w/ Winfried Etzel
Episode 12711th September 2022 • Data Mesh Radio • Data as a Product Podcast Network
00:00:00 01:14:51

Share Episode

Shownotes

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.

Winfried's LinkedIn: https://www.linkedin.com/in/winfried-adalbert-etzel/

MetaDAMA podcast (episodes in both English and Norwegian): https://podcasts.apple.com/us/podcast/metadama-en-helhetlig-podcast-om-data-management-i-norden/id1572639573

In this episode, Scott interviewed Winfried Etzel, Information Strategy Consultant at Bouvet, Board member of DAMA Norway, and host of the MetaDAMA podcast.

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

  1. Transformation teams - a team that helps domains to transform and upskill by embedding in the domain for a time - is an exciting pattern for data mesh.
  2. Transformation teams can collect information more easily and find patterns as they are closely collaborating with more domains.
  3. Think of transformation teams like a personal trainer - they help you get in shape so you learn what exercises to do and how but then you can work on your own. And you can engage them again if you need more help.
  4. How can we give guidance and enable change at the same time - the transformation teams shouldn't do the work for the domains but need to work with them. Can we go broad in the organization if we only have a limited number of transformation teams? Do we need to be in that much of a hurry where that's an issue?
  5. There's definitely some vendor washing going on around data mesh. It's often difficult to determine what is new and what they've recycled to sound new.
  6. In data, we should look to take many learning from software engineering but also other disciplines. History, political science, law, manufacturing, etc. all have something to teach us to better approach sharing our information with each other.
  7. "Data is a message to people in the future." What do you want to tell them? Data products are how we communicate with those people in the future.
  8. Data maturity models are crucial so you can self-reflect - are we really willing and capable to do what we need? And how can we measure how well we are maturing our capabilities?
  9. We need to adopt better change management principles in data if we really want to create data citizens. And you should explain how data is important to their role to drive buy-in.
  10. Potentially look at using a big bang approach to organizational changes if it is to something like upskilling or even ways of working. Doing a big bang approach for new responsibilities though is probably more challenging and less likely to work.
  11. Data ethics as a practice is relatively immature. Companies often don't see a purely business value to training people to act ethically. At most, the return on investment is indirect. Maybe we can figure out how to discuss it relative to retention? How many people want to be creepy and overstep with data simply because they can?
  12. Many data mature domains not only want to build everything themselves, they also want to set their own definitions and standards for things like data products. It may be a challenge getting them to participate in data mesh.
  13. When finding initial domains to work with in a data mesh implementation, look for domains with the capacity to change - willingness and ability. They will understand what they need to do and why even if they can't do it yet.

Winfried shared that in the data mesh meetups for Norway, most of the discussion thus far has been about domain driven design for data, data discoverability, and data as a product. If you are not sure exactly how to approach those topics or what they mean for your organization, you are not alone. And no one is quite sure what federated computational governance means either.


In order to do data mesh, Winfried believes people should consider the emerging pattern of Transformation Teams. These are teams that help domains by collaborating to build out their first data product - or possibly more - while also upskilling the team. Scott Hawkins at ITV (episode 48) discussed something similar. The transformation teams also are a great source for finding reuse as they are working with the domains and can more easily recognize patterns. They also can have an excellent perspective on how your implementation is going thus far. We need people that can enable change while giving guidance. A concern though is that the number of transformation teams is limited - how can you go broadly in the organization quickly? Or do you need to be in a rush to do so?


In Winfried's view, we need to take far more concepts from software engineering in general in data. Zhamak has stated this multiple times as many, many software engineering practices inspired parts of data mesh. Both mentioned Team Topologies as a crucial tool for change management. But we also should look to other areas outside software too. Winfried sees history as providing a lot of inspiration for data literacy. Political science can be a good way to think about organization design and communication. Law has millennia of examples of good ways to present arguments / one's context. Manufacturing can give us good insight into how we think about products including lifecycle - as Alla Hale discussed in her recent episode.


There are many data maturity models, most of which are not that differentiated, according to Winfried. They are still useful when assessing your readiness to do something like data mesh - at the macro and the micro/domain level. Are you organized correctly? Do you have the capability to do what's needed? Do you have the capacity - both meanings: the amount of time and the capability - to change? Are your teams ready and willing to share? Etc.


Per Winfried, in general in data, we have not adapted and adopted change management techniques all that well. We need to focus on providing strong learning paths so individuals can change to being "data citizens" as we evolve the overall organization. To inspire people to want to change and get better with data, we need to share with them how data is important to their role. Otherwise, it is homework with no purpose in their heads.


Should we go for a big bang approach or incremental, domain by domain? Winfried thinks it shouldn't be only one or the other. When it comes to things like upskilling or even changes to ways of working, big bang might be a better approach so you aren't having to constantly fight against the inertia of the historical patterns and working across so much time to get everyone to a new way of working. But Scott asked about trying to do a big bang approach to new responsibilities and both agreed that can lead to issues.


And we need to make sure we keep ethics as something top-of-mind when people learn about data - just because you can doesn't mean you should... Winfried doesn't believe data ethics as a practice has really matured yet. There is of course AI ethics but that is typically about biased inputs, not as much the "should we really even be trying to figure this out?" Companies don't really see the business value in data ethics - which is a challenge that everything has to be about driving business value. There are many cases, especially in the US now, where we need to think about potential harm much more than just potential risk of data exposure.


Winfried shared his view on a few things regarding data mesh and domain data maturity. The most data mature domains typically want to do everything themselves - that includes not just building but even things like defining data products. That can lead to challenges when trying to integrate their work into the broader mesh. The domains you should look for are the ones that "understand what they need to do even if they can't do it yet." Those domains have the capacity - the willingness and the ability - to change.



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, ItsWatR, Lexin_Music, and/or nevesf

Links

Chapters

Video

More from YouTube