Meta Grid Domains
A short description of meta grid domains and how to distringuish them from domains in microservices, data mesh, and fediverse architectures
The Meta Grid is a decentralized architecture for enterprise metadata. This metadata is stored in multiple metadata repositories. All these have a tendency to turn into monoliths, as they are focused at delivering an overview of the IT landscape for various purposes spanning innovative, operative and regulative enterprise endeavors. The meta grid addresses this monolithic reality - it’s an architecture dedicated at contextualizing and coordinating metadata so that enterprises can get increased impact of their investments in metadata repositories, better maintain them over time, and substantially cut costs on redundant work carried out by external tech- and management consultancies.
The Meta Grid puts an end to siloed, repetitive tasks of deep, technical mappings of the enterprise IT landscape performed again, again and again by these consultancies. The Meta Grid is decentralized because it acknowledges the empirical fact that the same metadata - always uniquely shaped - is stored in multiple metadata repositories that are seldomly connected. This creates confusion, even conflict, increased costs and low certainty of enterprise IT landscapes. That’s the problem that the Meta Grid architecture addresses and resolves.
Just like other decentralized architectures, the Meta Grid has domains. And understanding these domains is a key to understanding the meta grid altogether. Instead of the long, rather opaque definitions of domains found in Domain Driven Design, the Meta Grid utilizes a more simple definition from Domain Analysis: A domain as a group of people that share knowledge, goals, methods of operation, and communication. [1]
Domains in Microservices, Data Mesh, and Fediverse
The domains in a Meta Grid can be understood smoothly when comparing them to domains in other decentralized architectures. Accordingly, we will briefly describe the nature of domains in:
Microservices
Data Mesh
Fediverse
Microservices. In microservice architecture, domains are related to the monoliths that the microservice architecture dissolve: If a Customer Relationships Management systems (CRM ) is broken up into small microservices, then, these microservices are shaped in the overall logic of the activities carried out in the context of customer relationship management. [2]
Data Mesh. In a data mesh, domains are exactly not related to the monoliths that they dissolve: Enterprise wide data lakes and warehouses, that have destroyed the characteristics of the domain from which data was gathered, cannot serve as an element to structure data mesh domains. Therefore, one has to go deeper into the origins of the data, and back to the business function in which these were derived - ultimately approaching the same types of domains that are found in microservice architectures. [3]
Fediverse. Unlike centralized social media platforms, fediverses allocates specific servers owned by the community that uses them (and each user can engage in multiple communities). A community chooses to use the given decentralized social media platform, such as BlueSky and Mastodon, and as such, they use the software provided, but the community owns and moderates the content. Unlike Facebook and Instagram, there is no centrally defined algorithm that controls all feeds for all users. In a fediverse, domains are created as specific topics of interest to a reading public, and accordingly, that shapes the domains of the fediverse - and is likely to allow a more democratized, secure social media reality in the future. [4]
All in all, domains in microservices, data mesh and fediverses can be seen in the light of our definition: Groups of people that share knowledge, goals, methods of operation, and communication.
On this background, we now ask: What constitutes the domains of the meta grid? What groups of people are trying to get an understanding of the enterprise IT landscape though metadata repositories? What are their goals? What are their methods of operation? How do they communicate? This is what we discuss below.
The Four Domains of the Meta Grid
Fundamentally, the Meta Grid has a flexible domain architecture - domains can be added and the domains themselves can be varied to fit the thinking of the specific enterprise. However, the reality of most companies will be a meta grid that has four domains, that I discuss in depth in my upcoming book Fundamentals of Metadata Management [5] namely:
IT Management
Data Management
Information Management
Knowledge Management
These domains represent groups of people that share knowledge to fulfill shared goals by working with the shared method, and shared means of communication. Each domain has their own subgroups of people and these subgroups are all focused at one metadata repository. Each of these will have a tendency to be managed in isolation , leveraging one core capability - and these have significant tendencies to turn into monoliths. Let’s dive in.
IT Management. The IT Management domain is the traditional, IT centric domain. It contains metadata repositories - typically run from a central IT department - that allow management of the past, present and future of the IT landscape in a company. Accordingly, typical metadata repositories in the IT Management domain are:
Enterprise Architecture Management tool (EAM)
Endpoint Management System (EMS)
Integration Repository (IR)
Asst Management System (AMS)
IT Service Management System (ITSM)
Configuration Management Database (CMDB)
However more metadata repositories are frequent in this domain, such as e.g.:
Project- and Portfolio Management (PPM) system
DevOps tool (DevOps)
You can see a depiction of the IT Management domain in Figure 1-1, complete with its metadata repositories and the core capabilities they leverage. Keep in mind that the core capability will define how the IT landscape is depicted (this goes for each metadata repository in each domain).
Figure 1-1. The IT Management domain in the Meta Grid.
Data Management. This domain represents the infamous Modern Data Stack - a term that has fortunately faded. [6] The metadata repositories in data management are focused at representing the data from all parts of the company, in distinct solutions aimed at storing, measuring, monitoring, transporting, and ultimately exploiting data for analytical use cases. The tooling of this domain is typically scattered across many parts of the enterprise, wherever data teams [7] support strategic, data-driven initiatives. Typical metadata repositories in the data domain are:
Data Catalog (DC)
Data Modeling tool (DBM)
Data Warehouse (DW)
Data Lake (DL)
Data Pipeline tool (ETL)
Data Quality (DQ)
Access & Identity Management tool (AIM)
In the data domain, there are - many - more metadata repositories, not discussed at length. The reason is that, at least until the second half of 2023, it was possible for software vendors to claim that ever more narrowly scoped capabilities were in need of their own technology. Such technologies are for example:
Data Lineage tool
Data Observability tool
You can see a depiction of the data management domain in Figure 1-2.
Fifure 1-2. The Data Management domain in the Meta Grid.
Information Management. The information management domain is relatively small, and primarily dedicated to regulatory/compliance agendas. It has its roots in tracking legal proof, ensuring privacy and security/confidentiality of information. Typical metadata repositories in the Information Management domain are:
Business Process Management system (BPMS)
Privacy Information Management system (PIMS)
Information Security Management system (ISMS)
Records- and Information Management system (RIMS)
You can see the information management domain depicted in Figure 1-3.
Figure 1-3. The Information Management domain
Knowledge Management. The last domain - in the suggested collection of domains in the meta grid - is knowledge management. This domain is focused at ensuring learning, quality, and dissemination of the past and present of the company - and in doing so, metadata repositories of the IT landscape emerge. Typical metadata repositories for the knowledge management domain are:
Content Management system (CMS)
Knowledge Management system (KMS)
Learning Management system (LMS)
Quality Management system (QMS)
Collection Management system (CMSy)
You can see the knowledge management domain depicted in Figure 1-4.
Figure 1-4. The Knowledge Management Domain
Summary and next up
Domains in the Meta Grid represent groupings of metadata repositories. These groupings are shared perspectives and purposes on how to manage the IT landscape of a company. In most cases every metadata repository does this in splendid isolation, which is expensive, confusing and not robust.
The domains that have been described above - IT, Data, Information, and Knowledge are not canonical. Many others could exist, e.g. Marija Drašković has persuasively argued that at least a fifth domain exists, namely the domain of (Artificial) Wisdom Management. This domain would be focused at managing the AI aspects of an IT landscape.
The point about the Meta Grid is simply this: Metadata repositories list the same metadata again and again. The Meta Grid is a new architecture that seeks to limit and focus the money being spend in the majority of companies around the world when trying to implement metadata repositories. The Meta Grid will allow for a smoother, simpler and even accelerating way of implemtenting metadata repositories, and be a strategic key in managing highly complex and and costly enterprise IT landscapes.
In following posts here on Substack, I will dive deeper into the Meta Grid, with practical, easy to follow examples.
Notes
[1] I have discussed this in more depth in the section Understanding Domains, in Ole Olesen-Bagneux: The Enterprise Data Catalog, (O’Reilly, 2023), p. 25-32
[2] Martin Fowler: Microservices - a definition of this new architectural term; Sam Newman, Building Microservices - Designing Fine-Grained Systems, 2nd edition (O’Reilly, 2021); Guillaume Bodet, Scrum en Action, (Pearson, 2012)
[3] Zhamak Dehghani: Data Mesh - Delivering Data-Driven Value at Scale (O’Reilly, 2022); Piethein Strengholt: Data Management at Scale - Modern Data Architecture with Data Mesh and Data Fabric, 2nd edition (O’Reilly, 2023)
[4] Fediverse on Wikipedia
[5] Each domain will be an independent chapter in my upcoming book, Ole Olesen-Bagneux: Fundamentals of Metadata Management (O’Reilly, 2025)
[6] Joe Reis: Everything Ends - My Journey With the Modern Data Stack
[7] One typical constellation in big enterprise is that BI data teams are placed in Finance, where more advanced analytics data teams are placed in e.g. Manufacture or Research & Development. For a deeper understanding of data teams (there are three types), see; Jesse Anderson: Data Teams, (Apress, 2022)







