A data product is a product or service that is based on data and provides value to users. It combines data from various sources, analyzes it using algorithms, and presents the results in a user-friendly way, such as through visualizations, dashboards, reports, or as datasets or streams.
Examples of data products include:
Data products can be built for a variety of industries and purposes, and are typically powered by data science, machine learning, and artificial intelligence techniques. They enable organizations to make data-driven decisions, improve customer experiences, and gain a competitive advantage.
Open Data Product Specification (ODPS) is the standard machine-readable version of the above. A machine-readable document is a document whose content can be readily processed by computers.
The below usecases can be fulfilled with multiple vendor-specific and isolated solutions. While those isolated solutions have value, ODPS is a fullstack data product model which offers solutions to all below cases in one single package.
Many organisations fail to break down internal data silos, impeding data sharing and collaboration across an organisations business units. According to a study among 1000 business leaders and technology managers it was discovered that
Instead of exposing raw data to wide range of internal data consumers which are more and more non-technical business people, data is productized into easy to consume valuable data products. The productized layer of data is the key in increasing the internal transparency of valuable data. According to the Harvard Business Review companies that treat data like a product can reduce the time it takes to implement it in new use cases by as much as 90%, decrease their total ownership (technology, development, and maintenance) costs by up to 30%, and reduce their risk and data governance burden.
ODPS is a suitable protocol to break down the silos and internal organizational borders between business units. With the help of ODPS data sharing can be enabled with one transparent metadata model. Included standard business metadata elements express the data's purpose and value proposition. ODPS enables provision of a machine-readable clearly defined access to data. Data democratization is built on top of transparency and that is enabled by decoupling data from systems in order to provide easier and faster data discovery and comparison.
There is currently a clear trend towards the development of new trading platforms specializing in the commercial exchange of data. The data monetization global market is estimated to grow from US$2.1 billion in 2020 to US$15.5 billion in 2030 (compound annual growth rate of 22.1%). Data monetization failures can be attributed to the fact that many customers are not prepared to pay the required price for the data. One main reason is that customers do not recognize the value of the data before purchasing it because it cannot be fully disclosed prior to purchase (known as the ‘Arrow paradox’).
Customer wants to know the product and what it does in sufficient detail as to understand its capabilities or have information about the facts to decide whether or not to buy it. Exposing the full data product prior to the purchase is not a viable option for the provider, but there are other means to convince the customer.
The problem is closely tide to Customer eXperience (CX). Customers expect to know the quality level of data, see (and even try) how it can provide value, what are the conditions for use, how provider is handling governance, are there alternative or complimentary data products, and get the data in a way that fits their workflow.
ODPS has been designed to support building of a great customer experience. With below listed features of the ODPS customer is given a thorough understanding of the data product to ensure that it fits their needs and surprises are minimized to ensure a great Customer eXperience.
Since data is treated like a product for a good reason, it will change the way we should look at teams working with data. Data ownership transitions from centralized to decentralized, architecture migrates from monolithic to distributed, and accountabilities change as organizations move from a top-down to a federated governance model.
Data Product is built by talented people put together from multiple disciplines: tech, marketing, business, security, and legal. They have the ownership of the data product. The team is lead by “data product owner” who is accountable for the success of a domain’s data products in delivering value, satisfying and growing the data users, and maintaining the life cycle of the data products.
The above might look familiar if you are familar with the Data Mesh. Your enterprise data mesh driven journey will change the way data teams are organized and the way they work. This data product team needs something common to bind their efforts together.
ODPS 2.0 has been built on top of 4 aspects: business, tech, legal, and ethical use of data. ODPS offers a standard model to Data Product teams to collaborate. Each discipline contributes to the same data product and results are put together in a standard machine-readable metadata model – ODPS. The standard reduces need to reinvent the wheel by offering ready-made solutions based on acadmemic research and best practices applied in the data economy.
Open data has become part of the economic life of cities by providing access to data maintained and often monopolized by governments. So far metadata on open data has been defined according to DCAT.
DCAT standard was adequate for open data catalogs. Now that leading open data governments are productizing data (for example France and South Korea) and building data marketplaces, DCAT is not enough. DCAT is extensive standard but not suitable for marketplace purposes in which data known as open data will be served both as open data without costs, but also with commercial plans. Open Data offering has lacked quality as well. With ODPS a clear 7 indicator data quality framework is added to the metadata.
In addition to that, in order to take full advantage of open data, it must be treated as data product and be offered side by side with private sector commercial data. Data consumer CX requires that all data is easy to consume, discoverable and clearly with similar fashion described. Open data catalogs will be merged with data marketplaces over the coming years. This requires data as a product approach to be applied on open data as well.
ODPS provides extendable metadata model for open data driven data products. ODPS extends the DCAT model and offers means to bring open data to the data economy instead. So far open data has existed as an isolated island separate from data economy. Now we can use the same data product metadata model for open data and commercial data. On top of that monetization of open data is also on the radar of some leading nations.
When an organization is planning to publish multiple data products to the markets, it is obvious that all data products should have the same “look & feel” to ensure easier and cost effective maintenance as well as a great data product consumer experience. Creating a Data Product Design Guide is a must have. The Design Guide assists the Product Manager and the data product team to design and build consistent results. However, to ensure that Design Guide is applied, it must be tested.
In order to make machine-driven testing of consistency we need to have machine-readable specification of the data product – Open Data Product Specification. Next step is to apply concept called “linting” to the consistency testing.
In common meaning linting is the process of running a program that will analyze code for potential errors. Linting helps you follow standard data product guidelines. Standardizing data products can reduce clutter, help others understand it, and ultimately save time. Standards usually follow specific security measures. Thus, passing your data product through a linter could help reduce loopholes or vulnerabilities. With help of ODPS you can create linting rules and run consistency tests automatically.
ODPS provides machine-readable metadata model of a data product. Against it you can build data product linting tools to vefify consistency of data products in your portfolio.
"Product-market fit," writes startup coach and investor Marc Andreessen, "means being in a good market with a product that can satisfy that market." When an entrepreneur identifies a need in the market and builds a solution that customers want to buy, that's product-market fit.
Product mockups are frequently used to present a final product in a real-life context. In order to avoid waste and develop a solution before having a verification from the markets, you should use mocking / prototyping. This is where Open Data Product Specification becomes handy.
Open Data Product Specification defines the data product metadata in machine-readable format and from that you can generate product views for humans. An example would be a visual presentation of how this data product will be presented in a marketplace. Since you use ODPS you can have multiple versions and iteration is easy. Also A/B testing is rather easy.
ODPS provides machine-readable metadata model of a data product. Against it you can generate products views for product-market fit testing and also for A/B -testing. Open source version of "ODPS visualizer" or mockup tool is already in progress.
Release date: 1st April 2023
Description: Version 2.0 is currently the latest. You should adopt this one if you want to have all the above mentioned features.
Specification: See the full specification.
Source: See the source files.
Issues: See the issues.
Release date:
Description: Development version (dev) is for the development which aims for the next released version. Add your needs to this version, unless it's a bug in version 2.0 or 1.0. In those cases, use issue lists of version 1.0 and 2.0.
Specification: See the full specification, development version.
Source: See the source files.
Issues: See the issues.
Release date: 1st Feb 2022
Description: This is the MVP version and should not be used anymore. Preserved for legacy users not ready to use version 2.0
Specification: See the full specification.
Source: See the source files.
Issues: See the issues.