Why Context Is the New Currency in Data Strategy with Chris Tabb of LEIT DATA

Chris Tabb, Co-Founder and Chief Commercial Officer of LEIT DATA, joins us to explore the friction framework for building data business cases, the context layer as an architecture for AI-ready data and why meta metadata represents the next frontier of enterprise data value.

‍

KEY TAKEAWAYS

‍

00:00 Introduction. 

02:50 Dashboards only create value when they drive a clear business decision. 

05:15 Data strategy is shifting from visualization back toward the quality of the underlying data. 

13:30 Business value is a positive evidence effect on business objectives, not a bottom-line metric. 15:10 Friction, measured by time, effort and frequency, is the foundation for a data business case. 17:00 Force multipliers solve a problem once and yield compounding returns across the organization. 22:10 Reading the annual report first will anchor any data project to the business's actual objectives. 26:30 The context layer unifies ontologies, knowledge graphs, semantic layers and vector databases under one concept. 

28:30 Scoring and tuning prompt context is how organizations get more accurate, consistent AI outputs. 

35:10 Meta metadata, data about the data about the data, is where enterprise value now lives.

‍

Thanks for listening to the “Data Masters Podcast.” If you enjoyed this episode, be sure to subscribe so you never miss our latest discussions and insights into the ever-changing world of data.

‍

RESOURCES MENTIONED

‍

LEIT DATA website:

https://leit-data.com/

‍

O'Reilly book by Joe Reis and Matt Housley [Fundamentals of Data Engineering]:

https://www.amazon.com/Fundamentals-Data-Engineering-Robust-Systems/dp/1098108302

‍

Anthony: Welcome back to Data Masters. Today I’m thrilled to be joined by Chris Tabb. Chris is the co-founder and chief commercial officer of LEIT DATA, one of EMEA’s fastest-growing data consultancies with an impressive 30 years of experience spanning BI, data architecture, and enterprise analytics. Chris has seen the evolution of our industry firsthand.

He [00:01:00] started his career at Cognos in the 1990s and has worked through almost every layer of the data ecosystem since. Beyond his strategic work driving business value and advising startups, he’s also a fellow podcaster hosting the Data Value Show, which I encourage everyone to go listen to. Today we’re going to dive into how our careers have shifted upstream from BI to raw data, why we need to rethink traditional ROI to build smarter business cases, and finally, we’re going to demystify the context layer — what it is and how it keeps organizations from falling into the chasm of inaccuracy. Chris, great to have you on the show.

Chris: Well, what an intro that was — being called a

Speaker 2: master to start

Chris: with, and then all the rest of it. I’ve even forgotten how much I’ve done over the years. Thank you very much for the intro, and it’s great to be [00:02:00] here. Shall we start at the beginning, really?

Anthony: Yeah. In a funny way, I think — as we were preparing for this — we both noted that we have, in that sense, similar career trajectories, having both started on the consumption side of the data. You started at Cognos, I started at Qlik. Let me relay a story, if you don’t mind. I just got back from the Gartner Data and Analytics Summit in Orlando. In the initial introduction that the Gartner analysts do on stage, at some point early in that presentation, they said something like, “Isn’t everybody sick of dashboards?” And the entire room erupted into applause and cheering.

It was just an absolute moment where I was like, oh my goodness. Where we started our careers — around helping people consume and use data more effectively — that era is [00:03:00] very much over, and everything has really shifted back in the value chain to the data that supplies those. So I’m curious: do you agree? Or are dashboards still relevant?

Chris: You just triggered a thought. I’d just make a note, because otherwise ideas pop in and out of my mind. A little while ago I did a take on what UI would look like in the future. I said UI is just going to be a prompt box — forget the dashboard and the rest of it. That will be our interaction with it. I was right on this occasionally — it happens occasionally. We did do a lot of work with ThoughtSpot back then, and that was their sort of tagline at the time: “dashboard is dead.” I think first you need to define what a dashboard is.

