EdgeRed

Home Technology Why we keep implementing KADA for data governance

Why we keep implementing KADA for data governance

Data governance tooling has a credibility problem. Most organisations have tried it. A catalogue that nobody updates. A lineage map that’s six months out of date. A data quality dashboard that tells you something is wrong but not what depends on it.

We’ve implemented KADA across several clients now, and it keeps earning its place for one reason: it surfaces what’s actually happening in your data environment, automatically, without requiring a team of people to maintain it.

Here’s what that looks like across the features we use most.

Usage monitoring – know what’s actually being used

One of the first things we used KADA for was a dashboard rationalisation exercise. The client had accumulated hundreds of Tableau dashboards over the years. The question was which ones to keep.

KADA answered it cleanly. We could see exactly which dashboards were active, how often, and who was using them. That alone made the decommissioning exercise tractable. But the more valuable find was the duplicates – dashboards tracking similar metrics, calculated slightly differently, sometimes pulling from different sources. Nobody had flagged it because nobody had visibility across the full set at once.

That kind of silent inconsistency is common in mature data environments. When two reports show different numbers for what looks like the same thing, people stop trusting either of them. KADA made it visible.

Usage monitoring also changes how you approach migrations. Rather than guessing which data assets are critical, you can see which ones are heavily used, by which teams, and what they feed into. That’s a much more confident basis for migration planning than asking stakeholders to self-report.

Intelligent lineage – trace it back to the source

Most lineage tools work well within a single platform. KADA works across them. We’ve used it to trace data flows from Oracle through to Snowflake through to Power BI – field level, with calculations and logic visible at each step.

The lineage map updates automatically as data flows change, so you’re not maintaining it manually. And because it spans the full stack, when something looks wrong in a dashboard you can navigate back to the source without manually following the trail across systems.

For data migrations, this is particularly useful. You can see exactly what flows where, what depends on what, and which assets move together. That changes how you sequence the work.

Data governance – prioritised by what matters

KADA’s governance features are built around usage data, which is what makes them practical rather than aspirational. Instead of trying to govern everything equally – which means governing nothing well – you can focus on the data assets that are actually critical and heavily used.

PII tagging is automated. Data quality results from Great Expectations surface directly in KADA, so the team sees quality, lineage, and usage in one place rather than switching between tools. When something fails, the right people are notified with enough context to act – they can see what’s broken, what it feeds into, and who uses it.

We’ve also used KADA’s impact assessment capability on migration projects – automatically identifying who gets notified when a data asset changes, based on who actually uses it rather than a manually maintained contact list.

Why we bring it in early

The temptation is to treat governance tooling as something you add once the platform is built. We’ve found it’s more useful the earlier you bring it in. On migration projects especially, having lineage and usage visibility from the start changes how you plan – you’re making decisions based on what’s real, not what people think is happening.

KADA connects to your existing sources and gives you a working view of your data ecosystem within an hour. That low barrier to entry is part of why we keep recommending it. Governance tooling that takes months to stand up tends not to get stood up.

If you’re sitting on a complex data environment and not entirely sure what’s being used, what’s trusted, or what’s connected to what – it’s worth a look. We’re happy to walk through how we’ve implemented it.

This blog was written by Monica Ly.

About EdgeRed

EdgeRed is an Australian AI and data consultancy, part of The Omnia Collective group, with teams in Sydney and Melbourne. We build things that work in production — agentic AI, machine learning, data engineering, and Microsoft Fabric implementation. 250+ projects. 100+ clients. 100% Australian on-shore team.

Subscribe to our newsletter for practical data and AI insights, straight to your inbox.