What “Data Governance” Actually Means: A Story From My Own Gift Shop

If you’ve spent any time around modern data platforms, you’ve heard the words. Data governance. Unity Catalog. Microsoft Purview. Collibra. They get thrown around in webinars and vendor decks until they start to sound like marketing noise rather than something a real business actually needs.

I run a small gift retail business called Gift & Bliss, currently one store, at IFC Mall. I also run a technology training and consulting company, Instrovate, where I teach people Azure, Databricks, and Microsoft Fabric for a living. For a long time, I understood these governance concepts technically - I could explain Unity Catalog’s architecture on a slide. But it wasn’t until I mapped it onto my own store, and imagined growing it to twenty stores, that the concepts actually clicked as business ideas, not just technical ones.

This article is that journey. If you run a business, any business, with more than one location or more than one sales channel, this is for you.

Where every business starts: one store, one system

Today, at Gift & Bliss, the operation is simple. Stock arrives, and I enter it into Zoho Inventory - SKU, barcode, quantity. When a customer buys something, I scan the barcode at the counter, and Zakya, our point-of-sale system, creates the invoice instantly. Customer details get captured right there too, if they choose to share them.

This is what’s called an OLTP system - Online Transaction Processing. It’s built for exactly one job: handle a transaction fast, reliably, and without losing data, even if ten customers are checking out at once. Zoho does this well. It’s not trying to be anything more.

And for a single store, this is genuinely enough. I can pull Zoho’s built-in reports for monthly sales or current stock, and that covers the basics.

Where the cracks start showing, even at one store

But even here, something is missing. Zoho’s reports are pre-built — they answer general small-business questions, not the specific ones I actually have. Which items have sat in inventory for ninety days without selling? What’s my real margin by category, after returns? Which customers bought once and never came back?

These aren’t things Zoho’s canned reports were designed to answer, because they require combining multiple things inventory age, sales velocity, customer repeat behaviour in ways no generic report anticipates. This is the first hint of a much bigger idea: the system built for running your business day to day is rarely the system built for understanding it.

Now imagine four stores, and a website

This is where it gets interesting, and where most growing retail businesses actually live.

Suppose I open three more stores across the city, and also start selling online through a website. Each store still runs its own Zoho Inventory and Zakya POS. The website runs on entirely different software Shopify or WooCommerce, say with its own customer accounts and its own product catalog.

Now a real, practical problem shows up. A customer who buys in-store at Store 1, then again at Store 3, then orders online - exists as three separate, unconnected customer records. Nobody can answer “what is this one customer’s total lifetime value” without manually piecing it together. The same problem exists for inventory: is an item marked “in stock” on the website actually available, or is it sitting on a shelf 20 kilometres away?

This is what the industry calls fragmented data silos and it’s not a technical inconvenience. It’s a business blind spot.

Step one: bring everything into one place

The fix starts with consolidation. Every store’s Zoho data, and every website order, gets extracted and landed into cloud storage , something like Azure Data Lake Storage (ADLS) or Amazon S3. Think of this as a large, cheap warehouse for raw data. Nothing clever happens here yet , it’s just a durable place for everything to land.

Step two: turn raw data into real answers

Raw files sitting in storage don’t answer questions on their own. This is where a platform like Azure Databricks comes in an OLAP system, Online Analytical Processing, built for the opposite job Zoho does. Where Zoho is optimized for one transaction at a time, Databricks is optimized for scanning millions of rows across time and locations, joining tables, and surfacing patterns.

Once your four stores’ invoices and inventory, plus your website orders, all live as clean, structured tables in Databricks, you can finally ask the real questions. Which store has the best sell-through on your best-selling category? Which customers shop across more than one channel? What’s dead stock, and where is it sitting?

This is the layer that actually turns data into decisions.

Step three: who’s allowed to see what

Here’s where it gets important, and where “governance” stops being an abstract word.

Once you have unified tables covering every store’s sales and every customer’s data, a new question appears: who should be allowed to see all of it? A store manager at Store 2 probably shouldn’t see Store 4’s revenue. Nobody except a couple of trusted people should see customers’ raw phone numbers.

This is exactly what Unity Catalog does inside Databricks. It’s not a separate storage system , your data still physically lives in the lake. Unity Catalog is the governance layer sitting on top of it. Concretely, it lets you:

•Enforce fine-grained access : a store manager’s login only returns rows from their own store, even though the underlying table holds all four stores’ data

•Mask sensitive columns dynamically : the same table can show full customer phone numbers to your ops team, and hide them from anyone else, without maintaining two separate copies of the table

