The temptation to centralise everything

When an organisation sets out to understand its data and processes at scale, the instinct is to pour everything into a single platform. One catalogue, one source of truth, one place to look. It feels tidy. In practice, forcing process models, application maps, data lineage, quality scores and business glossaries into one tool creates exactly what it was meant to eliminate: a new silo, owned by one team, serving no one perfectly.

A more sophisticated pattern recognises that process architecture and data governance are different disciplines with different owners, different cadences and different questions to answer. The right model keeps them in their natural homes and builds a deliberate, well-designed interface between them. This is the difference between a forced model and a federated one.

The architectural decision

Choosing two best-in-class tools — one for Enterprise Architecture, one for Data Governance — is not redundancy. It is a deliberate separation of concerns that becomes essential at national scale.

Two hubs, two questions

In a typical mandated toolchain, an Enterprise Architecture platform such as ABACUS and a Data Governance platform such as AXON each take a clearly defined role.

ABACUS — the business and process architecture hub

As the Enterprise Architecture hub, ABACUS is the logical home for the process and capability view. It answers: what business processes do we run, what capabilities do they use, and what applications support them? It stores validated BPMN 2.0 process maps, business capabilities, goals and the applications that underpin them.

AXON — the data governance and metadata hub

As the Data Governance hub, AXON is the logical home for the physical data view. It answers: what physical data supports this process, where is it, how does it flow, what is its quality, and who owns it? Populated by automated discovery, it holds data assets, systems, dataflows, the business glossary, quality rules and policies.

From passive catalogue to active metadata

There is a deeper shift hidden in the phrase 'reusable metadata knowledge base'. A traditional catalogue is passive — it documents what exists and waits to be read. A modern governance platform treats metadata as active: an intelligent, event-driven foundation that drives automated actions, alerts and real-time governance. Metadata stops being a filing cabinet and becomes the engine that powers transformation and risk management.

The lynchpin: stitching process to data

A federated model only works if the two hubs are genuinely connected. The interface between them is not a single API call — it is a conceptual linkage that has to be designed and maintained. The stitching method works in three steps:

1. In ABACUS, a business process — say, 'Issue VAT Refund' — is linked to its supporting applications and business capabilities within the architecture model itself.

2. The stitch: that same process element is linked, via a common identifier, to the corresponding business glossary term in AXON.

3. In AXON, that glossary term is already connected to all the physical systems, dataflows, quality rules and data assets it represents.

The result is transformative. A programme manager can start in an ABACUS process map, follow the logical BPMN 2.0 flow, and click straight through to AXON to see the physical data assets, granular lineage and quality scores that underpin that exact process step. That federated, linked model is the reusable knowledge base — and it is far more powerful than anything a single forced tool could deliver.

The bottom line

Don't force your metadata into one box. Put each discipline in its proper home, then invest in the interface between them. The stitch — not the storage — is where the value lives.

VE3 designs and operates federated metadata architectures that connect Enterprise Architecture and Data Governance into a single, queryable knowledge base. If you are weighing up how to operationalise a mandated toolchain without creating a new silo, visit ve3.global to see how VE3 can help.