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.

Data Catalog vs Dictionary vs Glossary

Three artefacts, three audiences, three failure modes. What each one is for, why organisations build the wrong one first, and how they fit together in a governance programme.

The three terms are used interchangeably in vendor material and in most internal documents, and they describe three genuinely different things with three different audiences. Getting them confused is not a vocabulary problem — it produces a governance programme that builds the wrong artefact first and then wonders why nobody uses it.

The short version. A data dictionary describes physical structure, for engineers. A business glossary defines concepts, for the business. A data catalog is the platform that holds both, connects them to each other, and makes them searchable across systems.

Two are documents. One is a system. That is the distinction that matters most, and it is the one most often lost.

The data dictionary

A data dictionary is a technical description of a specific database or system: every table, every column, its data type, length, nullability, keys, constraints and, if you are fortunate, a sentence about what it holds.

Its audience is engineers and analysts working directly with that system. Its scope is one system — a dictionary is a property of a database rather than of an organisation. Its content is objectively verifiable: the column is varchar(2) or it is not.

Historically, dictionaries were maintained by hand in a spreadsheet or a wiki page, which is why the phrase carries a slightly archaeological air. That maintenance model is also why they are almost always wrong: a hand-maintained dictionary is accurate at the moment it is written and diverges from the database with the next migration. Modern practice is to generate the dictionary from the system continuously, which is exactly what a catalog's harvesting does.

Its failure mode: describing structure with no meaning attached. A dictionary tells you cst_st_cd is a two-character code. It cannot tell you what value 07 means, and that is the thing the analyst actually needed.

The business glossary

A business glossary defines the concepts the organisation runs on — active customer, net exposure, delinquent account — in business language, independent of any system.

Its audience is the business: analysts, risk officers, product managers, executives. Its scope is the organisation rather than a system, because the whole point is that one definition applies everywhere. Its content is not verifiable but decided: there is no fact of the matter about what active customer means, only an agreement, which is why the glossary is where governance stops being technical.

A glossary term is properly a governed asset with an owner, a status, relationships to other terms and a decision record. The full treatment is in business glossary.

Its failure mode: definitions that are never bound to physical columns. A glossary that lives as prose is technically correct and operationally inert — nobody encounters it at the moment they need it, so behaviour does not change.

The data catalog

A data catalog is a system, not a document. It connects to source systems, harvests technical metadata automatically, holds the glossary, binds glossary terms to physical columns, computes lineage, applies classification, and makes all of it searchable across the estate.

Its audience is everyone: engineers find structure, analysts find meaning, stewards find ownership, auditors find lineage. Its scope is every system it can connect to. And critically, it is the artefact that makes the other two useful, because it is what puts a definition in front of the analyst who is looking at the column rather than requiring them to go and find it.

A catalog stores metadata about your data, not the data itself. Your data stays where it is — which is the first question in every on-premise security review, and the answer is genuinely reassuring, with the caveat that metadata about a core banking system is itself sensitive. The mechanics are covered in what is a data catalog.

Its failure mode: being treated as the deliverable. A fully populated catalog that nobody opens is a more expensive spreadsheet. The deliverable is a behaviour change — an analyst who checks the glossary before building a report, an engineer who checks lineage before altering a schema.

How they fit together

The relationship is easiest to see by following one field.

A column called cst_st_cd exists in the core banking system. The dictionary layer records that it is a two-character string, 3% null, with eleven distinct values — harvested automatically, no human involved. The glossary layer holds the approved definition of customer status, owned by the head of retail, with 07 documented as dormant and dormant accounts excluded from the active customer count — written by a person after an argument. The catalog binds the two together, so an analyst who searches for "active customer" finds both the definition and every physical column that implements it, in every system, in whichever of three languages they searched in.

Remove the catalog and the other two exist in separate documents that nobody cross-references. Remove the glossary and the catalog is a searchable dictionary — useful, and short of the point. Remove the dictionary layer and there is nothing for the definitions to attach to.

Which to build first

The sequence question, and it has a clear answer that contradicts what most programmes do.

Do not start with the glossary. It is tempting, because it is the part that feels like governance and requires no procurement. But definitions written before anyone knows what systems exist are definitions about an imaginary organisation, and definitions with nowhere to bind decay immediately.

Do not start with a hand-built dictionary. Cataloguing forty thousand columns by hand is a three-year project that demonstrates nothing and is stale before it finishes.

Start with inventory and automated harvesting. What systems exist, what is in them, who touches them — then let a catalog harvest the technical metadata for the systems in scope. That is four to six weeks of work and it produces a real map.

Then the glossary, narrowly. Fifty to eighty terms in one domain, drafted from existing usage, bound to the columns already harvested. The binding is what makes this phase different from writing a wiki.

Then extend by following the reports, not the schema. Assets that appear in regulatory submissions and executive decisions are where being wrong has consequences.

The full sequencing is in building a data governance program.

The Azerbaijani complication

One local factor changes the shape of all three.

A typical large organisation here runs an Azerbaijani-language core system, a Russian-language legacy application and English-language modern infrastructure. The dictionary layer therefore contains column names in three scripts. The glossary must carry one canonical concept with three language labels — not three parallel glossaries, which drift apart within months. And the catalog must support search that works from any of the three, resolving to the same concept.

That last requirement is rarely on a feature matrix and eliminates several products. Ask each vendor to demonstrate one glossary term with three language labels, bound to columns whose names are in three different scripts, and to search from each language. Products that respond by showing a translated user interface have solved a different problem.

Key points

A dictionary describes structure (one system, engineers, verifiable). A glossary defines concepts (whole organisation, business, decided). A catalog is the system that holds and connects both.
Two are documents; one is infrastructure. Losing that distinction is what produces the wrong build order.
Dictionaries should be generated continuously, never hand-maintained. A hand-maintained dictionary is wrong by the next migration.
Glossary definitions must be bound to physical columns. Unbound definitions are prose and change no behaviour.
Build order: inventory, then automated harvesting, then a narrow glossary bound to what was harvested, then extend by following the reports.
In this market, all three must handle three languages, with one canonical concept rather than three parallel glossaries.

We implement OvalEdge for organisations that need all three in one on-premise platform. Related reading: metadata management and what is data governance.

Data Catalog vs Data Dictionary vs Business Glossary