The Meta Grid is nuclear architecture
Meta Grid architectures are extremely small, extremely full of energy and extremely explosive
Metadata repositories that depict the IT landscape of a company collectively constitute an architecture. I call that architecture the Meta Grid. In the vast majority of companies, that architecture is unconscious, with only very few established relations between the metadata repositories in use.
The Meta Grid has a nuclear-like character. The Meta Grid is small. Unlike the other decentralized architectures — microservices and data mesh — the Meta Grid will never grow big. It will remain very small throughout its lifetime.
However, what surrounds the Meta Grid is enormous: the entire IT landscape of a company. Everything in it.
Most company IT landscapes are deeply dysfunctional. They work, but they are full of extraordinarily expensive, underperforming IT solutions that gradually deteriorate further as time passes. Scrambling along, with a logic of their own, that is slowly lost to Corporate amnesia.
Unlike microservices and data mesh, the Meta Grid is not something companies actively decide to build. Instead, companies unintentionally create Meta Grid architectures all the time.
Poorly built, these Meta Grid architectures can be considered as the splitting of the nucleus in atoms, and subsequently as the unleashing of the extreme explosiveness of something extremely small: Meta Grid architectures gone wrong are very small representations of very big, catastrophic realities: IT Landscapes almost completely out of control.
However, Meta Grid architectures can also be architected consciously. If so, they become nuclear fission like vehicles: they allow the depiction of vital metadata elements in a coordinated way, cascading these coordinated activities deep out into the IT landscape in various directions for a multitude of purposes rooted in innovation, operation and regulation.
Let’s take the example of process.
If we establish that the BPMS is depicting processes in the company at the deepest level, then this metadata repository is our point of departure and processes can be pushed to other metadata repositories. Let’s follow the expansion of the Grid. The processes are pushed to the DPR and gives the Data Protection Officer a perfect foundation for living up to data protection regulations - instead of the DPO mapping these processes themselves. Further, processes are pushed out to a cluster consisting of the EAM and CMDB. Here processes are contextualized to the past, present (CMDB) and future IT landscape (EAM), with evidence based certainty of the actual processes in the company, expanding the metadata input from the BPMS to further detailing due to the metamodel configurations of the CMDB and the EAM. With this extra detailing, processes are pushed further to a cluster of the LMS and QMS, ensuring that training and quality is carried out within the established business processes both at the highest enterprise levels and detailed levels. Processes are also pushed from that cluster to the AMS, and further detailed to fit the pursuit of license usage across the company network.
In this Meta Grid, processes are mapped and maintained by one virtual team, and not six different teams, working in monolithic isolation in six different ways. Time spent on Metadata Management is significantly reduced and substantial solidity is ensured, liberating time to peform the core capabilities of the technologies on the Grid.
For the IT Landscape, the Meta Grid can be an extremely destructive atomic bomb or an extremely powerful source of energy. That is how the Meta Grid is nuclear architecture.
_________________
Two notes:
1. No Meta Grid architecture is canonical
2. The number of domains is not fixed but must remain (very) small
Metadata repositories (non exhaustive):
AMS: Asset Management System
BPMS: Business Process Management System
CMDB: Configuration Management Database
CMS: Content Management System
CMSy: Collection Management System
DBM: Database Modeler
DC: Data Catalog
DL: Data lake
DLH: Data Lakehouse
DO: Data Observability
DPR: Data Protection Registry
DW: Data Warehouse
EAM: Enterprise Architecture Management
EMS: Endpoint Management System
IR: Integration Repository
ISMS: Information Security Management System
ITSM: Information Technology Service Management
KMS: Knowledge Management System
LMS: Learning Management System
QMS: Quality Management System
RIMS: Records and Information Management System
