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: Build vs Buy

Building a catalog looks cheap because the first version is. The four capabilities that decide it, the honest three-year cost comparison, and the two cases where building is right.

Every organisation with competent engineers considers building its own catalog, and the reasoning is sound at the point it is made. A catalog reads database schemas and stores them somewhere searchable. A good engineer produces a working version in a fortnight. Commercial products are expensive and full of features you did not ask for.

The reasoning holds for exactly as long as the requirement is "somewhere to look up table names". It stops holding at the four capabilities that turn a metadata store into a governance platform, and each of those is a multi-quarter engineering project on its own.

This article is about deciding honestly, including the cases where building is the right answer.

What the first version costs, and why that number misleads

Two weeks of one engineer produces something real: a connector to your main database, harvested table and column metadata, a search interface, a place to write descriptions. It works, people are pleased, and it is genuinely useful.

The number misleads because the first version is the cheapest 10% of the problem. The remaining 90% is not more of the same work — it is four different problems, none of which resembles the first two weeks.

The four capabilities that decide it

Column-level lineage. Not table-level — column-level, parsed from SQL, stored procedures and ETL definitions. This means writing or integrating a SQL parser that handles your actual dialects, resolves views, follows temporary tables through stored procedures, and copes with dynamic SQL. This is not a feature; it is a specialist product category, and it is where every build project underestimates by a factor of several. If your requirement is only table-level lineage, building is far more feasible — and you should be honest about whether that satisfies your auditor. It usually does not; see data lineage explained.

Connector breadth and maintenance. Your first three connectors are straightforward. The twentieth is a mainframe extract with a fixed-width layout and no metadata at all. Then every source system upgrades on its own schedule, and each upgrade is a maintenance event you now own. Commercial products carry this cost across their whole customer base; you carry it alone.

Access control and workflow. Fine-grained permissions on metadata, access-request workflow, approval routing, and audit of who saw what. This is ordinary enterprise software work, and it is a substantial amount of it — and in a supervised institution it cannot be skipped, because the metadata repository is itself sensitive.

Adoption features. Search that actually finds things, usage signals, inline definitions in the query editor, change notifications to downstream owners. This is the difference between a catalog people consult and one they encounter, and it is where the return on the whole programme actually comes from. It is also the part of a build that never gets prioritised, because it always looks less urgent than another connector.

If you need all four, building is a product development programme rather than an internal tool. Be explicit about that when the decision is made, not eighteen months later.

The honest three-year comparison

Buying costs licence plus implementation plus a fraction of an engineer for platform operation. Implementation for a scoped domain is measured in weeks with a value platform and in quarters with an enterprise suite.

Building costs two to four engineers continuously — not for a project, but permanently, because a catalog is a live system with connectors that break when sources upgrade. Add the opportunity cost of what those engineers would otherwise deliver, and the key-person risk: the catalog becomes the property of whoever wrote it, and their departure converts an asset into a liability.

The comparison usually favours buying, and the margin is wider than it appears at the outset because the build case is almost always priced as a project rather than as a product with an indefinite maintenance obligation.

There is a third path worth naming: open-source foundations. Projects like DataHub, OpenMetadata and Amundsen give you a substantial head start on the storage, model and interface layers. This is genuinely cheaper than building from nothing. It is not free — you own deployment, upgrades, connector gaps, security integration and the adoption features — and it is best understood as buying the first 40% and building the rest.

When building is right

Two cases, and they are real.

Your requirements are genuinely narrow and stable. You need searchable technical metadata for six systems, table-level lineage is sufficient, you have no regulatory lineage obligation, and you have engineers with spare capacity. Build it. A commercial catalog for this requirement is overspending, and the maintenance burden is small because the scope is small.

You have a requirement no product meets. A proprietary system nobody supports, an unusual security model, an integration into an internal platform that is central to how your organisation works. Then you build — but build only the part that is genuinely unmet, and integrate rather than reimplement everything around it.

What is not a good reason: "we can do it cheaper." That is true of the first version and false of the third year, and the difference is where the decision actually lives.

The build decision in a regulated Azerbaijani institution

Three local factors shift the balance, two toward buying and one toward building.

Toward buying: the lineage obligation. A supervisor asking how a submitted figure was calculated needs column-level lineage, harvested rather than drawn. Building a SQL parser that handles your Oracle dialect, your stored procedures and your legacy ETL is the single largest engineering commitment in this whole decision, and it is the one that is hardest to abandon halfway.

Toward buying: the talent market. There are not many engineers in Azerbaijan who have built metadata infrastructure, and a system built by two exceptional people collapses when they leave. A commercial product with local implementation capability is a hedge against that, and it is a real one.

Toward building: the deployment constraint. If the products you can actually deploy on-premise do not meet your needs, building becomes more attractive by elimination. This is worth testing before concluding it — several catalogs deploy on-premise as a first-class product, and the field is narrower than the cloud market but not empty. The comparisons are in OvalEdge vs Collibra vs Alation and OvalEdge vs Atlan.

How to decide in two weeks

A short, cheap process that produces a defensible answer.

Write down the four capabilities and mark which you actually need. If column-level lineage and access workflow are both required, the answer is almost certainly buy, and you can stop.

Cost the build as a product, not a project. Three years, continuous staffing, connector maintenance, and the adoption features. Compare that to licence plus implementation plus a fraction of an engineer.

Run a two-week spike on the hardest part. Point an open-source catalog at your worst legacy source and try to get column-level lineage out of it. Whatever you learn in those two weeks is worth more than any amount of estimation, and it is usually decisive in one direction.

Then decide, and write down why. In eighteen months someone will ask, and the reasoning is more useful than the conclusion.

Key points

The first version of a catalog is cheap and represents about 10% of the problem. The other 90% is four different problems.
Column-level lineage parsed from your real SQL is the capability that breaks build projects. Table-level lineage is far more feasible and usually does not satisfy an auditor.
Building costs two to four engineers permanently, not once. Price it as a product with an indefinite maintenance obligation.
Open-source foundations are a legitimate third path — roughly buying the first 40% and building the rest.
Build when requirements are narrow and stable, or when a genuine requirement is unmet by every deployable product.
Decide with a two-week spike against your worst legacy source, not with a spreadsheet of estimates.

We implement OvalEdge on-premise, and the governance assessment maps the estate first — which usually makes this decision straightforward. Related reading: what is a data catalog and metadata management.