chapter five

5 Data as a Product

 

by Mariusz Sieraczkiewicz

This chapter covers

  • Validating whether the Data Product candidate is legitimate.
  • Selecting the person responsible for its development.
  • Forming the team that will develop it.
  • Defining the external interfaces of the Data Product.
  • Designing the building blocks of the Data Product.
  • Integrating the Data Product into the Data Mesh ecosystem.
  • Complementing the Data Mesh with Data Contracts & Sharing Agreements.

In the previous chapter, when discussing the Domain Ownership principle, we presented sample Data Products for the business capability Produce Content. We used the term Data Product without specifying what it is and how to create it. It is time to look at what it means to treat data as a product.

Often when thinking about data, we focus on technical aspects such as schema or data relationships. However, we need to remember that other related elements, such as schema description, domain description, the definition of access rules, metrics, and quality checks, are equally important. Often these individual elements are handled by separate, dedicated, specialized data teams. It turns out that, in reality, these non-functional aspects of data do not form an easily managed coherent whole with the data itself.

5.1 Applying Product Thinking

5.1.1 Product Thinking analysis

5.1.2 Data Product Canvas

5.2 What is a Data Product?

5.2.1 Data Product definition

5.2.2 Product not project

5.2.3 What can be a Data Product?

5.3 Data Product ownership

5.3.1 Data Product Owner

5.3.2 Data Product Owner responsibilities

5.3.3 An agile DevOps team as a base for Data Product Development Team

5.3.4 Data Product Owner and Product Owner

5.4 Conceptual architecture of a Data Product

5.4.1 External architecture view

5.4.2 Internal architecture view

5.5 Data Product fundamental characteristics

5.5.1 Self-described Data Product

5.5.2 Introduction to Metadata

5.5.3 Metadata as code

5.5.4 Data Product metadata