Designing Data Products

By Prajwal Haniya

Techletter #102 | December 7, 2024

Working backward from the end goal is a core principle of software development.

It is highly effective in modeling data products.

When adopting a data mesh, the following questions need to be answered:

  1. Which data products should we build first, and how do we identify them?
  2. What are the boundaries of a data product?
  3. How big or small should it be?
  4. Which domain do they belong to?

What do you mean by data products?

Data products package structured, semi-structured, or unstructured analytical data for effective consumption and data-driven decision-making.

They cater to specific user groups by keeping the context of their consumption pattern for these analytical data.

They are the building blocks of a data mesh.

The data products must exhibit 8 characteristics:

Discoverable, Addressable, Understandable, Trustworthy, Natively accessible, Interoperable, Valuable on its own, and Secure.

Use cases are important before building a data product.

Without the constraints of a tangible use case, you won’t know when your design is good enough to move forward with implementation, which often leads to analysis paralysis and lots of wasted effort.

Below is an example use case:

As a customer relationship manager, I need timely reports that provide insights into our most valuable and least valuable customers. This will help me take action to retain high-value customers and improve the experience of low-value customers.

To address this use case, let’s define a data product called “Customer Lifetime Value”



If you need to develop one data product, you should consider what are all the other requirements/data products needed to build this.

By working backward, it leads us to build other data products like a complete view of the customer, returns, historical purchases, etc.

No single data product should be owned by multiple domains, as this can lead to confusion and finger-pointing over quality issues.

Resources


The above article is just a concise summary of this article. You can read it in depth here: https://martinfowler.com/articles/designing-data-products.html