What is data governance, and what does it actually change day to day?

Data governance is the operating model that decides who owns each data asset, what it means, where it came from and who may use it. Day to day it changes four things: every important table has a named owner, contested terms like active customer have one approved definition, any figure can be traced back to its source columns, and access follows data sensitivity rather than old tickets.

What is OvalEdge — is it a database?

No — OvalEdge is not a database, and it does not store your data. OvalEdge catalogs metadata about the systems you already run — names, definitions, ownership, sensitivity and how data flows. It connects with read-only credentials, reads structure and statistics, and writes only metadata to its own store. Your data never moves, which is the answer to the first question every security review asks.

Can OvalEdge be deployed on-premise or in an air-gapped environment?

Yes — OvalEdge can be deployed on-premise or in an air-gapped environment, and that is the normal deployment here rather than an exception, which is why it survives the first filter in Azerbaijani banking and government evaluations. It needs its own database and network access to the systems it reads. Nothing requires internet connectivity at runtime.

How long does a typical OvalEdge implementation take?

A typical OvalEdge implementation takes six to twelve weeks to a working catalog for one domain, with harvested lineage and a glossary people use. Installing, connecting and harvesting take three to four weeks and are largely mechanical. The rest is the human phase — definitions, ownership, classification — which slows down in proportion to how many domains you attempt at once.

Which data sources does OvalEdge connect to?

OvalEdge ships more than 170 pre-built native connectors, covering Oracle, SQL Server, PostgreSQL, Teradata, SAP, 1C, mainframe extracts, object storage, Snowflake, Databricks and the major BI tools. Ask about your systems rather than the total, and ask specifically whether lineage is supported for each — many products can read a source's metadata but cannot parse its transformation logic.

Does a data catalog replace our data warehouse?

No — a data catalog does not replace a data warehouse. The warehouse stores and serves data; the catalog stores metadata describing that data and everything in your other systems. They are used together. Deploying a catalog changes nothing about your pipelines or reports — it makes them findable, documented and traceable.

What is the difference between a data catalog, a data dictionary and a business glossary?

A dictionary describes one database's structure for developers. A glossary defines business concepts like net exposure for the business. A catalog is the platform that spans the whole estate and holds both. What makes the catalog more than a document is the binding: each glossary concept is linked to the physical columns that implement it.

What is column-level data lineage, and why does it matter during an audit?

Column-level lineage traces a single column from its source, through every transformation, to the figure in a report — which is exactly the shape of the supervisory question show us how this number was calculated . Without it the answer is a reconstruction from memory that takes days. Insist on lineage parsed automatically from your SQL: hand-drawn diagrams are misleading within a year.

Who should own data governance — IT or the business?

Data governance is owned by the business, with heavy technical support from IT. IT can implement a catalog and harvest lineage; it cannot decide what active customer means. When governance sits entirely inside IT, definitions get made by people without the business context to make them, and the business ignores the result.

Do we need a data governance program in place before we start doing AI?

You do not need a full data governance programme before starting AI, but you do need governance on the specific data your AI will use — and that is more than most organisations have. Gartner expects over 40% of agentic AI projects to be cancelled by end-2027, with inadequate controls among the causes. Catalog and classify the one domain your first use case depends on: a few weeks, not a year.

How does OvalEdge handle Azerbaijani, Russian and English metadata in one catalog?

OvalEdge holds trilingual metadata as one canonical concept carrying a label in each language, rather than three parallel glossaries. `müştəri`, `клиент` and `customer` share no characters, so no automated matching will connect them — a person who knows the business in all three languages has to decide they are one concept. Design for this on day one; retrofitting it is expensive.

Does OvalEdge help satisfy Central Bank of Azerbaijan reporting requirements?

OvalEdge supplies the evidence CBAR requirements depend on, though no software makes an institution compliant on its own. CBAR's Regulation on Information Security Management in Banks, in force since April 2022 and built on ISO/IEC 27000, expects asset ownership, classification and access control tied to it. A catalog produces that evidence from the systems themselves rather than from memory.

How do you measure whether a data governance program is working?

