Can one set of data be used to deliver multiple Information Products?
Yes, one set of data can, and often should, be used to deliver multiple Information Products
Can one set of data be used to deliver multiple Information Products?
Yes, one set of data can, and often should, be used to deliver multiple Information Products. This is a core principle of an Agile Data Way of Working. It helps data teams reduce effort, increase speed of delivery, and ensure consistency across Information Products.
I think of it as DORO: “Define Once, Reuse Often”. Instead of reinventing the wheel each time, data that has already been collected, designed, and made consumable can be leveraged. With the heavy lifting already done, creating additional Information Products takes less effort and time.
Once structured into core business concepts, events, or details, data becomes a reusable data asset, not a one-off, ad-hoc dataset. For example, designed customer data used in a “Customer Churn” Information Product can also support a “Customer Lifetime Value” Information Product. Since the data engineering is already done, the focus shifts to how best to present the information, whether that’s a dashboard, report, or API.
Beyond a reduction in effort, data reuse ensures consistency. When multiple Information Products rely on the same definitions and data models, the risk of discrepancies between Information Products is reduced. If “Customer” is defined one way in a churn analysis, it will be defined the same way in a lifetime value analysis, preventing confusion and misalignment across users and stakeholders.
While data reuse is powerful, it does introduce challenges. When multiple Information Products depend on the same data, any structural changes to that data can create downstream impacts. A change to how the data for “Orders” is structured could affect both the “Customer Orders” and the “Top-Selling Products” Information Products. Data design trade-offs also come into play, as not every new Information Product will fit neatly into the existing data designs. Scalability is another factor to consider, as an expanding set of Information Products built on shared data requires careful coordination to prevent conflicts and unintended dependencies, especially when it comes to decommissioning Information Products that are no longer valuable or viable.