Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Android | Youtube Music | RSS
In every enterprise, says Ole Olesen-Bagneux, the information you need to understand your organization’s metadata is already there. It just needs to be discovered and documented.
Ole’s Meta Grid can be as simple as a shared, curated collection of documents, diagrams, and data but might also be expressed as a knowledge graph.
Ole appreciates “North Star” architectures like microservices and the Data Mesh but presents the Meta Grid as a simpler way to manage enterprise metadata.
We talked about:
- his work as Chief Evangelist at Actian
- his forthcoming book, “Fundamentals of Metadata Management”
- how he defines his Meta Grid: an integration architecture that connects metadata across metadata repositories
- his definition of metadata and its key characteristic, that it’s always in two places at once
- how the Meta Grid compares with microservices architectures and organizing concepts like Data Mesh
- the nature of the Meta Grid as a small, simple, and slow architecture which is not technically difficult to achieve
- his assertion that you can’t build a Meta Grid because it already exists in every organization
- the elements of the Meta Grid: documents, diagrams or pictures, and examples of data
- how knowledge graphs fit into the Meta Grid
- his appreciation for “North Star” architectures like Data Mesh but also how he sees the Meta Grid as a more pragmatic approach to enterprise metadata management
- the evolution of his new book from a knowledge graph book to
- his elaboration on the “slow” nature of the Meta Grid, in particular how its metadata focus contrasts with faster real-time systems like ERPs
- the shape of the team topology that makes Meta Grid work
Ole’s bio
Ole Olesen-Bagneux is a globally recognized thought leader in metadata management and enterprise data architecture. As VP, Chief Evangelist at Actian, he drives industry awareness and adoption of modern approaches to data intelligence, drawing on his extensive expertise in data management, metadata, data catalogs, and decentralized architectures. An accomplished author, Ole has written The Enterprise Data Catalog (O’Reilly, 2023). He is currently working on Fundamentals of Metadata Management (O’Reilly, 2025), introducing a novel metadata architecture known as the Meta Grid. With a PhD in Library and Information Science from the University of Copenhagen, his unique perspective bridges traditional information science with modern data management.
Before joining Actian, Ole served as Chief Evangelist at Zeenea, where he played a key role in shaping and communicating the company’s technology vision. His industry experience includes leadership roles in enterprise architecture and data strategy at major pharmaceutical companies like Novo Nordisk.Ole is passionate about scalable metadata architectures, knowledge graphs, and enabling organizations to make data truly discoverable and usable.
Connect with Ole online
Resources mentioned in this interview
- Fundamentals of Metadata Management, Ole’s forthcoming book
- Data Management at Scale by Piethein Strengholt
- Fundamentals of Data Engineering by Joe Reis and Matt Housley
- Meta Grid as a Team Topology, Substack article
- Stewart Brand’s Pace Layers
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 28. Every modern enterprise wrestles with the scale, the complexity, and the urgency of understanding their data and metadata. So, by necessity, comprehensive architectural approaches like microservices and the data mesh are complex, big, and fast. Ole Olesen-Bagneux proposes a simple, small, and slow way for enterprises to cultivate a shared understanding of their enterprise knowledge, a decentralized approach to metadata strategy that he calls the Meta Grid.
Interview transcript
Larry:
Hi, everyone. Welcome to episode number 28 of the Knowledge Graph Insights podcast. I am really delighted today to welcome to the show Ole Olesen-Bagneux. Ole is the… He’s currently the chief evangelist at Actian. Welcome, Ole. Tell the folks a little bit more about your role at Actian and what you do there.
Ole:
Thank you, Larry. Thank you for having me on. This is a great topic that we will dive in today. First of all, I recently joined Actian, so it’s been my first week since we’ve recorded this. I am the chief evangelist in Actian, so I will be telling the story of Actian as this technology evolves. Actian is a data platform, it’s based in the US and it is part of the HCL software family. Actian is a data platform, and as this data platform changes and evolves over time, I’ll be telling that story. That’s really what I’ll be doing.
Larry:
What a fun job, evangelizing a technology platform. Yeah. I love that kind of work. You’re also working on a book called Fundamentals of Metadata Management, which is all about the Meta Grid concept that you came up with, and that’s what I really want to talk about today. How’s the book going? It’s due for publication this year, correct?
Ole:
That is correct. I finalized the first draft version of the manuscript a couple of weeks ago. I am very confident that I will publish it on time. Maybe a little earlier than the current publication date, that I don’t know, but it’s coming along nicely. It’s been a difficult book to write. It’s the sum of my experience as a leader and an enterprise architect working closely with all things data for the last 10, 15 years. 10 years.
Larry:
Nice. Sort of a encapsulation. Well, it’s an intriguing idea, and I love the… We were talking before we went on the air about how much I love a good framework, and is that the right way to think about it? I guess, how would you define the Meta Grid?
Ole:
The Meta Grid, as I see it, is first and foremost an architecture, an integration architecture between distinct types of technologies that do not perform the value chain of a company such as ERP systems and CRM systems and what have you. Neither is it focused at the analytical plane, so to say, the data mesh universe where you’re trying to discuss how centralized or decentralized should your analytical data technologies be at data warehouses, data lakes, and the like. The Meta Grid really is about these small, small technologies that depict the IT landscape, the information security management system, the data catalog, the endpoint management system, the knowledge management system, all these systems that for distinct purposes depict the IT landscape. A short definition of the Meta Grid is that it is an integration architecture that connects metadata across metadata repositories.
Larry:
Nice. That connects across repositories, and that’s one of the key things about the Meta Grid is that your conception of metadata differs… Well, you come out of a library science background, isn’t that right?
Ole:
That is right.
Larry:
I’ve learned most of what I know about metadata from my librarian friends, but I’ve also… I think I’ve fallen into the not trap or a different way of thinking about it than you do this notion of just thinking about the kinds of metadata, descriptive metadata, administrative, tech, all those kinds. You have a different take on metadata. I’d love to hear how you think of it?
Ole:
You bet. Yes. Well, first of all, let me emphasize that I don’t think the way you think of metadata is wrong. That’s quite important for me. But what I see lacking in that thinking, for example, in the Data Management Body of Knowledge, the DAMA-DMBOK or other resources, vital resources in this field is that if you do that subcategorization of metadata into operational, technical, business, social, what have you, then you discuss subcategories instead of the actual nature of metadata. What I’ve come to find in my work life is that this perspective gives you some blind spots to something that is very, very important in metadata. How I define metadata is not in terms of its subcategories. I don’t think you can do that actually for metadata. I try to find the very nature of metadata in my definition of it, and that is that it is not anything in particular, but that it is always in two places at once.
Ole:
That’s the key to metadata. It’ll be in a repository and it will be at source, just like a book has its information, its metadata in the book itself and on Amazon. Just like the data in a data catalog is listed in the data catalog and in the data sources of that particularly data source that you have scanned. Metadata is in two places at once, and that definition unfolds the idea of the Meta Grid because once you have established this definition, you can also look at this definition as a problem because what it creates, and you can see that at every single company in the world, is that you have a lot of different metadata repositories listing the same type of metadata. That’s the problem that the Meta Grid addresses, that all these small activities in all these small teams are taking place in isolation.
Larry:
Is that the classic silo issue in enterprise architectures?
Ole:
It’s definitely the classic silo issue in enterprise architecture just for a very distinct purpose. I feel very, very connected to everything, team topologies, everything data mesh, microservices. These ideas of thinking of how to break up monolithic thinking and monolithic technology practices is something that is very, very close to… Well, to my heart and my mind.
Larry:
That close to mine as well. I help organize a conference called Decoupled Days, it’s all about microservices and decoupled architectures, but I love that you… But one of your… I read a bunch of stuff preparing for this, but you did this one blog post where you had a table that compares the microservices architectures, the data mesh, and your Meta Grid. It gets increasingly simple as you go from side to side, it seems like. You just added another one, the team topology to this. To me that was a helpful way for me to understand the Meta Grid was by contrasting it with those other models. Can you talk a little bit about each of those?
Ole:
Yeah. Sure. Sure. That could be a long talk, but I’ll try to be short.
Larry:
I’ll start a timer for you.
Ole:
Yeah. Basically I think microservices ties closely to operational data in a company. What you can do is you can take all the big monoliths of the value chain in a company, like I just mentioned, the ERP systems, the CRM systems and the like, and you can break them up into tiny, tiny, tiny services that functions in a decoupled way. This architecture is extremely complicated to achieve. It’s very, very complicated to achieve a microservice architecture, but if you do it, your company will have a competitive advantage that is remarkable. I’m sure you’ll know all this, but this is for your listeners to explain. Microservice architecture is basically very, very complicated. It’s big, it’s fast and it’s complicated. The same goes for data mesh. Data mesh architecture won’t be as big and as complicated as a microservice architecture, but it will still be relatively big, relatively complicated and fast.
Ole:
A data mesh architecture is an architecture that does not look at the operational data in a company. It does not look at the value chain of a company, but it looks at the analytical plane. It looks at the data warehouses, the data lakes, the data lake houses of a company and breaks the content of these quote, unquote, “monoliths,” up to small data products. That’s a data mesh. It’s relatively complicated to achieve a data mesh. Depending on your definitions, no company in the world has achieved it or a lot of companies has achieved it, depending on little bit of how much of a theoretical purist you are in terms of what a data mesh is. Then what I suggest is a Meta Grid that is a decentralization also, but it’s a conceptual, an intellectual decentralization.
Ole:
It’s not a technical decentralization as such. I am not arguing the end of specific metadata repositories, but what I’m seeing is that you need to do the same thing for metadata as we have done in the past for analytical data and for operational data. I’ve seen this very concretely because I know that a lot of teams are working on the exact same type of metadata in their teams with their technologies. I know this is a fact, and I have readers from all over the world, from all kinds of companies of a certain size. You need to have a certain size and a certain age before this becomes a problem in a company. But I have a lot of readers from all over the world reaching out and explaining that finally someone that gets this, finally someone that explains it. But basically, the Meta Grid does the same thing as microservices and data mesh, but for metadata in metadata repositories. It’s a relatively small architecture, it’s a relatively simple architecture and it’s a slow architecture.
Ole:
It’s not complicated technically to achieve this. What is complicated is the very realization of this. It’s complicated to address in a company because these are really our silos. These are not teams that have been used to working together, but the big promise of the Meta Grid is that you can really achieve something. You could achieve an enormous solidity in your understanding of your IT landscape if you get this. I think I actually, to be honest, I think I address a problem in IT and tech and data that is hard to identify and hard to grasp. But once you get that, it’s relatively easy to solve. There’s not that many problems that are easy to solve in data intake, but I actually think this is not that difficult once you get it.
Larry:
Yeah. That simplicity that really resonates with me as you do that. One of the things you were just talking about as you were talking right now, you mentioned IT a lot, but you talk about the four domains of the Meta Grid. That it’s not just IT and data information and knowledge as well. As you were just talking right now, I’m wondering, okay… Well, I guess first I’m curious about how you operationalize this, what it’ll look like on an ongoing basis, but I first think you have to build it. Are you just capturing documentation of metadata repos around an enterprise? Is it as simple as in sales they do it this way, in marketing, they do it this way? Is it something like that? Or how do you build a Meta Grid I guess?
Ole:
I would actually argue that a Meta Grid is not something you build. I argue, and I can prove, that Meta Grid architectures, once we accept the term Meta Grid, they exist in every single company already. Every single company will have a configuration management database. If it’s an old company that’s done a lot of mergers and acquisitions, they will have multiple configuration management databases. In those systems you will have lists of IT systems, you will have lists of integrations of application owners and what have you. Now, many companies also have business process mapping systems, for example. In those two systems, processes in the company is listed as a metadata example, a metadata type. These processes are rarely aligned because a business process mapping system is something that is used either for quality cases or for financial auditing cases, but it lists business processes and a CMDB. For example, I think I discussed 17 types of metadata repositories in my book, but these two would perhaps have business processes that would overlap.
Ole:
That would also overlap with the information security management system maintained by a chief information security officer or data privacy officer using a registry to list how sensitive data is processed. They will also work with the processes. These things or these metadata types, they interact across repositories. Now processes, it’s just one example. You have a lot of different examples, applications, type of endpoints. You can have very technical concrete examples such as servers and server names, but you can also have very abstract elements such as processes or project names and stuff like that, product names. That’s the architecture that I argue if you get that context under control across these repositories, then you save a lot of time and you get a lot more solid metadata architecture across these tools.
Larry:
Yeah. As you described that it’s really not just, but it’s mostly a discovery and is it like a documentation process just going out and…
Ole:
Yes. I would argue that it is a… What I argue that the Meta Grid is, it’s documents, it’s diagrams or pictures and it’s data, examples of data or entire data sets. Then obviously what the Meta Grid architecture suggests is that you create integrations between these systems so that each team does not do this in isolation and more importantly does not do this repetitively because that’s the big issue with this architecture. It’s that these teams have listed these things independently of each other to perform their business tasks, their particular goals.
Ole:
Then obviously you can… Once you’ve established this very, very basic architecture, this very simple architecture of API calls and architecture decision records and spreadsheets and diagrams, once you’ve achieved that, you can of course consider more complicated architectures using, for example, ETL, ELT tooling to perform this in a more automated way. Obviously, also… I’ve seen this, that’s why I was persuaded that it can be done. I’ve seen this by readers that have reached out to me. Two times I’ve seen it, but I won’t mention these obviously. But you can use on top of all this if you want and if you have a lot of organizational buy-in, you can use knowledge graphs to perform the Meta Grid, but-
Larry:
Yeah. I was going to ask because this is the Knowledge Graph Insights podcast, and it’s like everybody in this world knows about you and your work and talks about it all the time, but you never explicitly talk about knowledge graphs. I wanted to stitch that in a little bit. A knowledge graph might be one way to implement this knowledge that you discover. Is that a correct way of thinking about it or?
Ole:
Yes. I believe it is. The reservations I have is that I want to create something that is easily addressable and easily solvable with the Meta Grid. I’m not sure you would need a graph to perform a Meta Grid architecture. But obviously if you want to perform it at scale, if you want to build a custom user interface to explore the Meta Grid, then it would be super nice with a graph, wouldn’t it? But the reservations I have come from practical experience. I address I do not want to build a North Star. I think of data mesh architecture or Microsoft service architectures as North Star architectures that are beautiful and extremely elegant in the way they have been proposed by Martin Fowler and Sam Newman and obviously also Zhamak Dehghani. I think of those persons as brilliant technologists. The Meta Grid architecture is a solution that should work out of the box today for people fighting with metadata management out there in companies, like I have done myself, I have a lot of practical industry experience, and I am very humble in terms of what you can actually do in a company to change this agenda.
Ole:
So instead of describing only the North Star, what I have set out to do is to describe the practical reality that you can change right now, but obviously moving towards the North Star is possible if you get a lot of organizational buy-in. But what I know, what I’ve seen and what I’ve heard is that regardless of what type of metadata repository you’re talking about, implementations of these technologies are typically very, very poor. They are not working that well. I have a lot of read… My first book, The Enterprise Data Catalog gave me a lot of readers confessing to me, an enormous amount of readers from all over the world confessing to me that they thought my book was brilliant, but that they had not succeeded in implementing a data catalog in their organization for a lot of reasons that are linked to politics, time, technical understanding, mandate and so forth.
Ole:
I don’t want to create an architecture that is only doable if you have all these things in place because I’ve seen it go wrong so many times. Also, because what the Meta Grid architecture really is, the core of the Meta Grid architecture is a way out of that labyrinth. If you have implemented an information security management system and you have not succeeded that well in it, the Meta Grid architecture is there to help you because it can make you connect dots that you didn’t know of before in tools that you don’t know exist inside your company, managed by teams that you have never spoken to. Actually, I can help you succeed with that technology with the Meta Grid, and I can do that for all kinds of teams looking in all kinds of new directions. That’s what I want to do with the Meta Grid architecture. Obviously if you get really on top of things, if you are a brilliant technologist, yes, then you can actually power the Meta Grid with a graph. I’ve seen that and that is fantastic …
Larry:
No. You recently posted on LinkedIn about that, that you weren’t thinking of this, you hadn’t thought of this as a knowledge graph thinking and you thought, wait a minute, a couple of people have done this. Did I read that correctly?
Ole:
You did read that correctly, but there is a bit more to that story because I actually wanted to start the book like that as a… When I start writing of this book or propose the book to O’Reilly, I actually wanted it to be a knowledge graph book. But then I got a lot of feedback saying, “Ah. Hmm.” Lot of people were like, “Hmm,” and so I tuned down that level, that perspective a little bit, but with the massive… I must say it’s been quite massive, the interest that this concept has created. I’ve had a lot of people from all over the world reach out to me, and I have seen… But I must say these are very, very skilled persons in companies that obviously have a lot of money, but a lot of companies have a lot of money. But they have managed to obtain and maintain a position inside these companies where they’re capable of successfully working with knowledge graphs distinctly for this purpose. That, I must say, is very impressive, very impressive and super beautiful.
Ole:
If you see that navigating the reality of the IT landscape from very, very, very high-level conceptual descriptions into the fiber cables going from one office to another, and where our data center sits in the world, and where our applications are linked and what sensitive data they contain. See all these strategic always, or in the most cases, these strategic players that have so little knowledge about what is going on in the company, even though they have this quite substantial responsibility. For example, if a data privacy officer does not understand or answers incorrectly to authorities about these things, you know how the severity of fines and even lawsuits that will be personally addressed to this person. It’s super, super important. Seeing that is beautiful, but I argue that you don’t need to reach that North Star to make this work and get going. What you need to understand is that there is a set of technologies mapping the IT landscape for different purposes, leveraging different capabilities, but something that is very fruitful, very useful for you that you don’t perhaps know about.
Larry:
You’ve talked about… I’m getting the three things you mentioned earlier about this is small, simple, and slow. I got to admit, I’m not getting my head around the slow part of it. How is it… I think I get it, but I’d love to hear you elaborate on that a bit?
Ole:
Yeah. Sure. Sure. I think it’s way more simple than you think, but it’s just if you want to build a microservice architecture, it needs to be fast. It needs to be fast because it needs to be very responsive. You cannot have an ERP system that does not perform I won’t say in real time but fast. You need it to be fast. Because if it’s not fast, then you can’t respond to changes in the market fast, and you can’t… Simply, it doesn’t work. You need operational data to be responsive fast in certain cases. A microservice architecture, the entire intention of it is to decouple, to be flexible, to be adaptable. If that is something that you have to perform with one week latency, then what’s the point?
Ole:
The same goes with data mesh. If you want real time analytics to change the constitution or the structure of your website or how a car moves or how some tool for gardening responds to your movements, or I don’t know, any IoT device or… You would need real time analytics. You would need fast analytical data to be able to get a refined usage of a data mesh architecture, but the Meta Grid really is in no need of speed. There may be readers reaching out to me saying, “You’re not right on this one,” but typically a metadata repository responds to regulative, innovative or operational needs that are not urgent in the present. It’s solidity over time that is important. Your business process management system may need data from a CMDB, the example I mentioned earlier, or vice versa.
Ole:
But if you do a synchronization once a week, it will work. There’s no… It will work. When I’m saying it’s simple, it’s because it’s important not to build a complicated architecture, a complicated technology setup. Obviously you could stream a data mesh, but do you really want to do that? Or a Meta Grid, but do you really want to do that? It’s not that important in this case. What happens typically if you try to do that is that you get a technological setup that is so difficult to build that you will not achieve the goal you have. It’s the goal you want to reach and the goal is not difficult to reach, so don’t give yourself that obstacle.
Larry:
Yeah. That’s something that comes through in all the things I’ve read, and I can’t wait to read the book now because it’s clear, all those things. Also, something as you were talking just now, are you familiar with Stewart Brand’s Pace Layers model?
Ole:
I’ve got to admit I’m not.
Larry:
I’ll share it with you, and I’ll put a copy of it in the show notes because as you were just talking, now I get it, the slower… Because it’s… He has two metaphors that he uses to describe the capability for change within systems, and it’s like one of them is like a geologic metaphor, layers of crust going down into the earth. As you were just talking, it’s like Meta Grid is just an understanding of the deep structural governance-ey layers. Just an understanding of them, not the details of them. That’s a deeper layer than what his is. Then the further out you get in that model, the more there’s the need for real-time ERP data. Yeah. That’s just an enterprise requirement, but that’s a different concern than understanding the whole architecture. Does that make sense?
Ole:
It makes sense. It makes sense. What really… The book that made this crystal clear for me is Data Management at Scale by Piethein Strengholt. It’s an O’Reilly author also. I read his book as an enterprise architect, and it really was like an epiphany for me because it’s a very pragmatic book that suggests that the nature of your use case defines how you manage and move data. Obviously it’s a book, it has a big chapter on batch, it has a big chapter on APIs, it has a bigger chapter on stream or real-time or whatever you want to call that. I like the pragmatics of this book.
Ole:
Obviously we can all agree that all data, everything data should be streamed in every single use case, but that’s an ideal. The reality is different, and so knowing when to use what kind of stack or tech set-up or just integration patterns is really what this is about if you have limited economic means and limited full-time employees and also limited attention span by executive leadership. Knowing what to do when in this universe is really important. That’s what I… But there are many books on this topic, obviously also from the Fundamentals of Data Engineering. There’s an immense set of book that describes this way of thinking, but that book definitely sounds cool as well. I like the idea of layers.
Larry:
I think it’s germane. I think you all appreciate, but I can’t believe… Although we’re already coming up close to time, and I could literally talk about this forever. But I feel like we’ve given folks a good taste of the book, and like I said, I can’t wait to see it. But before we wrap up, is there anything last… Anything you want to revisit from the conversation or just want to make sure you share before we wrap up?
Ole:
I think there’s a detail around team topologies that I recently published on my Substack. I have a team structure that I call the data discovery team that I suggest build this. I just want to make sure everyone also get that detail from the conversation. The data discovery team would consist of a member from each of the metadata repository teams that I mentioned in the book, and they would collaborate to create the Meta Grid in its simplest… Actually team topologies use the term thinnest viable platform, I love that term. It’s exactly what the Meta Grid is. It’s the thinnest viable platform. It’s documentation, architecture decision, records, it’s diagrams, pictures of the architecture that you’re building, and then it’s data, data sets or entire data sets. Then obviously you can set up all kinds of integration architectures on top of that, but I just wanted to make sure that the data discovery team and the Meta Grid is a team topology that can make this work. It’s not something that is difficult to obtain.
Larry:
Nice. I love that, and the notion of team topologies. I did some research about that before we talked, and I’ll link to some resources about that, but I also love the thinnest viable platform. That seems like something that every enterprise should be aspiring to.
Ole:
Shouldn’t it be? It’s a brilliant concept. I love it.
Larry:
Yeah. That’s great. Well, hey, one very last thing, Ole. If folks want to connect with you or follow you online, what’s the best place to find you?
Ole:
The best place to find me would be LinkedIn. You can find me at Ole Olesen-Bagneux on LinkedIn. I also have a Substack that I publish in-depth on the Meta Grid, so you can find me there. My name is also Ole Olesen-Bagneux. I have a publication called the Meta Grid Notes on Substack, and then I’m also on Medium. It’s also just my name.
Larry:
Excellent. I’ll link to all those in the show notes as well. Well, thank you so much. My mind is blown in the best possible way, so thanks so much, Ole.
Ole:
Thank you, Larry. Thank you for having me on. It was a pleasure.
