Top-down Versus Bottom-up Data Quality Approach

Have you heard of the discussion comparing Top-Down versus Bottom-Up approaches to data quality implementation? In this blog post we’ll introduce the concept and outline some considerations for DQ professionals. Subsequent blogs will dive deeper into some of the activities of each approach that use the Conformed Dimensions.

 

Side-by-Side Comparison

Top-Down Approach

Bottom-Up Approach

Business process focus

Data focus

Conducted by business teams and consultants

Conducted by IT teams or specialized DQ consultants

Focused on setting the correct objectives and areas of priority; a vision with direction

Focused on exposing instances of likely wrong data that needs associated verification of requirements and standards

Conceptual

(deals with problem across the business generically)

Concrete

(deals with problem in one location)

Based on customer/stakeholder defined issues 

(e.g. I can’t compare costs of selling the same products in different countries)

Based on technically defined issues

(e.g. Cost UIDs and labels are different in each country so I can’t easily query like costs from two data sources and match on IDs or names in order to compare sales of products between countries)

Issues list created by asking customers/stakeholders and prioritized by them (loudest voice)

Issues are identified by:

  1. Reviewing existing backlog of technical tickets/defects
  2. Profiling data based completeness (Null/Not Null) or validity (list of values) rules

Top-down Approach:

In general, the Top-down approach uses a more business and process focused orientation. Typically, top-down approaches use the voice of the customer to identify the most urgent issues relating to data. The members of the team conducting the analysis are typically business department members or consultants. They typically start with a conceptual issue that is broad and then require more detailed definition all the way to root cause analysis (RCA). At the point that the 5 Whys (process of asking why something happens at least five times) have exposed a potential reason for the issue, you begin to conduct root cause analysis that often leads to technology team involvement and data queries.

 

It should be said that there is no judgment about which approach is better, so it should be said that the bottom shouldn’t be thought of as inferior in any way. However, it must be used at the right time and in conjunction with the Top-down depending on the executive leadership’s objectives for the company and current situation.

 

Bottom-up Approach:

This approach usually focuses on the actual data that documents a business issue. It is often started by technical teams in IT because they have first hand knowledge about where the data is located and data transformation rules in pipelines that feed the reporting or warehousing systems. Sometimes technical managers create a business case for clean-up efforts or data scrubbing based on data profiling (review of the completeness or validity of business critical data). These efforts rely on exposing existing issues often identified during root cause analysis of existing defects/tickets that application teams manage.

 

At this point you’ve probably realized that there isn’t a right and wrong way to use these approaches. You are right, they both are required and data quality leaders must be comfortable using them as needed. 

 

What does the DMBOK2 say regarding these two approaches?

“Typically, a hybrid approach works best – top-down for sponsorship, consistency, and resources, but bottom-up to discover what is actually broken and to achieve incremental successes.”

 

In other words, in the steady state data quality management environment you’ll use both approaches. In the next blog we’ll discuss how the Conformed Dimensions are used for each of these approaches.

Did you enjoy this blog? If so, help out by taking the annual Dimensions of Data Quality Survey open now!