Measure a data governance programme by behaviour change, not by row counts. A catalog with fifty thousand documented assets and no users is a more expensive spreadsheet. The metrics that mean something: analysts checking the glossary before building a report, engineers checking lineage before changing a schema, and how long it now takes to answer a regulator's question about a figure.

What does data stewardship involve, and how many stewards do we need?

A steward is a named person in the business accountable for a set of assets: approving definitions, confirming ownership, settling disputes. Roughly two hours a week. Fewer than you expect — one per domain, so ten to twenty across a large bank. Make it part of an existing role, because a programme built around a few exceptional individuals collapses when two of them leave.

Is Yukon Labs an OvalEdge reseller or an implementation partner?

Yukon Labs is an OvalEdge implementation partner, not a reseller. We deploy, configure and operate OvalEdge inside your environment rather than selling a licence and leaving. That means connectors against your real systems, lineage validated on your own transformation code, the multilingual glossary modelled correctly from the start, and the change management that decides whether the catalog gets used.

Metadata Management: The Three Types

The three kinds of metadata, why conflating them breaks governance programmes, how active metadata differs from a static inventory, and what to harvest rather than type.

Metadata is what you know about data without looking at the data itself: what a field is called, what it means, who owns it, when it last loaded, how many rows it holds, who queried it yesterday. Metadata management is the discipline of collecting that reliably and keeping it true.

It sounds administrative and turns out to be the load-bearing layer of a governance programme. Every control you might want — classification, access rules, quality checks, lineage, retention — is applied to metadata rather than to data. If the metadata is wrong or absent, none of the controls above it mean anything, however well the policy is written.

The most useful thing to get right early is the distinction between three kinds of metadata, because organisations that treat them as one thing consistently build a repository that satisfies nobody.

The three types

Technical metadata describes structure. Table and column names, data types, lengths, nullability, primary and foreign keys, partitioning, row counts, physical location. It comes out of the systems themselves, it is objectively verifiable, and nobody should ever type it by hand. A connector extracts it in minutes; a person entering it produces an inventory that is stale before it is finished.

Business metadata describes meaning. What this field represents in business terms, which glossary concept it belongs to, how sensitive it is, which regulation applies, who is accountable. This cannot be harvested, because it does not exist in the systems — it exists in people's heads, and getting it out requires conversations and, frequently, an argument. This is the expensive layer and the valuable one.

Operational metadata describes behaviour. When did this table last load, how long did the job take, did it fail, how many rows arrived, who queried it, how often, from where. It is generated continuously by running systems and it is the type most often ignored, which is a mistake: it is what tells you whether an asset is alive, and it is the fastest way to find the twenty tables that actually matter out of forty thousand.

The failure mode from conflating them is specific. A programme that treats metadata as one undifferentiated pile will try to have humans maintain all of it, exhaust the stewards on technical facts a connector could extract, and never reach the business layer — which is the only layer that required humans in the first place.

Harvest what can be harvested

The rule that saves the most time: if a connector can extract it, no person should be entering it.

The value of a catalog product is precisely that it reads systems directly. An organisation that populates it manually has bought a wiki with a licence fee. And manually entered technical metadata is worse than absent, because it looks authoritative and is wrong within a quarter.

The corresponding rule on the other side: do not expect harvesting to produce meaning. A connector can tell you a column is called cst_st_cd, is a two-character string, has eleven distinct values and is 3% null. It cannot tell you that it is the customer status code, that value 07 means dormant, and that dormant accounts are excluded from the active customer count. That is business metadata, it requires a person, and it is the whole reason data stewardship exists as a role.

A well-run programme spends almost no human time on technical metadata and almost all of it on the fifty to eighty concepts where meaning is contested.

Active metadata: the shift that matters

The market term for the change of the last few years is active metadata, and beneath the marketing there is a real distinction.

Passive metadata sits in a repository and waits to be read. Someone opens the catalog, searches, finds the definition, closes the catalog. It is a reference book, and like most reference books it is consulted rarely and by the people who least need it.

Active metadata is pushed into the places where work happens and triggers action. A schema change fires an alert to the twelve downstream owners. A column newly classified as personal data automatically inherits an access policy. A table that has not loaded in three days raises a quality incident. A query editor surfaces the business definition inline as the analyst types the column name.

