Skip to content

Why Data Engineers, Scientists, and Analysts Need Data Observability.

Data has become the lifeblood of most organizations. Yet, despite using data almost daily to make critical business decisions, few organizations have complete visibility into the health and usage of their data. Moreover, as the acceleration of data usage has increased, so too has the complexity of data systems, increasing the risks of data-related issues and making it even more difficult to identify and resolve issues related to data quickly.

This article will discuss specific use cases of how Data Observability can help data engineers, scientists, and analysts in their daily jobs. But first, let’s recap what Data Observability is and how it works.

Introduction to Data Observability

Starting from the definition of observability, which is the ability to measure the internal states of a system by examining its outputs, Data Observability is a specialization that focuses on the measurement of the data facet of the system's internal states. Data Observability uses three types of telemetry data — metrics, logs, and traces — to provide deep visibility into data systems and allow teams to get to the root cause of a multitude of issues and improve the data usage trustworthiness and efficiency.

There are many ways to introduce Data Observability, but most do not scale very well. Consequently, we believe that taking a Data Observability Driven Development (DODD) approach is the best way for data engineers and data analysts to apply Data Observability in an effective and sustainable manner.

As part of a DODD approach, there are three principles that Data Observability must follow:

  1. Contextual observability: Data Observability should provide information on the data itself and the context of its usage.

  2. Synchronized observability: Data Observability should be performed at the exact moment of data usage to avoid any lag between monitoring and use.

  3. Continuous validation: Unlike tests, Data Observability should be part of the entire development lifecycle, including production.

If you wish to learn more about Data Observability and Data Observability Driven Development, feel free to download our O’Reilly Report “What is Data Observability?”.

Next, let's look at how applying Data Observability (and DODD) can help data engineers, scientists, and analysts resolve several data issues and challenges they currently face.

Use Cases

#1 - Reduce Time To Detect (TTD) and Time To Resolve (TTR)

In most organizations, when data issues arise, data engineers spend a lot of time trying to figure out what the problem is, where it originated, and which applications (python, ETL, SQL, ...) need their attention to fix the issue. And every step of the process takes a lot of time. First, the data engineer must check the entire data environment, including any connection to the data. They also have to look at the data itself—how was the data built, how is it being used, is there any missing or inaccurate data? Finally, they also need to check the data application and analyze the code to see if it's creating the issue. Unfortunately, the time spent on these investigative tasks and trying to resolve the issue is time data engineers aren't spending on other high-value projects.

Data Observability and DODD reduce the Time To Detect (TTD) as data engineers are alerted in a timely manner because any data usage issues are observed in real-time (aka synchronized observability). The Time To Resolve (TTR) is also much faster because there is visibility into the entire system thanks to contextual observability, which enables data engineers to quickly fix issues in order to reduce their impact on business users.

Overall, faster TTD and TTR mean that data engineers have more time to focus on other data projects, enabling them to get those to market faster. Additionally, because there is higher reliability in the data, business users have greater confidence in that data.

#2 - Improve communication and ensure business users get "good" data

Data quality issues can quickly create a lack of confidence in the data for business users. Therefore, data engineers need some understanding and knowledge about the data that is delivered to business users in order to guarantee that it meets their expectations.

However, most of the time the data engineers creating the application don't know what KPIs are important to the business user. This makes it difficult to validate data quality in production and often results in the business user receiving data that doesn't meet the business user's needs, such as having fresh data every hour.

While Data Observability provides visibility into the entire system, the benefit of DODD is that it creates upfront, continuous communication between data engineers and business users. Given that there is a mutual interest to include the right metrics and KPIs about the data when developing applications the business is requesting to use, having communication at the start of the process is extremely helpful. But it's also important that this communication is continuous because KPIs may evolve as the business users need to address business updates or market changes.

Making communication about KPIs and SLAs a routine part of the project description and a step in the maintenance and issue-resolution process makes it easier for data engineers to adopt and integrate data KPIs and enables accountability for both data teams and business users.

#3 - Need documentation solutions to keep engineers in the loop