If a dashboard is a static bit of information from which no business decision is being made — yes, it is just a pretty picture, and it is no more than that. But if that [00:04:00] dashboard is driving business decisions and the business processes are being driven off those dashboards, then they’re not dead. So I think it’s how they’re being used. A prompt now can create your dashboard that you go and make the decision on. I think it was a bit of a marketing thing — anyone that’s put an AI front end on their original dashboard product. So yeah, I think it depends. Everything needs to be driving a business process or a decisioning process. Otherwise, yeah, it’s just a bit of nice chartage.

Anthony: No disagreement, but there’s a sort of second dimension to this. Maybe we could say that whether it’s a prompt interface or a dashboard interface, it’s kind of a solved problem. But what isn’t a solved problem is the underlying data [00:05:00] itself.

Chris: Oh, yeah, yeah.

Anthony: And I think part of what people were reacting to in that moment was this overemphasis on the visual presentation of the data and a lack of emphasis on the actual data itself. I’m curious if that resonates.

Chris: I just triggered another thought. I remember back in my BI developer days — I probably spent more time getting the legends in a particular format, or the colors on the charts and mapping them to what the user would want, than probably on the data preparation itself. I think that goes back to the point: we were delivering this for people who used to have PowerPoint charts, so they wanted to report in the format they were used to — which is the same problem we have with Excel, but that’s a slightly different story.

Yeah, so I think there was too much emphasis on how it [00:06:00] looked in the presentation rather than what we’re going to do with it, how accurate it is, and also: what’s the next question I’m going to ask when I look at that? “Oh, great — but why is that more? Why has that increased? What changes happened during that period? Why is the number of customers up 100% in the past two weeks? That couldn’t possibly be right. Oh, we did a migration.” Those sorts of questions — that iterative analysis of data — that’s where the value is. It’s not the first question you want to ask. It’s actually the fourth question you didn’t know you wanted to ask.

That is actually going to provide the value. Where we are now and where we’re going, we are able to give people the ability to ask these questions and get answers. But how much trust is there in that particular response? Everyone’s talking about AI hallucinating — why are they going to trust the information? And they’re [00:07:00] right to have some concerns. This is why you need to make sure it’s set up in a way where there’s no way of actually creating these mistakes, because you’ve already built all the business logic and usage of that data and context — maybe I shouldn’t use that word too early in this podcast.

Yeah, to make sure it is writing accurate SQL that you would’ve written yourself back in the day, and that it’s providing consistent answers — the same if another person in another department is asking a similar question of the same dataset. It will always correlate. You’re never going to get into that boardroom where someone says, “Our net revenue this month was this,” and someone else says, “No, it was this.”

Anthony: I used to have this thing I would say, because it would be very common for customers to complain about the quality of the data in their dashboard. And I would say, “No, no, you don’t need to worry about [00:08:00] that — sunlight is the best disinfectant. By putting the data in the dashboard, then people will be caused to go fix the data.” Which, admittedly looking back on it — a lie might be a bit strong, but it was an oversimplification, maybe a more generous way of saying it.

But I’m curious: as you’ve moved in your career and now find yourself on the advising side of the business, do you feel like that’s given you a kind of freedom to say different things to customers? Do you find yourself saying different things because you’re not beholden to…

Chris: So I think, going back to the career I’ve been on — and probably why I’ve stayed well, or people liked me, and I’ve worked with many of the same people over and over again — I say what I think and I say what I believe, rather than what they would want to hear. And I think [00:09:00] being a contractor: I’ve only ever had two permanent jobs — one at Cognos, one is the company I now employ myself in. Between those 20-odd years I was a guns-for-hire contractor. I went there because I wanted to deliver the best approach and the best solution. I had no ulterior objective, no career path to protect, and if you didn’t like it, I’d go somewhere else, because I knew I could. I had the confidence knowing I wouldn’t be short of work, based on my experience.

And again, being in your own company — I have a chairman who makes sure I do the right thing, I have a CFO who makes sure I do the right thing. But from an advisory standpoint to a client — I do like sales, but part of my pitch is: [00:10:00] I’m an architect first and a salesperson second. I can only sell you something I believe in. That’s the approach I’ve taken, and it’s recognized — that advice is taken seriously because it’s not driven by any ulterior motives. Obviously I need to make money, but I think giving the right advice actually aids that rather than not.

