Data Products: where to start to understand them

Simply put, Data Products make a company’s data easy to find, easy to analyze, easy to share and easy to control. The challenge is to design these Data Products so that they are easy to build, protect and manage. In this article we look at some of the keys to designing a Data Product to deliver business value.

There are two categories of Data Products:

• Those that support decision making: They are mainly used to extract information from essential data. They can provide access to raw data (the user processes the data to generate information) or to derived data (a large part of the data is cleaned, and the user only has access to this cleaned data). 
• Automated decision makers: They make decisions on behalf of the user. In this case, the user’s role is limited to monitoring and adjusting the results provided.

However, we also find data products that, when combined, generate hybrid tools that combine both models. For example, if we think about the combination of Google Analytics with Google Ads, we see that they provide an easy and simple way to analyze our user journey, while offering us segments that we can target through Google Ads.

Going into more detail on its composition, within a Data Product we differentiate between four layers:

• Raw data layer: Where we find the most basic and fundamental data that are necessary to create the product and make it work. 
• Data access layer: Provides the necessary data to the next layer to make the right decisions based on it.
• Business logic layer: :Here we find the configurations of the knobs and switches. This layer controls the output of incoming data from the previous layer. For example, let’s think about the Netflix recommendation tool. If we choose the option “do not show products that I have already seen in the recommended ones”, this layer is in charge of managing that they do not appear.
• Feature or Interface Layer: This layer serves us as a front-end for all the data and data-driven decisions we have made.

It should be noted that the data does not remain static in these layers, but moves and flows through them. These layers are configured vertically, with the interface at the top and the raw data at the bottom. To explain this, let’s return to the example of a recommendation product. This type of Data Product will have an API implemented in the interface that will go from the business-logical layer to the access layer and the raw data layer. From the business-logic layer, the data output will be filtered thanks to the system of commands and switches we mentioned before, and, again, this data will go down through the other two layers to retrieve the product images and other presentation content.

We can also point out several factors in the architecture of Data Products that cause them to have certain features:

• Interoperable: interoperable interfaces meet the user’s consumption needs. Interoperability is the ability of an information system to share data and enable information exchange.
• Limited: in the sense that Data Products store any type of data that has a clearly defined boundary and owner.
• Self-aware: they can automatically capture changes and information about themselves so that they can be distributed within the Data Product itself, to other Data Products or to stakeholders within the enterprise.
• Verifiable: each Data Product contains its own registry that publishes its metadata, owner information, policies and any other additional information. This registry is the “one-stop shop” for us to find, consume, share and govern the data and information handled by a specific Data Product.
• Secure: both when they are at rest and when they are in motion.
• Historical and temporal: changes in the state of the data are stored and managed in an immutable record. 
• Compatible: a Data Product has “ports” that allow all data to be consumed or received. The information and all the changes that occur must be able to be communicated through massive or real-time channels.

Data products are gaining traction in organizations looking to generate ROI and looking to use data in a scalable and sustainable way. Refocusing the data strategy towards this model is the first step, building it properly is the next, and requires deep data usage knowledge and experience.