•Track lineage automatically : if a number in a report looks wrong, you can trace it backward through every transformation to the exact source table and column it came from, with zero manual documentation

•Log every access : who queried what, and when, automatically

•Make data discoverable : a new hire can search “customer” and find the right table instead of asking around

None of this requires trusting people to “be careful.” It’s enforced automatically, every time, at the moment someone runs a query.

Step four: the part most people get wrong : Purview and Collibra

This is usually where confusion sets in, so let’s be precise.

Unity Catalog’s reach stops at the edge of Databricks. It has no idea that your website has its own separate customer database, or that a staff member has a spreadsheet of walk-in leads sitting on their laptop. The moment your data lives in more than one system , which, realistically, happens the moment you have a website alongside your stores , Unity Catalog simply can’t see the rest.

This is exactly the gap tools like Microsoft Purview or Collibra are built to close.

Here’s what actually happens, mechanically. You connect each system to Purview or Collibra - Databricks, your website’s database, even a shared spreadsheet if that’s genuinely where some data lives.

Once connected, the tool scans each system on its own schedule, inspecting tables, columns, and files. It doesn’t rely on you naming things helpfully - it uses pattern recognition to detect that a column shaped like a phone number is a phone number, even if someone named it something obscure.

The output is a single, searchable, always-updated map: “Customer phone number exists in: Store databases, website backend, and this one spreadsheet on SharePoint” - across every connected system, refreshed automatically as new stores or channels get added.

One thing worth being precise about: Purview and Collibra don’t enforce anything. They don’t block access the way Unity Catalog does. Their job is discovery and classification , telling you where sensitive data lives, everywhere, so nothing gets missed. Actual enforcement still happens separately, inside each system: Unity Catalog for Databricks, the website’s own permissions for its database, and so on.

Why any of this actually matters, in plain terms

At one store, you are the governance system. You personally know where the customer list lives, and you trust yourself with it. That doesn’t scale.

At twenty stores, with staff at every location and a live website, a very real, expensive question eventually arrives , usually from a customer, a regulator, or a bank: “Where does this customer’s personal data exist, across all your systems, and can you prove you can delete it?”

Without the tools described above, answering that means someone manually checking every store’s software, the website, and every spreadsheet in circulation , by hand, hoping nothing was missed. With them, the answer already exists, continuously updated, because the scanning and classification happen automatically in the background.

This is also, directly, what GDPR Act and similar data protection regulations elsewhere require businesses to be able to demonstrate. “We were careful” isn’t an answer a regulator or a customer complaint will accept. A system that can actually show where personal data lives, and prove it’s protected, is.

The honest truth: this isn’t a problem you solve once

It would be convenient to say “install this tool and the problem goes away forever.” That isn’t quite right, and I think it’s worth being honest about it.

New stores keep getting added. Systems get replaced. New sales channels appear , a marketplace listing, an Instagram shop. People join and leave your team, and access needs to be updated continuously, not set once. Governance isn’t a project with an end date. It’s an ongoing discipline that has to scale alongside the business.

What tools like Unity Catalog, Purview, and Collibra actually give you isn’t a permanent fix , it’s a way to make that ongoing discipline manageable, instead of a manual, error-prone exercise that gets harder every time the business grows. At one store, governance lives in your head. At twenty stores, it has to live in a system, because no single person can hold it there anymore.

Where this fits into skills and careers

If any of this resonated because you’re in retail, ecommerce, or operations, that’s the point of this piece.

But if you’re on the technical side, wondering how to actually build and operate this stack, this is exactly the skill area behind three certifications I train and consult on at Instrovate:

• DP-750 : Azure Databricks Data Engineer Associate, for building and governing the Databricks and Unity Catalog layer itself

• DP-700 : Microsoft Fabric Data Engineer Associate, for the equivalent pipeline and engineering work inside Microsoft Fabric

• DP-600 : Microsoft Fabric Analytics Engineer Associate, for the analytics and semantic modelling layer on top

If you’re a business owner trying to make sense of this for your own data, or a professional looking to build these skills, feel free to reach out. We deliver Microsoft Fabric & Databricks Consulting & Certification training on exactly this stack, grounded, as you’ve just read, in real operational problems, not just slideware.

You can email me at support@instrovate.com or directly at support@instrovate.com and can whatsapp us at +971 50 603 2177

Also If you found this article useful, I’d genuinely like to know which part landed, the retail example, the Unity Catalog vs. Purview distinction, or the “governance is ongoing, not a fix” point. Reply or comment, I read all of them.