The other thing to mention: I’m probably more hands-on than I’ve been in many years now with regard to building stuff. I’m doing R&D, building up frameworks, I’ve built my prompt engines for internal optimization. The learning I take from that I give back to clients — I say, look, I’ve built a system of context. There’s that word again. On top of all my systems of record, it’s able to be my [00:11:00] one portal where I can see anything going on in the business, and it’s driven by AI, in the right places. Using the right tool for the right job is also very important.

Anthony: So, speaking of tools — and I know you host an entire podcast on this — I did want to touch on this question of business value and ROI. I do feel like you are a kind of world expert in this area. I also think this is arguably one of the most challenging pieces of the software space when it comes to data and analytics software. Building the business case — a large proportion of the sales process, the prospect engagement process, is helping data teams [00:12:00] build that case almost internally. They’re bought in, but they don’t know how to speak the language of business to get the business side to buy into it. Maybe share a little bit on your framework around this.

Chris: Yeah.

Anthony: How do you think about this?

Chris: So I’ll tell you a story about ROI — what ROI is and why it always annoyed me. I was working at a FinTech company — head of architecture or something — and the marketing department’s CMO and I both went in with our presentations. The CMO was putting up a proposal for Salesforce, claiming 50x value in customer retention and all these things. I went in with my proposal, which wasn’t asking for anywhere near as much money as Salesforce needed, but I was [00:13:00] evidencing a modest but valuable return that would’ve actually unlocked other things later. It was foundational — it would’ve paid for itself and a little bit more, but then you could actually execute on use cases three, four, and five. Anyway, I lost. I didn’t get anything. And I was there long enough to see the Salesforce project fail miserably, cost a lot of money, and return no value.

And if they’d hedged a bet and just given me a bit of chump change, I think they would’ve been in a better place. I didn’t go full smug mode until toga [see Flagged], but I think they all knew.

So let’s step forward to the term “business value.” About three years ago I started using it. We mentioned Joe Reese and Matt Housie, who did a book called fundamental Engineering on O’Reilly — a very good book. You’ll see my name at the beginning; I did a foreword on it. Anyway, I’d been talking to them, and Matt and I were going on a journey — we were going to try and do a book on it. We never actually made it, but we did a lot of thinking. We were hung up on just the definition of business value for a long, [00:14:00] long time.

The thing we both agreed on in the end — after a lot of debates with other people over a few beers over a few months — was that it was a positive evidential effect on your business objectives. So it was never about the bottom line, because it’s not always about the bottom line. It may be so on the second degree, but maybe not directly. The reason I say that: Uber never made a profit for 10 years. Was the objective of anything they did to actually adjust the bottom line? This year? No. Next year? No. They were hoping maybe by year three or four, but it wasn’t the case. The value there is customer retention — acquiring new areas — not actually about making additional profit or improving the bottom line at that point. And there could be some environmental thing you want to do, like making sure you’re carbon neutral — [00:15:00] again, not directly making money, but it passes your business objectives as agreed with your shareholders.

So that’s when we got to: what is business value? Since then I’ve taken this — and we’re using it now with a few clients — to the next level: how do you provide business value to a client in an evident way? The approach we take is the friction approach. You’ve got — and you could include a third, but let’s keep it simple for now — two types: business friction and delivery friction.

What is friction? Friction is the time, complexity, and effort to perform an activity, compounded by frequency — how often that thing happens. If you’re able to look at the business processes — and this could be via a combination of interviews, log mining, UI flow analysis, and multiple mechanisms to get the metadata-associated information — [00:16:00] you start to understand where there is business friction, where there is optimization that could happen, or processes bouncing back and forth between two teams that could be solved with something simple. That’s your business friction.

Then your delivery friction is: how long does it take you to get something into production? Engineers love engineering things. They look at their backlog and go, “Oh, look, I’ve written it all in a scripting language. Now I need this bit of infrastructure, and it’s automated — brilliant!” How often do you have to do that? Well, every three months, maybe. How long does it take? Half a day, a day. So what’s the full cost? What’s in the background? There is no value in that. That is a vanity project — an engineering-driven project not quantifiably [00:17:00] linked to business value.

