#209 Panel: What is BI's Place in Data Mesh - Led by Ammara Gafoor w/ Elif Tutuk and Ryan Dolley

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.

Ammara's LinkedIn: https://www.linkedin.com/in/ammara-gafoor/

Ammara's Articles on data mesh Part 1: https://www.thoughtworks.com/insights/articles/data-mesh-in-practice-getting-off-to-the-right-start

Part 2: https://www.thoughtworks.com/insights/articles/data-mesh-in-practice-organizational-operating-model

Part 3: https://www.thoughtworks.com/insights/articles/data-mesh-in-practice-product-thinking-and-development

Elif's LinkedIn: https://www.linkedin.com/in/elift/

AtScale article on data mesh: Principles of data mesh and how semantic layer brings it to life: https://www.atscale.com/resource/data-mesh-principles-semantic-layer/

General AtScale article: The Semantic Layer’s Critical Roles in Modern Data Architectures: https://www.atscale.com/resource/the-semantic-layers-critical-roles-in-modern-data-architectures/

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

Super Data Bros Blog: https://superdatablog.substack.com/

Super Data Bros YouTube: https://www.youtube.com/@superdatabros

In this episode, guest host Ammara Gafoor, Principal Business Analyst at Thoughtworks (guest of episode #133) facilitated a discussion with Elif Tutuk, Global Head of Product at AtScale, and Ryan Dolley, Independent Data Consultant and one of the SuperDataBros (guest of episode #183). The focus topic area was what role does Business Intelligence (BI) have in data mesh - e.g. where does it sit and who owns it - and how do we enable BI to really drive significant value in a data mesh implementation.

A few other episodes that would be good to get a broader picture here on related topics in addition to Ammara and Ryan's episodes are #199 with Brent Dykes and #192 with João Sousa.

Scott note: I wanted to share my takeaways rather than trying to reflect the nuance of the panelists' views. This will be the standard for panels going forward.

Scott's Top Takeaways:

It's really important to actually define what business intelligence even means to your organization. If everyone doesn't have a clearly defined picture, it's one of the easiest things to have a major mismatch on expectations - everyone thinks they know what we mean by BI but we often mean different, sometimes vastly different, things.
In data mesh, it's okay to have multiple org groups/layers of BI across the org - say BI teams embedded in the domains and a central BI team too - as long as responsibilities are relatively clear and teams _communicate_. If everyone is working on similar or overlapping goals, it's going to create BI sprawl - e.g. dashboard and report sprawl with weak ownership.
BI must focus on enabling business users, not just data analysts. How do we make it so regular business users can actually drive their own analysis and then own the output? How can they then share their insights back to others.
It's important to focus on enabling BI capabilities over tooling. In BI that feels especially hard because the interface to the data for most people is literally the tools themselves so of course tools feel like they are most important. How we make that distinction, especially to users, is hard and seems to be to-be-determined.
Really consider if BI is only a consumer or, more likely, is it also a crucial producer to the mesh. Are data analysis outputs going to be made available in something like an analytics catalog? Whether you call that part of the mesh or not, how are people reliably sharing the insights they create and how are others discovering those?
Ammara brought up the complexities of how do we go from providing raw data in these fundamental data products to actually doing BI - the tools are not designed to ingest from many sources and the BI professionals are typically not super technical. Do we create domain data marts or mesh aggregated data products? I like the recipe angle Mahmoud Yassin mentioned in episode #103. Data virtualization technologies also probably play a key role here.
Elif made a good point about there is a difference between making the data analytics ready and business ready. How do we bridge that gap? How do we even define that gap so we can recognize it before addressing it?
Design thinking and product are truly crucial to doing BI right, whether data mesh or not. For too long, all aspects of data but especially BI have been focused on outputs - kind of like # of widgets produced - as the metric. It can feel like accomplishing something even if it's not creating value. We need to focus much more on how people will use what we build to drive specific value. How do we create "delightful experiences" as Zhamak always says for consumers of business intelligence.

Other Important Takeaways (many touch on similar points from different aspects):

BI is about "translating the things that happen in the business … into the format that's going to enable people to make informed decisions on it…" as Ryan said. It's easy to get bogged down in tools and techniques but at the end of the day, we're trying to provide intelligence to make better decisions, that enables people to understand and take reasonable actions.
Data mesh gives us a chance to reinvent how we produce BI dashboards and reports. Instead of creating single tables to support each dashboard, we can easily source reliable data without creating rigid and quickly deteriorating or abandoned data assets.
Balancing user experience - especially letting users use their tools of choice - and reliability/scalability is very hard in BI. How do you track lineage into Excel? How do you _govern_ data that's been put into Excel? But if you try to get everyone into Power BI, will you have user disengagement? Scott note: you won't even be able to pry Excel from my dead hands. It's not for reporting but it's the best data poking tool around for small to moderate data sets
We need to start to think about how our mesh data products interface with business users. At the mesh experience plane level, how can they have what Zhamak calls in her book "a delightful experience"? In general in data, we often overlook the rank and file users to focus on the highly technical ones - those are more 'our people' - but we will miss out on a ton of business value if we do that with data mesh.
Is a centralized BI team a mesh anti-pattern? I agree with Ammara and her colleague Emily Gorcenski: nope! You need someone really focused on generating and owning cross-domain use cases or we focus on preventing data silos for nothing. If we don't actually combine the data across the domains, what's the point of data mesh?! Just make sure to share information with other BI teams to prevent knowledge silos.
There is a lot of focus on who sits where and exactly how things interact, which is important in some respects. But it's more important to focus on what are we trying to actually accomplish and then who owns that. Clear responsibilities win, the org chart doesn't! :)
Governance is a key enabler in BI. Not just defining who does what but creating common and easy to leverage interfaces to our data. That can't be done individually for each data product - it would be a ton of work on data producers and consumers would have an awful time. So you have to consider how far does the mesh experience plane extend. Is it into BI or not? If not, how do we achieve scale if business consumers have a disjointed experience and can't easily share with each other.
Mesh consumer-aligned data product owners need to consider if BI users are a target consumer. What output ports are you creating to make it easy for BI users to leverage your data product?
How do we think about the semantics and metrics layers relative to BI in data mesh? BI users want to be able to trust data without deep-diving into transformations and lineage. How do we make that simple and easy? I really don't have good answers here.
Zhamak has talked about her disdain for layers specifically for data in a data product and the large-scale data pipeline approach. I don't believe this extends to the concepts of a semantics layer or a metrics layer if you use this as something data products need to produce their metadata into. It's another aspect powering data discoverability. It's kind of a complicated analogy for how this might work and I am working on the wording…
Governance has to be focused on enabling BI usage of data more than restricting. Of course, controlling who has access and what people can do with it is crucial but with mesh, if we are so focused on producing great quality data across the org, we have to think about how we can enable usage at scale. That's table stakes for data mesh.
We need to create good and low friction ways for people to go from generating an insight to sharing that insight. It's often that insights get locked in at the BI layer. How do we share those insights back to others on the mesh to leverage? Can we easily push insights into the mesh to create a new data product? This is a cultural AND a technology issue that needs to be addressed.
In BI, there is often too much of a bias towards 'give me the complete picture and I'll go from there' which leads to complicated and non-effective customer 360 approaches. Just sourcing a bunch of data without a specific business objective. Humans are curious creatures! Do we need to focus on what information are you trying to understand and why first rather than produce all this data and I _might_ have an interesting insight? I think yes.
One thing that _feels_ like it is often missing from a BI strategy is bringing the business knowledge to the data instead of only bringing the data to business users. How to actually go about bringing the business knowledge to the data, I have no idea. Maybe this is the consumer-driven data modeling and feedback involved in data product creation but it feels deeper than that. It's a concept that is brewing in my mind…
Do we want to have some org-wide defined metrics? Taxonomies and ontologies can easily become overly rigid but having optional adherence can make things much easier when you think about standardized metrics and meanings. It's all a balance and it feels like you should be constantly assessing it because it can easily go the route of too many metrics and your mesh becomes littered with metrics that all mean slightly different things.
BI people are likely to be skeptical of data mesh. Trying to get access to tons of systems and cross-correlate and consume data from multiple sources has historically been a pain - probably an insane pain to be honest. Be ready for pushback even if this is a better solution in the long-run - and likely short-run - for them. Show them how BI in data mesh can be better, that their focus is on value.
We need to get BI people on board with data mesh and what it offers and how it will be better for them in the long-run. BI people are often the data gateways to execs. If the BI people aren't on board, are your executives going to see the benefit of data mesh? Not just buy-in wise but are they literally going to see an improvement in their business operations from data work if the BI people aren't leveraging it?
In general, we need to get better at translating the business need into the BI need then into the data need. Data work is often not as valuable as expected because it gets divorced from what people actually care about. Far easier said than done of course but think about user experience more relative to the entire data consumption and analysis / BI process.
Churning out reports and dashboards is not a good end-consumer user experience. What do business users get out of it to drive their business? We need to tie more BI work directly to what would drive change, what would drive action if we found out new information. We can start by just looking at who is using reports/dashboards before getting more complicated.
Product thinking in BI isn't just about the consumer experience, we need consumers to be part of the conversation and giving more feedback on usage and importance of the BI work. Instead of just having information pushed at them, it needs to be a collaborative push/pull.
Ammara asked about data mesh and BI teams: "…how does data mesh not add to the complexity? How do we not add more strain to the teams? … How do we not add to more to their cognitive load?" How do we make BI feasible in data mesh? It's not as obvious of an answer as it feels initially. We want to get more value leverage, not more work, from the teams.
Data virtualization might be a key aspect of doing BI well. Ghada Richani (episode #206) raved about what data virtualization has allowed them to do as well because it's crucial to easily be able to ingest data you are supposed to have access to. And many tools aren't designed to take data from lots of sources. I have lots of places where I am seeing data virtualization misused but this one seems safe :)
Some people are better served by feeding them reports and dashboards than giving them advanced self-serve analytics capabilities. Do we need to level them up? Do we want to move past "first wave" type practices? I honestly don't know. Some people like to cling to ways of the past but it might also be serving them well. If it's scalable and reliable, do we need to push to 'modernize'? Probably? A bigger BI question than just data mesh related :)

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