“However, new clients unaccustomed to his methods said that Drucker’s consulting was frustrating at first.[…]. Drucker on the other hand asked many questions but refused to answer ones about what to do, saying that this was not his job. Yet the questions he asked his clients led them to come up with solutions, which repeatedly led to success, and they usually hired him again.”

(Taken from Peter Druckers very different consulting model, but “Peter Drucker on Consulting” tells the same story)

Peter Drucker had a consulting model which I admire because it had three components I value. 

One, it forced the companies to think through their own problems, which they are best positioned to do anyways. 

Second, it was designed to NOT complicate for profit; In fact, if the client has to think through the solution himself, the consultant actually is incentivized to make things as simple as possible. Even though, as quoted above, this can still be frustrating. 

Third, Drucker focused as I understand it on empirical, visible facts, as well as on thinking to the roots of a situation. Again something I learned to value a lot through my scientific upbringing.

With that in mind, I started to ask a few questions myself, when I talk to someone about data meshes, as well as when considering building one of my own.

The questioning lines below ask for exactly that, the deep reason for building a data mesh & the alignment with company strategy. The reason behind building a platform and the visible current interactions in terms of data of teams overall.

Question 1: Why do you want to build a data mesh?

Why do you want to build a data mesh? …. How does that link to your data strategy? …. How does that link to your company strategy?

The intent behind this line of question is simple. It is to get to the ground of the efforts, the pains, and the gains that your company sees in shifting to a data mesh. 

When you chose to break down your (probably still existing) legacy monolith into smaller microservices, you chose to gain much more flexibility at the cost of adding complexity.

If you choose to build a data mesh, you’re choosing the same thing. Added complexity for the sake of large flexibility in your data products.

That’s only worth it if you have a data strategy that is directly derived from your company strategy that is focused on extracting value from data in any way. 

(For details on that alignment, read my article on Good Data vs Bad Data)

Question 2: Why do you want to build a self-serve data platform?

Why do you want to build a platform? … Is the collected benefit greater than the expected value? … What is the end benefit to the users of the platform? … What would the alternative look like? … How do the costs & values compare on both sides?

The intent behind that is again simple, platforms have a bad rep for being complicated to use, and not adding any benefit. Part of that is true, platforms for some reason suck their designers into a larger than necessary architecture at the cost of, ironically, flexibility in the individual parts.

Ask yourself what would happen, if your data platform would consist only of a wiki page – telling people in which storage system to place data? Who would make use of that? Why not? Then slowly increase the size and keep asking the same question while watching the cost explode.

Question 3: How did your development teams work with data before?

How did your machine learners access their data? … What happened when they talked to development teams? … Do product managers ask about ways to provide data? … Are product managers responsible for providing data with their products?

This line of questioning is targeted at the underlying behavior of your teams. Why? Because interactions are really tough to design for, they usually involve a lot of emergent behavior. Things you cannot foresee.

If you don’t already have working ways of interaction between data consuming and data producing teams, you will likely not be able to design a proper platform to use, because you cannot foresee the emergent behavior. If you design a platform, you’ll likely end up redesigning it again and again. The best approach might simply be to take what already works, make it easier, and scale it up.

So now what?

I suggest you go and do some deep digging. Ask yourself all these things, if you do not feel happy with any of the answers, I would recommend not building a data mesh, but focusing on the underlying problems. If you solve the underlying issues, a data mesh might emerge on its own.

Or it might not. Because you don’t need one, you might be better off without it, because your company strategy actually has a different direction.

There of course is also an argument that would say “if you don’t show people how to build data products, they will never do that on their own”. I simply don’t buy that, based on my experience.