The other part I now add to this is what I refer to as the force multiplier. A force multiplier is something that is reusable — it becomes a reusable asset — or the amount of effort you put in relative to the value you get is disproportionately favorable. I called it the Millennium Fulcrum. You know, if you move the fulcrum — and you move that with automation — the effort you put in here is a lot less to lift the load on the other side.

So by identifying where in the business world or in the delivery world these force multipliers are — you solve it once, or the effort you need next time gets you the same or greater return — you can now plot a [00:18:00] business value roadmap that is iterative. If you look at these things and work out: yes, there’s a lot of value in this, but it’s really hard to do — now I’ve got all the information needed to start having the right discussions with the right people in the business, taking out emotion and vanity projects, and saying, “Let’s do things in the right order. Yes, you get to build your nice fancy framework — we need that in year two, because by then we’ll need it when we want to spin up more of these things quicker because we’re opening up another product line. We don’t need it now.”

So business value — we actually have the force multiplier discussion anyway. If you get all the right information and package it up, internally we also have a platform blueprint, which links onto the context layer in a minute. That platform blueprint is a technology-agnostic [00:19:00] functional domain component platform, and it will show you everything you may need at some point, but you may not need it all today. We’ve got some knowledge engineering done in there — we know which components are grouped together and could be solved by a particular product. If you go with that product, you’ve covered multiple pieces of it, but you’re not saying, “I’m building a Snowflake with a Sigma and a Tamr in it” — what you’re actually doing is a bit of data quality, a data app, and a data catalog. Wrong. We’ve always been making that same mistake — describing the technology rather than the functionality — and that makes it very hard to swap things out later because there’s no abstraction.

So using our blueprint and the frameworks we have underneath, with best practices for each, we can, [00:20:00] with a little bit of effort working with a client, provide them something that’s driven by what they need, not driven by a technology roadmap being implemented on them, and doing things in the right order that keeps the stakeholders happy on that journey. Because you’re not going to keep them all happy all the time — you’ve got to keep the right people happy at the right time and eventually get to everyone at some point.

# SPONSOR PLUG

[00:21:00]

Anthony: One of the big ideas I took away from the Gartner Show last week in Orlando — one of the Gartner analysts made the point that every data project should start with the team reading their annual report. What would that have to do with it? But his point — and it speaks exactly to what you’re talking about — is: if you don’t understand the business objectives of the business, then whatever technology, whatever data project you’re working on, is likely to be a technology project and not a business project.

Chris: Spot on. Whenever I’m going in to pitch for a data strategy piece, the first place I go is their last board report or anything publicly available. I’ve actually built that into our knowledge platform internally — we have all that research done on a company before we’re even talking to them. [00:22:00] So before I’m talking to them, I’ve already got the background on what’s going on with them, so I have all the content I need when I have the conversation.

Anthony: And I also really love this idea of friction. I think that is a really unique insight. Just to play it back to you — one idea that’s really important is that there are almost certainly lots of pain points inside an organization, lots of points of friction. But friction in something that’s not actually moving very quickly — to your point, something that happens every three months — even if it’s very painful every three months, it’s only every three months. Whereas something that’s happening six times a day, even if it’s not that much friction individually, there’d be a huge heat buildup because it’s just constant.

Chris: Yeah. You either have to throw more oil at it — which means more people to try and smooth the process — or you reduce that friction by putting something in there that solves the problem.

Anthony: So in your [00:23:00] view — I like this idea of the force multiplier — is that typically human-led, meaning the force multiplier is people, or is the force multiplier technology?

Chris: I think it could be any of them. Let’s take the people route: it could be that at the moment you’ve got three people doing a particular activity as a part-time job, and the value they have doing other things is more valuable. It can be solved by just putting one dedicated person in that role who serves those other three. You’ve just solved it as a people problem. It can be as simple as that — just more efficiency with the staff you’ve got, or better structure of your teams.

