Written by —
Jani Haakana, Data Engineer, tells you how dbt & analytics engineering boost ROI by bridging business-IT gaps with transparency, trust and faster insights.
Written by —
Transparency is key
In today’s data-driven world, businesses don’t just want access to data, they want actionable insights, fast. Although implementation speed is of importance (as time is money), stakeholders utilizing those insights are people and changing their decision-making behavior requires trust in the insights provided.
One aspect of creating that trust is transparency.
I’ve often faced the same issue in analytics projects:
How to successfully communicate business logic and its technical implementation between business stakeholders and developers?
As mentioned, stakeholders are required to understand their KPIs, and thus often ask what some specific figure is based on.
There are multiple common pain-points that make answering that question complex from a technical perspective. First of all, there are multiple data modeling steps between source data and the final output that the stakeholder sees.
Understanding the logic requires going through each step’s modeling, working your way from the end-product to the source(s), and studying changes made to the information along the way, effectively creating a data lineage. Furthermore, as developers’ documentation practices vary, discovering this data lineage might have some written information to support or has to be done solely based on the coded transformations.
dbt
Analytics engineering is a discipline that applies software engineering best practices; version control, testing, documentation, modular code, to data transformation. It turns messy raw data into clean, reliable, analysis-ready datasets using scalable, transparent workflows.
Currently, plenty of documentation tools with various documentation methods already exist. But what I’ve generally found is that the essence of that information isn’t only to have the most detailed information written down, it is to have easily digestible, up-to-date information available that is ready to be shared outside of developers.
What dbt provides is metadata-based model and column lineage. There are also many features that improve trust from the data accuracy point of view (model reusability, macros, data tests, source freshness etc.), but I want to highlight the recently renamed dbt Catalog (formerly dbt Explorer).
What makes the dbt Catalog particularly powerful is its seamless integration of lineage, documentation, and testing results into one visual interface. This means that both technical and non-technical users can trace how a specific KPI is built, see the upstream dependencies, and read curated documentation written by developers — all in the same place. This visibility dramatically reduces the time it takes to answer stakeholder questions and builds confidence in the output, as business users are no longer solely reliant on a developer to "explain the black box."
Example a of a model lineage
Data lineage was already an existing feature in dbt Catalog. It represents an information lineage on a model entity level and highlights both upstream and downstream dependencies. For example defining an intermediate model for a business customer can require utilizing dimensional information from multiple upstream models. But what might not be obvious from this lineage alone is to what extent those upstream models are utilized.
What goes beyond a basic data lineage is dbt’s recently launched column lineage feature, which offers similar information but on a more detailed (column) level. This supports developers to communicate not only to what entities a specific model is connected to but also already starts to answer how all of the model’s information is constructed.
For example from the picture below, one can quite easily comprehend that defining the measure in euros requires additional information to its source data. It also highlights, without needing to go through the code defining the calculation logic, what information was used in the currency conversion, and whether the information was transformed or renamed.
This could even be further improved by providing written documentation explaining exactly how all of the information is being utilized to define this specific field.
Example a of a column lineage
Not just a technical exercise
If you think about the role of information and knowledge management more holistically, the goal is to support an organization with improved decision-making and support it to achieve its business goals, both of which extend beyond the technical realm highlighted in this post.
But creating a shared language between business and data teams requires understanding business goals and aligning data strategy with them. Tools should be selected to support this alignment in a world where cross-team collaboration, evolving business environments and staff turnover are a reality and thus the value of knowledge sharing isn’t realized as often as it should be.
When the data models are version-controlled, well-documented, and visible to everyone — as in dbt Catalog — it surely helps a lot. Teams are no longer siloed in their own, department or country borders; they’re collaborating around a single source of truth. And this alignment pays dividends in terms of speed, quality, and trust: analytics cycles shrink, rework is minimized, and decisions are made with greater confidence.
Want to have a go at bridging the gap between data and decisions?
Start exploring dbt and the analytics engineering mindset — because faster, smarter, and more trustworthy data isn’t just a dream. It’s a model away.