Currently, most organizations already have solutions (e.g., data catalog) that focus on documentation for business and data governance teams. While these solutions offer a good view of data governance for the business unit, they don't provide the type of technical view of the data that would be useful for data engineers. In fact, the documentation can be almost useless, which means the data engineers are often wasting their time when required to write documentation for these solutions.

Data Observability automates the documentation that data engineers care about—how the data is used in run-time. For instance, Data Observability logs and traces the lineage, metadata, profiling (stats), and data usage (apps, jobs, reports, etc.) throughout the system.

DODD adds additional value by using contextual and synchronized observability as well as continuous validation to keep data engineers in the loop while limiting the impact on the business. DODD also eliminates manual documentation for data engineers, which means they can spend less time on documentation and more time on other high-value data projects.

#4 - Avoid upstream data issues from breaking data models and dashboards

Data analysts and data scientists use machine learning models to help predict churn, offer product recommendations to customers, and analyze and predict the performance of the latest marketing campaign or the business's financial outlook. However, their models are dependent on receiving quality data from the data engineering team. Upstream data issues, such as a missing table or row, can jeopardize their work.

As the data analyst's role is to gain insights into how the business is working, they do not want to spend time identifying and fixing issues with the data. And they definitely don't want to have data models spit out incorrect insights that could lead to potentially poor business decisions.

The benefit of Data Observability is that it saves data teams time in finding and fixing data issues and even allows them to do so proactively. Thus, they can ensure higher reliability of the data and have greater confidence in the insights from their analytics and machine learning models.

#5 - Avoid undetected model drifts

While data scientists need Data Observability to make sure that the data that is consumed by their models meets their expectations, they can also benefit from Data Observability when it monitors the data produced by the models.

Indeed, it often happens that AI or ML models produce unexpected results despite being fed good data. In these instances, the issue is actually within the models and not the data consumed. For example, if the environment has changed such that the model no longer meets the expected performance (e.g., accuracy, precision, etc.), then the insights will no longer be valid. Thanks to Data Observability, however, data scientists can be alerted in a timely manner that the insights produced do not respect the quality indicators that they set. They can then take the appropriate actions to correct their models.

Ownership of DODD

Within any data-driven organization, several teams are involved in the use of data. The exact structure and types of teams may differ in every organization (i.e., the analytics teams might be split across the data and business teams in some organizations), but there are typically four primary teams involved in managing, analyzing, and utilizing data. Each team has different responsibilities as well as different dependencies on other teams to ensure they can manage their responsibilities.

Type of team Responsibilities Dependencies
IT team Build and maintain the platform; manage security and compliance  
Data team

Build the data pipelines and manage the data from deployment to production

Rely on IT to build the platform and set up the tools to monitor the pipeline and systems, including implementing Data Observability tools
Analytics / Data Science team Build analytics and AI/ML models that can analyze and interpret data for the business team's use cases Rely on the data team to build the pipeline to generate the data they will be using in their models
Business / Domain team Sponsor use cases and use data analysis to make business decisions Rely on the other teams to ensure data and analyses are accurate


Data engineers are primarily responsible for implementing Data Observability through a DODD approach. They must introduce Data Observability into data applications as the time they do the development and allow for continuous validation of the data usage in the production environment.

Users, including data analysts and data scientists, must have the accountability and responsibility to continuously communicate with data engineers about KPIs and any issues they see arise with the data. DODD, which gives them contextual and synchronized visibility into the state of data and ensures continuous validation of the data, makes this much easier to do.

Benefits of DODD

Combining Data Observability with DODD principles offers multiple benefits to not only data engineers and analysts but to everyone. These benefits include:

  • Improved analysis, troubleshooting, and prevention
  • Stronger involvement and accountability
  • Easier maintenance
  • Automated complete documentation
  • Higher reliability

These benefits, combined with the ability of data teams to scale up data usage within the organization with confidence, allow organizations to finally get the full value from their data, resolve any issues quickly, and trust that the data they're relying on to make critical business decisions is accurate.

To learn more about DODD and its benefits, don't hesitate to read our post on DODD or contact our team.