👉 The Data Product Dichotomy 👇 Data products can be divided into two categories: 1️⃣ Pure Data Products, aimed at facilitating access to the data they manage, 2️⃣ Analytical Data Products, designed to deliver functionality based on the data they handle. 🤓 In a pure data product, the more visible and easier the data is to consume (overt data), the higher the product's value. In an analytical application, the opposite is true: the less visible the data (covert data), the more valuable the product becomes. 🤔 Here’s the catch: the end user rarely needs the data. What they need are decisions supported by the data. So why does it still make sense to consider products where data is overt, like pure data products, as valuable? Can't we focus solely on products where data is covert, like analytical data products? 😉 My answer is in the comments… #TheDataJoy #dataProducts
Andrea Gioia - This is a great and necessary extension of the concept of Data Product, but I am wondering if Pure Data Products are a type of Data Product as you have defined it: "A data product is essentially a software application. Like any software, it’s a unit of management made up of interfaces, code, data, and infrastructure. A dataset on its own, even with clear ownership and published on a marketplace for easy consumption, isn’t a data product by itself." or a type of Digital Product as shown in the diagram in your Medium post? Since Pure Data Products don't have "specific features on top of it" how do they qualify as a Data Product?
What I’m observing, with some sad feeling of “Deja vu” is building of new ivory tower. Majority of discussions regarding “data products” seems quite abstract and misses two major factors: - a product is “something” that must satisfy certain needs (I.e. posses some qualities that increase total value of somebody’s business) - data are “byproduct” of business activity. Thus, for example, it hardly can be justified to build “data products” around operational data streams, that serve specific business purposes. (Like transactions posting). But on another side the accounts data could be quite valuable. (And here we run into topics of dimensionality, facts, reference data, etc.) So my point is: development of any product MUST start from determination of consumers and their needs (this product shall address) Otherwise we are at risk of wasting time and efforts. Projects that start out of FOBO or FOMO, and especially as kind of “fad” - are the riskiest. Shall I remind to fellow architects on how many “centralized data management” projects did not succeed only due to absence of justifiable business goals that shall bring in tangible benefits? Crucial question for product’s development: what will be ROI? (Besides of nice diagrams?)
Nice overview! Andrea Gioia how would you relate such a thing as existing data virtualization products to Pure Data Products? Just one of several ways to implement it or do you see them as complimentary to each other?
Partner and CTO at Quantyca & Co-founder at Blindata
1d📌 Why care about pure data products? https://medium.com/p/19faa223f91b 📌 The evolution of data products https://www.oreilly.com/radar/evolution-of-data-products/