Jeremy Posner suggested this alternative meta grid domain structure:
Business metadata:
Owners indicated in brackets...
- the org structures & People and what they know, competencies/skills (owner:HR)
- Financial structure - ie) Legal entities, cost centres, (owner:Finance)
- Bus. Capabilities and Bus. Process registry (owner:EA)
- Projects, costs, budgets/forecasts. etc (owner:Bus. mgt)
- Business Risk registry (owner:OpRes)
Data mgt metadata:
Owner: CDO/DGO and/or each Line of Bus.
- Glossaries, external Report inventory (ie: regulatory), Security/Privacy classifications, etc
- "Business" Data Lineage & Data usage agreements
- Data controls & Data Quality
- Data Issue Management and risk registry
- Possibly ontologies and data models here (maybe below with Apps)
Application metadata
Owner: Tech group. CIO/CTO
- Application inventory.
- Application Risk registry
- Application cost allocation
- Integration tools (ETL,ELT)
- Application schemas (physical/scanned from the estate)
- API registries (data contracts)
- Possibly ontologies/data models
- Build/DevOps
Technology metadata
Owner: Tech "Infrastructure" group, InfoSec/CyberSec. These are central services for the whole org:
- CMDB (on prem and cloud)
- Operational metadata linked to applications ( incidents/tickets from ITSM, metadata from logs)
- Tech Utilisation & Costs
- Tech Security risk registry inc. External threat / cyber info
- Gateway info (endpoint mgt)
- IAM
The metagrid domains you are proposing look like horizontal domains that support business roles that define and manage metadata. However, the metadata describe concepts that belong to vertical business domains and therefore ideally are owned by these vertical domains, in the same way that these vertical domains own the described data (and business process behavior).