Provided as a free resource by DataStax AstraDB
Data Mesh Radio Patreon – get access to interviews well before they are released
This episode is part of the Data Innovation Summit Takeover week of Data Mesh Radio.
Data Innovation Summit website: https://datainnovationsummit.com/; use code DATAMESHR20G for 20% off tickets
In the last of the interviews for the Data Innovation Summit Takeover week, Scott interviewed Henrik Göthberg, the Founder and CEO of consulting company Dairdux, the Co-Founder of the Airplane Alliance, and the Chairman of the Data Innovation Summit.
Let’s start with some conclusions/advice from Henrik:
- When working with other departments, in data mesh or not, you need to start from respect, empathy, and understanding for people in different roles.
- When you think about maturing a domain or process, a big bang approach very rarely works. You need to think about evolution, not revolution.
- To find a good pathway to maturity, start with the domains already on the leading edge, the innovators; trying to get the laggards to catch up instead of focusing on those who see value in maturity is going to lead to pain and likely not much progress.
- Start with less complicated and high risk challenges so you can learn and develop the right muscles to do things easier in the future.
- Focus heavily on reuse – reusable data, yes; but also templates and other “easy path” enabling things. To succeed in data mesh, you need to get to a place where you can have broad reusability. Reusable data, reusable processes, reusable templates, reusable tooling, etc.
- In a data mesh implementation, start with an initial domain but move on to adding a second domain quickly if possible. Templates will get you to value quickly.
- It’s okay to skip automating or building out a great solution for certain pieces of your data mesh implementation. What will get you in trouble is building half-solutions that end up as major pain points. This is the biggest source of unintended tech debt.
- If you business people don’t understand they own the processes and the data, your data mesh implementation is much more likely to fail.
Background and other color:
Henrik covered his journey from 2012 to present in most of the first 30 minutes – from joining a domain to add analytics capabilities to that domain to building out a large data and analytics central team at the same company to joining a new company in 2019 to help them implement a new data strategy which has evolved into implementing data mesh.
Henrik joined Vattenfall to build out the data and analytics team inside the sales org. They had a multi-country domain with different maturity levels across each country. They needed to improve the data and analytics capabilities and operations in all three countries so they could have strong data and analytics capabilities at the country and European level. The team had some technical savvy but they were struggling with actually getting the data – the data was locked into the source systems. It was difficult to even do basic customer analysis and data science, not to mention anything fancy. So they needed a lot of help in maturity.
In 2015, Henrik became the Business Intelligence Officer at Vattenfall. That meant taking ownership of the centralized team with lots of core data and analysis. A big part of the role was owning providing costs in very granular ways so needed to try to move to a very standardized reporting model for P&L.
A big change was in consumer maturity. When Henrik first started the role, people were mostly consuming reports. They moved to consuming data sets and even raw data. As part of that, they often moved from ETL to ELT, which caused some major headaches as many have seen with the data lake.
All of that background maturing the data and analytics capabilities helped Henrik when he joined Scania, a truck manufacturer, in their financial services division. The culture of the company was already very decentralized and modular, which can set up well for data mesh but that also meant domains were very independent with limited standards or standardization around data enterprise-wide. They had a big data lake implementation with a good raw data layer and a semantic layer but the analytics layer on that was lacking. The centralized data team was struggling to even manage the raw data layer from a governance perspective and they were feeling increasing strain from issues trying to manage data pipelines.
Henrik mentioned the necessary evolution process for domains – a “big bang” approach very rarely works. And Henrik started with the domains in the innovator category as they were the most bought in on domain maturity. As part of this process, they were able to decommission many large data warehouses.
To start, Henrik focused on what was valuable to build for the domain – the micro level – instead of valuable to the greater organization. That way, he could mature that domain much faster and if there are multiple mature domains, those mature domains are better prepared and capable to work with each other. There was a focus on building reuse wherever possible – not just reusable data but what templates and other easy path things could the team create.
After year 1 of focusing on creating value from the data products individually, Henrik and Scania started to focus more on creating value at the overall mesh level – this is where data product interoperability really can come into play.
Before you get going on a data mesh journey, Henrik recommends spending the time to really plan out how you think your implementation will work and how it will create value for the organization. And what will be the near-term value adders and what will be the longer-term value adders.
Henrik strongly believes in either taking challenges on with the intention to get to a good solution now or not tackling the challenge at all. The half-assed solutions just lead to far more pain so either commit to take it on or leave it entirely for later.
Another piece of advice is to not have the domain teams just hire without consulting the central team, especially if there is a central team around that competency. Look instead to embed people from the central team into your domains so they can understand the friction points to build out templates to address that friction.
For Henrik, it’s key to find the right people in each domain who can be a sensible buyer. There needs to be a high level of trust between the business and IT and so you need someone who can develop a strong relationship with IT.
For Henrik, you need to start from respect, empathy, and understanding for people in different roles in order to actually form a strong relationship. Business people often think it’s not that hard to set up your data and analytics processes well. You should focus on investing time and energy with the key players to develop a good relationship. That way, it is much easier to get to each other’s context.
Henrik wrapped up talking about to succeed in data mesh, you need to get to a place where you can have broad reusability. Reusable data, reusable processes, reusable templates, reusable tooling, etc. He also believes that domains, especially the business people inside the domains, need to understand they own the business processes AND the the data.
Henrik’s LinkedIn: https://www.linkedin.com/in/henrikgothberg/
Dairdux website: https://dairdux.com/
Airplane Alliance website: https://airplanealliance.com/
Data Mesh Radio is hosted by Scott Hirleman. If you want to connect with Scott, reach out to him at community at datameshlearning.com or 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 created by Lesfm (intro includes slight edits by Scott Hirleman): https://pixabay.com/users/lesfm-22579021/
Data Mesh Radio is brought to you as a community resource by DataStax. Check out their high-scale, multi-region database offering (w/ lots of great APIs) and use code DAAP500 for a free $500 credit (apply under “add payment”): AstraDB