This chapter covers
- Applying design thinking to validate legitimacy of the data product candidate
- Selecting the person responsible for its development
- Forming the team that will develop it
- Defining the interfaces of the data product
- Designing the building blocks of the data product
- Complementing the data mesh with data contracts and 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’s 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, 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 nonfunctional aspects of data do not form an easily managed coherent whole with the data itself.