The next one — it could be the deployment framework. Normally you’ve got someone running a script here, doing that, and someone else doing the testing. Now [00:24:00] you’ve built an end-to-end testing framework that runs it and sends a Slack message with the results saying, “Done.” You’ve probably done two things: you’ve saved them some time, and you’ve also built more trust in the process because it’s less likely to fail. And once you’ve solved that process for one department, you’ve now got a force multiplier — every other department doing the same thing can now benefit from it. You’ve solved it once and got more benefit from it.

And I think the business process one is: for example, you’ve got master data scattered all over the place — which is your area, but you know what I mean — and having that now centralized in one place means the information is more accurate, you’re not paying for multiple systems doing the same thing, and you’ve got it in a more timely manner. So it becomes that. How you’d identify that is through your process of analysis — looking [00:25:00] for areas of friction. You’d have identified that three departments are all using separate systems: one’s got Salesforce, one’s got HubSpot. At some point it may make sense to centralize into one CRM, but maybe not. So maybe there’s an opportunity to say, “I can’t get rid of all of you, but for now I’m going to master this in one location as the golden source.” Anyone who needs the latest thing on that — everything feeds via that hub now. And you’ve gone and solved that for your billing, finance, and marketing departments, which are now not sending marketing material to people who haven’t paid their bills. There’s no point trying to market to people who can’t buy in the first place.

Anthony: That’s a good transition to context layers, which — if there was a third theme that came out of the Gartner Show — it was the buzzword “context layer,” which [00:26:00] we’ll give you credit for, as you’ve been talking about it for some time. I don’t know if you can quite claim to have invented it, but you should claim to have

Chris: invented it. I did a bit of Perplexity research to find out who was the first person to talk about it, and it kept me happy — it couldn’t find other people talking about it before me. But I’ll tell you where I originally coined it and why. It wasn’t to invent a buzzword. It’s linked to the good old days of BI. In Cognos you had a catalog; in Business Objects you had a Universe. They were a semantic layer — a bundled semantic layer with a BI product. I didn’t know it was a semantic layer back then. All I knew was a catalog where I was describing my data, and I just did it.

It’s interesting to see the evolution to where we are now. We were talking about Semantic 2.0, and there’s a whole list of things I’d say are context-related: ontologies, knowledge graphs, vector databases, [00:27:00] semantic layers, and Semantic 2.0. People were arguing, but I said: look, what are they all providing? They’re providing context — collectively, they are a context layer. And going back to that group in our reference architecture — I know how long it’s been there because I haven’t updated that part for over a year — it has this thing called a context layer. The purpose of that was to describe to the business what capabilities are involved. It wasn’t a product, it wasn’t a solution — it was a concept. It was trying to say: all these things you’re hearing about are part of the jigsaw puzzle of providing you the context needed for your use cases. But you don’t need all of them at once, and you probably won’t need all of them at all. It’s working out what you need at the right time.

Then I put in there something I call context management. I’ve done this in my prompt engine. [00:28:00] My prompts are scored afterwards, and they also score the context they’ve been given. It gives feedback if it believes the context is the reason for a poor result from the prompt, so that hierarchically it will tune itself — saying what additional context would be needed to avoid that. You need to manage context, and context will mean different things to different people. Context also has a lifespan. People really need to unpack what they actually need in terms of context.

If context simply means you’ve now stored all your additional metadata on your DDL with comments, tags, foreign key and primary key constraints, or naming conventions — you’ve built context into that by design. You’re able to read that and [00:29:00] extract knowledge from it, and it will always be kept up to date. So you don’t need to maintain another catalog. If your business processes are captured and you’ve got some naming convention, and you put those business processes into your data model that you may have somewhere — you’ve actually already created all that metadata. Let’s provide new context. You don’t need to buy a product or do anything else. You just need to put that somewhere and be able to use it. Stick an agent on it as an example, and it will work out what it can do with all of that context you’ve provided.

