On-Demand Webinar · 1 hr 2 min

Real-Life Examples to Inspire Your DataOps Initiative

Chris Bergh on where to start a DataOps initiative: a Theory of Constraints framework for choosing a first project by finding the bottleneck, and three companies' examples of how they kicked theirs off. Recorded January 2020; updated August 2026.

Presented by Chris Bergh

What you'll learn 7 points
  • The starting-point framework is the Theory of Constraints: improvements not at bottlenecks are illusions. Find the constraint in your analytic process, pick one, and iterate — rather than launching a broad DataOps programme.
  • Three constraints cover most teams: too many errors ('I don't want to learn about data quality issues from my customers'), slow deployment ('I don't want to break production when I deploy'), and poor team coordination.
  • An American transportation company attacked errors first, orchestrating a toolchain spanning Oracle, SQL Server, Hadoop, S3 and Redshift, with Informatica, PySpark, Nifi and Kafka, across on-prem and AWS, and six separate owning teams. Tests validated streaming data was fit for purpose and alerted to Jira, email, and Slack.
  • A European telecom took four months to move an idea into production through a four-stage manual deployment, with almost all testing done by hand. Dozens of automated tests embedded in the pipeline brought deployment down to minutes.
  • A consumer goods company used orchestration to hand ML models from data scientists to IT, so updates to a model stopped being a crisis and expensive data science time went back to creating rather than operating.
  • Automated tests serve a dual purpose: data tests and monitoring in production, and regression, functional and performance tests in development. Quality the customer receives is a function of data, code, and environment.
  • Measure the process, not just the output: production error rates, data provider error rates, SLAs, deployment rates, release environments, and test coverage. Analytic teams are typically not analytic about their own work.

Slides

58 slides

Questions from this session

Where should a team start with DataOps?

At its bottleneck, using the Theory of Constraints — improvements not at bottlenecks are illusions. Ask where the constraints are in your analytic process and what stops you creating new insight, then pick exactly one and iterate. Starting everywhere at once is how DataOps initiatives stall.

What are the most common constraints?

Three: too many errors, slow deployment, and poor coordination between teams. Each has a recognisable complaint attached — not wanting to hear about data quality problems from customers, not wanting to break production on deploy, and the standing feud between data science and analytics teams.

How did a company reduce errors in a complex toolchain?

An American transportation company running both streaming and batch — Nifi, Kafka, Informatica, an ESB, across Oracle, SQL Server, Hadoop, S3 and Redshift, on-prem and AWS, owned by six different teams — built end-to-end orchestration with tests that validated data was fit for purpose, so the assumptions made downstream stayed true. Failures alerted into Jira, email, and Slack rather than being discovered by customers.

How much can automated testing speed up deployment?

For a European telecom, from four months to minutes. Their existing process was a four-stage manual deployment with almost all testing done by hand. Dozens of automated functional, regression, unit and performance tests embedded in the pipeline removed the manual verification that made each stage slow.

Isn't deploying faster riskier?

Speed without tests is riskier. The session is explicit that moving code quickly into production is scary — the fear is making a mistake and having the business act on wrong data. What makes speed safe is that the tests proving correctness run automatically on every move between environments, so faster deployment also means more checks per change, not fewer.

How do you measure whether DataOps is working?

By instrumenting the process itself: production error rates, data provider error rates, on-time delivery within SLA, build time, deployment rates between environments, test coverage, and per-project productivity. The pattern to look for is error rates declining while deploys and automated test counts rise.

Where to go next