Is your data already a product?

People entering data in an Excel file.

By Michael Schroeder (ERNI Switzerland)

Do you know the difference between an email with data delivery and a self-service data product? This short article presents a brief case for data productization and why you need to lay the data-centered groundwork before building upon it.

Under the umbrella of digital transformation, many new services are being created, and many postulate or assume available data to be an enabler of the product. However, there are often overlooked catches:

  • Data needs to be understood by the consumers of that data
  • Data needs to be continuously available as an easily accessible self-service

What sounds easy actually requires that:

  • Data quality is constantly monitored and reported
  • Federated data governance is in place and implemented
  • Available data sets, tables, columns, and cell contents are clearly described; interpretation help is being supplied and ideally linked to a business glossary
  • A common interface can access available data sets

You may think these requirements are a handful, which is precisely the point. They cannot be fulfilled without treating your data as products.

Source : Image adapted from

Provide data-based services for yourself

Think about providing data as a product to user groups where the product is a collection of data sets. Handling a group of related data sets as a “data product” implies that the providers of the product and associated services address, above all, aspects of maintaining a digital product, including thinking about what parts of the company data are of interest to which user groups and at what level of detail.

Consider two scenarios with two different types of data products:

  • System-level data products: Suppose that an operative application – let’s call it the Producer – produces data about what the system is processing. The logs and data can be transformed into a system-specific data product, where we can analyse whether the system is working properly. The user group will need to have knowledge about how the application works and what specific technical fields mean.
  • Business-level data products: The Producer is part of a business process called Production. Therefore, the Producer’s data may contribute to a business-focused data product. While system-level data is structured according to how the Producer works, business-level data should be structured to represent Production. All technical fields should be removed, and data contents human readable. The business-focused data products are the ones that can then be used to calculate KPIs and be applied to use cases.

The two scenarios above describe how one original data set is processed into two different data products for two distinct user groups. Thus, they differ in content, structure, and description.

It is an investment, isn’t it? Yes.

The overall goal of supplying data products is to enable and foster data-driven innovation in your company by promoting simplified and controlled access. Caring about your data is caring about your KPIs, based on which you are steering your business.

As a long-term goal, some data may be sold as a product to other companies. Only what is discoverable, accessible, self-describing, interoperable, and trustworthy will have the desired effect on supporting innovation and digital transformation.

To make the opposite point: what is hindering data-driven innovation and concise KPI-based steering?

  • Merely supplying data dumps that are often static, stored locally and without meta data
  • Merely supplying hard-to-understand raw data, which can also be a potential security issue
  • Not having a clear rule on who may access specific data at which processing level

Ultimately, what is created with care and thought adds to the desired value of a product – be it a traditional product or a data product.

Are you ready
for the digital tomorrow?
better ask ERNI

We empower people and businesses through innovation in software-based products and services.