Then you just need to make sure that context is available for the purpose you’ve got. It could be going to a prompt — making sure you’re giving the right context to the prompt. It could be, [00:30:00] as we’re talking about, the prompt box for reporting. Now you need to make sure — using the example I gave earlier — we’ve just done a migration, right, and by the way, here’s a history of activities that have gone on recently. Or there was an outage in this region at that time. Those things — if you can get that context somewhere — are going to be useful for someone doing reporting. Just getting that into a place where, when your analysis is being performed, it also has access to that additional context. You’re just providing additional value and additional trust in that data, because as soon as they see something wrong: “Oh, I know why it’s wrong” — or better yet, it knows why it’s wrong.

Anthony: One thing I just want to go back on: you made this point that this is something we’ve had as an industry for a long time, and in that sense, in our consumer lives, we’re quite comfortable with it. We often talk about what Google has — a lot of context. A lot of what [00:31:00] Google was trying to do in making search better was learn or figure out context. Sometimes it gets creepy in our personal world — but leaving that aside — would it be fair to say that we could learn a lot from the way our experience with consumer software informs the way we need to make these enterprise systems successful, especially in the context of context?

Chris: I’m going to answer this, but something else we didn’t talk about recently is a system of record. You’ve seen recently Salesforce’s price crash, HubSpot’s crash — and it’s something I’ve noticed as well — and that was based on the behavior of businesses now. Whereas before, that system of record was the go-to place that everything was driven from, now it’s not. They were taking that information out of Salesforce and performing the analysis outside of it, which meant [00:32:00] maybe the number of licenses they needed before — because people could go and self-serve on this data — is now lower. I know that Sigma is doing this; they’ve got an app on top of that. You can’t take that data in real time, but you can take it in batch.

So that’s sort of a shift from where we were before — systems of record being the great golden pillars of an organization. And you may have seen that Salesforce has recently changed their licensing agreement so that you cannot train AI on your data in their platform. I’m not sure how they’re implementing it, but it just shows that they realize context is where the money is — and if they lose that context, if it’s being taken outside the platform, they’re losing their value.

Anthony: Yeah.

Chris: Did I answer your question?

Anthony: Yes, exactly. And I think [00:33:00] this goes to a theory I’ve had for many years, which is that what happens in enterprise software is what happened in consumer software five years ago.

Chris: Yes.

Anthony: And to your point about operational systems — where I think a lot of organizations saw value in these operational systems — they’re increasingly seeing value in the linkages between those operational systems, and not so much in — I’ll say this in a funny way — there used to be this idea that eventually all the data will end up in SAP, Salesforce, or whatever your system of choice is. And I think there’s this increasing realization that that’s never going to happen — the data is just not going to end up in one place.

Chris: Yeah. Which I think is where — the system of context, as I coined it (well, Gartner will talk about this next year, and you can say you heard it here first) — the system of context is stringing together all of those different [00:34:00] parts of your organization. It’s much easier to bring it all together now than it’s ever been, though it’s always been there — it’s just been very difficult to do. Before, data platforms were always seen as downstream, never as an operational thing. Now that’s shifted.

If your data platform feeds your operational processes and all the systems of record are feeding into it, the system of context sits on top of it because it understands everything, because everything is going into it. The sum of all the parts is worth more than the individual pieces — and the data world has got that now, whereas the Salesforces of the world are all trying to get everything into their platform.

Anthony: Which brings us back to where we started: the value is no longer in this very specific, bespoke user interface — a dashboard or, for that matter, a CRM system — but in the data behind it, and in fact [00:35:00] in the context that data provides, whether it provides that context to humans or to AI systems.

Chris: I coined something else a few years ago, which is meta metadata — data about the data, about the data — that’s where the value is now. And that links into providing additional context. People tried to do this years ago — you’d take your ETL metadata, your database metadata — but it was difficult. Now you go and stick some agents on top of that and it can work it out quite quickly. You can get some really valuable insight from it. We’re doing that — not really everything, but that’s something else we’re doing elsewhere.

Anthony: Well, look, I think we’ve covered a lot of ground — the transformation in the data space away from how we visualize data to the actual data itself, how we can use a different concept [00:36:00] than ROI and instead think about friction as a motivating factor, and really introducing this idea of the context layer, which arguably is where we’re going as an industry. Chris, thank you so much for your time.

Chris: No, thank you for listening. I’ve got a lot to talk on this stuff.

‍

‍