Data Contracts

Chapter 2. Data Quality Isn’t About Pristine Data

One of the early mistakes Mark made in his data career was trying to internally sell the concept of data quality on the merits of what pristine data could provide the organization. The harsh reality is that, beyond data practitioners, very few people in the business care about data—they instead care what they can do with data. Coupled with data being an abstract concept (especially among nontechnical stakeholders), screaming into the corporate void about data quality won’t get one far. It’s challenging to connect quality to business value, and thus it is relegated to being a nice-to-have investment. This dynamic changed dramatically for Mark when he stopped trying to internally sell pristine data and instead focused on the risk to important business workflows (often revenue-driving ones) due to poor quality. In this chapter, we expand on this lesson by defining data quality, highlighting how our current architecture best practices create an environment for data quality issues, and what the cost of poor data quality is for the business.

Defining Data Quality

“What is data quality?” is a simple question that’s deceptively hard to answer, given the vast reach of the concept, but its definition is core to why data contracts are needed. The first historically recorded form of data goes all the way back to 19,000 BCE, with data quality being an important factor for every century thereafter in areas ranging from agriculture, manufacturing, ...