The meta grid and metadata management altogether can be seen through the lens of team topologies, put forward in the book Team Topologies.[1] A team topology is both organizationally and technically a structure that allows to loosen up monolithic IT by redefining how people work together and how they use technology. The ideas in Team Topologies have been successfully tested at a global scale, and the Meta Grid is closely aligned to this way of thinking.
The Data Discovery team discussed in my upcoming book Fundamentals of Metadata Management,[2] create and maintain the Meta Grid. The Data Discovery team and the Meta Grid together constitute a team topology - and it is useful to think of it like this, because it will ease the enabling of the Meta Grid, and the many benefits it unleashes. A team topology is a flexible constellation of teams and technologies that allow for faster, more efficient flow in organizations.
There are four types of teams in team topologies:
Stream-aligned teams
Enabling teams
Platform teams
Complicated-subsystem teams
Stream aligned teams deliver a continuous flow of work that belongs in a business domain, or to an organizational capability. All teams managing metadata repositories can be considered stream aligned teams, e.g. data teams, the office of the DPO etc. are typically stream aligned teams.
Enabling teams are teams of specialists focused at a given technical domain. They help bridge capability gaps for the stream aligned teams. The Data Discovery team can be considered an enabling team, in the sense that it helps the stream aligned teams manage metadata repositories - by sharing identical metadata across these repositories and streams. [3]
Complicated-Subsystem teams are not relevant in this context, briefly explained these teams enable deep technical knowledge when other teams have cognitive overload.
Platform teams enable stream-aligned teams to perform their tasks without any technical friction or delay. In our context, the platform teams delivers the Meta Grid:
“The platform team provides internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services”
Team Topologies
This is exactly the point of the Meta Grid: To help all metadata repositories perform better. When considering metadata repositories managed by stream aligned teams, the platform team can assist these teams, with meta grid architectures. This enables the stream aligned teams - the teams managing metadata repositories - to unburden themselves from the cognitive overload of mapping the IT landscape again and again.
Altogether, the Data Discovery team consists of a an enabling team that have representatives from all teams managing metadata repositories, and a smaller platform team, that manages the meta grid documentation, as a platform. This is depicted in the figure below.
The Meta Grid should be considered the Thinnest Viable Platform (TVP), as also defined in Team Topologies:
“The simplest platform is purely a list on a wiki page of underlying components or servies used by consuming software (...) We should aim for the thinnest viable platform (TVP) (...) A TVP is a careful balance between keeping the platform small and ensuring that the platform is helping to accelerate and simplify software delivery teams building on the platform ”
Team Topologies, p. 92
The principles behind the TVP matches the idea that a meta grid architecture is performed merely by text, images and data and supports the fundamental idea that the Meta Grid is not to be a technology itself. Only in cases of elaborate Meta Grid Architectures should dedicated technologies be considered for the meta grid itself.
Notes
[1] M. Pais, M. Skelton, Team Topologies, (IT Rev, 2019), see in particular Chapter 5
[2] O. Olesen-Bagneux, Fundamentals of Metadata Management, (O’Reilly, 2025, forthcoming)
[3] In this sense, the Data Discovery team follows an Architecture Modernization Enabling Team AMET-pattern, strictly for decentralization of metadata in metadata repositories. To read more, see E. Silva, Architecture Modernization Enabling Teams, 23-Feb-2023, see especially the table “AMET primary purpose”
A friend shared some of your fantastic insights in another post, so I followed that here, where I am missing *all* the context as this is my first introduction to your writing. I have also not read the Team Topologies book; I just read what you describe here.
I am only commenting because I feel indebted to you for your insights, and if I'm just missing the context, please feel free to dismiss and ignore this comment.
In my 25+ years as a software engineer, Team Topologies does not accurately reflect most enterprise organizations I have worked at. The teams I have worked on have never been so neatly categorized. Sometimes there is a single "Team" of up to 20 engineers that has all those responsibilities and more. Usually, there are focused "Product Teams" with some of those as shared responsibilities. Sometimes there are one or more centralized teams that split out some of those shared responsibilities, usually along with "Platform engineering" or "DevOps".
Your book and other posts are very interesting, but I felt like I owed it you to ask if your advice and Meta Grid is able to speak usefully to those who are in the context of a more messily defined responsibility as well.
My apologies if this is just off base and a distraction.
I’ve been reflecting on how classical data governance roles adapt within the Meta Grid framework, particularly in alignment with Team Topologies.
I don’t want to go now through all Data Excellence Roles I have in my concept, but two roles stand out as critical in both their traditional and evolving responsibilities:
The Data Steward – already central in a federated data domain model but now requiring a broader perspective.
The Data Excellence Rollout Manager (DXROM) – a role I have always introduced as a key enabler for operationalizing data governance and metadata management on the ground.
I can imagine both roles being deeply relevant to the Meta Grid architecture, yet their responsibilities shift significantly in this new paradigm.
1. The Data Steward: From Enterprise Data Catalog to Multi-Repository Metadata Stewardship
In a federated data domain model, the Data Steward was already responsible for:
Metadata collection and documentation within their domain
Maintaining and curating metadata in an Enterprise Data Catalog (EDC)
Ensuring metadata quality and compliance under the approval of the Data Definition Owner
However, within the Meta Grid, the perspective of this role shifts:
Metadata is no longer consolidated in a single Enterprise Data Catalog but distributed across multiple repositories.
The Data Steward must now ensure consistency and discoverability across multiple metadata repositories, not just one.
Instead of only working under the Data Definition Owner, the role now engages more collaboratively with other stream-aligned teams and platform teams.
The Data Steward now contributes to metadata interoperability between decentralized repositories, which aligns with the Meta Grid’s federated and lightweight metadata architecture.
In Team Topologies terms, the Data Steward moves from a purely stream-aligned role to also interfacing with enabling teams that support metadata consistency across repositories
2. The DXROM: From Data Governance Enablement to Meta Grid Metadata Orchestration
The Data Excellence Rollout Manager (DXROM) has always played a unique role in metadata enablement. While Data Governance Managers operate at a conceptual and tactical level, the DXROM ensures operational implementation by:
Supporting metadata governance rollouts in projects and use cases
Defining and enabling conceptual metadata (e.g., data terms, definitions) with data requestors and stewards
Acting as a bridge between governance policies and practical execution
In a traditional metadata governance model, organizations might have only 1-2 Data Governance Managers, but the DXROM scales flexibly as needed to support various initiatives.
With Meta Grid and Team Topologies, the DXROM role expands significantly:
From a rollout role → to a continuous metadata enabler role in an Enabling Team.
From managing Enterprise Data Catalog metadata → to orchestrating metadata across multiple decentralized repositories.
From defining metadata concepts → to enabling metadata self-service across the organization.
From engaging with Data Stewards and Data Definition Owners → to also collaborating with Platform Teams to embed metadata governance into self-service tools.
From being a support function → to an automation enabler, leveraging APIs and metadata observability tools to ensure governance is built-in rather than enforced manually.
Both the Data Steward and DXROM could have a central role to the Meta Grid’s decentralized metadata approach.
Their evolution ensures:
Metadata remains federated, yet consistent and interoperable across domains.
Governance is no longer enforced top-down but embedded into operational workflows.
Metadata is discoverable and usable at scale without creating a monolithic repository.
Teams managing metadata repositories (stream-aligned teams) are effectively supported by Enabling and Platform Teams without cognitive overload.
You now I am a believer of decentralization but also that federation only success with “enlightened” data citizen why operationalized guiderails with the two above mentioned roles are from my point of view critical.