Data governance

Data governance built on the real model of your applications

icaria Data Governance documents the metamodel of your applications and keeps its changes under control, so your data office works on the real model, not on documentation that no longer matches it.

  1. Document applications, environments and metamodels from the databases themselves.
  2. Detect model changes and drift between production, test and development.
  3. Compare the same data in different systems and pinpoint integrity defects.
Request a demo

Where to start

Governing data starts with knowing its model

A glossary that does not match the tables, an owner who does not know which application their data lives in, or a change nobody documented: data governance fails when it does not start from the real model. That model is the metamodel of each application: its tables, fields, relationships and keys.

icaria Data Governance reads that metamodel from the databases themselves, keeps it current and uses it as the basis for classifying data, evaluating its quality and comparing one system with another.

How the data office works

Each step builds on the one before

Everything icaria DG does starts from the same metamodel, so each step builds on what the previous one documented. Start with the inventory and widen the scope when you need to.

  1. Document what you have

    Declare each application with its environments and submodels and synchronise its metamodel: tables, fields, relationships, indexes and keys. Business terms link each concept to the applications where it appears.

    Documented after this step:

    • Metamodel (Added by this step)
    • Business terms (Added by this step)

  2. Control changes

    The first synchronisation is kept as the reference snapshot. Later ones show what was added, changed or removed, and the production, test and development instances are checked against each other to detect drift.

    Documented after this step:

    • Metamodel
    • Business terms
    • Reference snapshot (Added by this step)

  3. Classify the data

    The data map collects the fields of interest, such as identity documents, names, addresses or accounts, with their format and the location of the master data. Inspectors apply the rules that recognise each type of data.

    Documented after this step:

    • Metamodel
    • Business terms
    • Reference snapshot
    • Data map (Added by this step)
    • Inspectors (Added by this step)

  4. Evaluate quality by role

    Validators count the valid, invalid, empty and null records of each field. Information roles group the fields that represent the same concept, and evaluation sessions check whether they hold the same value.

    Documented after this step:

    • Metamodel
    • Business terms
    • Reference snapshot
    • Data map
    • Inspectors
    • Information roles (Added by this step)
    • Evaluation sessions (Added by this step)

  5. Compare across systems

    Data from several applications is mapped to a common reference metamodel and compared with check rules. Each discrepancy is an integrity defect and is published to the health monitor.

    Documented after this step:

    • Metamodel
    • Business terms
    • Reference snapshot
    • Data map
    • Inspectors
    • Information roles
    • Evaluation sessions
    • Reference metamodel (Added by this step)
    • Integrity defects (Added by this step)

Cross-system comparison

The same customer in the CRM and the ERP

The CRM and the ERP store the same customer in different tables and fields, sometimes in different formats. icaria DG assigns each field to an information role, maps both records to the reference metamodel and compares them value by value.

Evaluation session · seed: customer 100482

Sample record with fictitious data

Information role CRMACCOUNTERPCUSTOMER_MASTER Result
Tax ID TAX_ID GB123456789 VAT_NO GB123456789 Match
Company name ACCOUNT_NAME Alba Engineering Ltd. CUST_NAME ALBA ENGINEERING LTD Match After the rule that matches case and punctuation
Address BILLING_STREET 12 High Street ADDRESS 21 HIGH ST Integrity defect
Postcode BILLING_ZIP LS1 4DY POST_CODE LS1 4DY Match
Billing email BILLING_EMAIL invoices@albaengineering.co.uk INV_EMAIL invoices@albaengineering.co.uk Match
Customer status STATUS Active CUST_STATUS Closed Integrity defect

One reference structure

The architect designs the reference metamodel and the rules that map each application's data to it, such as the one that matches case and punctuation in the company name. That is how systems that share no tables or field names can be compared.

Defects that are followed up

Every discrepancy is recorded as an integrity defect and published to the health monitor, where data owners follow it through to correction.

Data migrations

In a migration, the source and target systems hold the same customers in different structures. Applied to both, the same comparison checks value by value that the migrated data is equivalent before the old system is retired.

icaria platform

A current model for every process that depends on data

  • icaria Data Governance

    A synchronised metamodel

    icaria DG keeps the metamodel of each application synchronised and shows what has changed. It is the reference for any process that reads those tables and fields: integrations, reports or migrations.

    See icaria Data Governance

  • icaria TDM

    Test data on the current model

    icaria TDM extracts, subsets and masks data on the same applications, environments and submodels. A model change that shows up in icaria DG can be reviewed before the next extraction.

    See icaria TDM

  • icaria Data Privacy

    Privacy on data you have located

    icaria Data Privacy executes data subject rights on the personal data in your applications. A new field detected at synchronisation is classified in the data map before it slips through.

    See icaria Data Privacy

Who works with icaria DG

What each team does with the same metamodel

Team What it needsWhat it uses in icaria DG
Data office To know what data exists, where it is and who is accountable for it Application documentation, business terms and the health monitor
Data owners and data stewards To define each business concept and resolve its discrepancies Business terms, master application and integrity defects
Data architecture To control the model and its promotion between environments Metamodel synchronisation and the reference metamodel
DPO and compliance To know where personal and sensitive data is Data map and inspectors
QA and data quality To measure quality by field and by concept Validators, information roles and evaluation sessions
Migration teams To check that the target holds the same data as the source Reference metamodel and integrity defects

Let's talk about data governance in your organisation

We'll show you icaria DG on a case like yours: documenting an application, controlling changes to its model or comparing two systems that store the same data.

Request a demo Talk to an expert

Frequently asked questions

What does icaria DG give a data office?

An inventory that comes from the databases themselves, not from spreadsheets. icaria DG documents the metamodel of each application, controls its changes between synchronisations and environments, classifies fields in a data map, evaluates quality by information role and compares the data that different applications store for the same concept.

How does icaria DG compare data in a CRM and an ERP?

It transforms the data of both applications to a common reference metamodel, with rules the architect defines, and compares them with check rules. Each discrepancy, such as the same address written two ways or a customer who is active in one system and closed in the other, is an integrity defect published to the health monitor.

What are information roles?

They are how you state that several fields represent the same business concept, even when their names and tables differ. An evaluation session collects the values of all the fields linked to a role for a specific business object (the seed) and checks whether they match.

Does icaria DG detect uncontrolled changes to the data model?

Yes. The first metamodel synchronisation is kept as the reference snapshot and later ones are compared with it to identify additions, changes and deletions. Metamodel management across environments checks production, test and development against each other and detects the drift left by an incomplete promotion or a manual change.

Can icaria DG validate a data migration?

Cross-system comparison can be applied to the source and target of a migration: both are mapped to the same reference metamodel and compared value by value. Discrepancies show up as integrity defects before the old system is retired.

Which data sources does it support?

Relational databases (Oracle, PostgreSQL, DB2 for z/OS, AS/400 and LUW, SQL Server, SQL Azure, MySQL and Fujitsu Symfoware), VSAM files and XML and CSV formats, through JDBC connectors.

How does icaria DG relate to icaria TDM and icaria Data Privacy?

All three products work on the same foundation: applications, environments, submodels and metamodel. The model icaria DG documents and keeps current is the model on which TDM prepares test data and Data Privacy locates personal data.

Related content

More on data governance