The practical difference is adoption. Passive catalogs have a usage curve that peaks at launch and decays; active metadata is encountered by people who never chose to open a catalog. Gartner's Magic Quadrant for Data and Analytics Governance Platforms weighted active metadata and automation more heavily in its 2026 edition, extending evaluation into unstructured data, analytics models and data products — which is a reasonable signal about where the category is going, even though the axes it scores do not include on-premise parity.

When evaluating products, the question is not whether the vendor uses the phrase. It is which specific events the platform can react to, and which systems it can push into.

What metadata management actually requires

Six things, in the order they become necessary.

Connectors to the systems you actually run. Not the modern ones — the systems that hold the regulated data. Oracle, MS SQL, SAP, 1C, mainframe extracts and the specific core banking system in place. A catalog that cannot read your core system is decorative, and connector coverage is a hard requirement rather than a comparison point.

Scheduled re-harvesting. Metadata harvested once is a snapshot of a system that has since changed. Daily or weekly re-harvesting is what keeps it true, and a product that makes this awkward will produce a repository nobody trusts by month six.

A model that separates concept from column. One business concept, many physical columns bound to it, across systems and — in this market — across languages. Getting this wrong is the most expensive structural mistake, because retrofitting it after a thousand terms are catalogued means redoing them.

Classification, applied automatically where possible. Pattern-based detection of personal data, financial identifiers and other sensitive categories, reviewed by a human rather than invented by one. Under Azerbaijan's Law on Personal Data, you cannot meet obligations about personal data if you cannot say which columns contain it, which makes this a compliance capability and not a convenience.

Usage signals. Which assets are queried, by whom, how often. This is the cheapest way to prioritise everything else, and it is available from query logs from day one.

A path from metadata to enforcement. A classification that does not drive an access rule is a label. The value appears when the metadata layer and the control layer are connected.

Metadata is sensitive

A point that comes up in every on-premise security review and surprises people who have not run one.

A catalog does not store your data — it stores metadata about your data. That is the correct answer to the first question, and it is genuinely reassuring. But metadata about a core banking system is itself sensitive: table names, column names, row counts and profiling statistics describe your systems in considerable detail. A complete metadata repository is an excellent map for anyone who should not have one.

Treat the metadata repository as a system of the same sensitivity class as the systems it describes. That means access control on the catalog itself, and it is a substantial part of why catalogs in Azerbaijani banks and state institutions are deployed on-premise rather than as a hosted service — a constraint covered in data residency in Azerbaijan.

The multilingual problem

Rarely on a feature matrix, decisive in this market.

A typical large Azerbaijani organisation runs systems whose metadata is in three languages at once: an Azerbaijani-language core system, a Russian-language legacy application, and English-language modern infrastructure. The same business concept exists under three unrelated names — müştəri, клиент, customer — and no automated matching will connect them, because they share no characters.

This is a modelling problem rather than a translation problem. You are not translating labels; you are deciding that these three tables describe one concept, and that decision needs a person who understands the business in all three languages. The metadata model has to support one canonical concept carrying multiple language labels from day one, with physical columns from all three system generations bound to it.

Ask any vendor to demonstrate exactly that, and then to show search working from any of the three languages. Several products that claim localisation will show you a translated interface instead, which solves a different problem.

Key points

Three types: technical (structure, harvested), business (meaning, human), operational (behaviour, generated). Conflating them exhausts stewards on work a connector could do.
If a connector can extract it, nobody should type it. Manually entered technical metadata is worse than none, because it looks authoritative and is stale within a quarter.
Active metadata — events that trigger alerts, policies and inline definitions — is what drives adoption. Passive repositories peak at launch and decay.
Classification is a compliance capability: you cannot meet personal data obligations without knowing which columns hold personal data.
The metadata repository is itself sensitive. Table and column names map your estate in detail, which is a large part of the on-premise argument.
Multilingual metadata is a data model requirement, not a UI translation. One concept, many language labels, bound across all three system generations.

We deploy OvalEdge on-premise for organisations with exactly this profile. Related reading: what is a data catalog, business glossary and data lineage explained.

Metadata Management: Technical, Business and Operational Metadata