avatarHanzala Qureshi

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

2353

Abstract

easier/better).</p><p id="9eb4">Examples of Data Products are your C-suite dashboards, a model that helps you predict when a customer will churn, data for sales leads that allows your team to sell more services, etc.</p><p id="cb52">But that's just the Data Products part; what about "treating as a product"? Well, your dashboard is your front end. You need underlying metadata, transformations and tools to make the dashboard possible. And when you package all that up into one operational item, it is your Data Product.</p><p id="4a52">And when that Product meets certain principles like <a href="https://www.starburst.io/blog/data-mesh-and-starburst-data-as-a-product/">DATSIS</a>, it is now productised. <b>D</b>iscoverable (it can be found in a marketplace), <b>A</b>ddressable (readily available tools can use it), <b>T</b>rustworthy (quality/lineage is known and limitations understood), <b>S</b>elf-describing (all information related to is available), <b>I</b>nteroperable (it conforms to product standards), <b>S</b>ecure (it has relevant access controls applied)</p><h1 id="757f">Great — How Do I Get Started?</h1><p id="10b5">Most of today's organisations will have invested in their data, meaning this will not be a greenfield implementation.</p><p id="276a">Treating Data as a Product requires particular basic data management and infrastructure requirements. You can only productise something if you trust it enough. Implementing a solid data quality framework and data ingestion and retention framework, amongst other things, would help ensure you can truly market Data as a Product in your organisation.</p><p id="1490">You can start with 1 or 2 essential data products to avoid boiling the ocean. For example, start with the CFO dashboard, which shows customer churn leading to poor revenue outcomes.</p><ol><li>CFO Customer Churn Dashboard — Data Product</li><li>Head of Performance Reporting — Data Product Owner — sets the vision of the product roadmap and is accountable for ensuring CFO requirements are met.</li><li>Customer Domain related Data — Data Architect/Analysts — supports the Data Product Owner in creating relevant models designs to power the Product.</li><li>Customer Domain Data Team — Data Engineers — creates the underlying data transformation code to meet the design set by the Architect and vision set by the Pr

Options

oduct Owner.</li><li>Centralised Platform Team — Infrastructure Engineers — ensuring the platform & tool required to run the Product are maintained continuously</li><li>Data Product Marketplace — a centralised tool where Products, all their related metadata and feature information are published</li></ol><p id="a282"><b>See Part 1:</b></p><div id="fd8a" class="link-block"> <a href="https://hanzalaqureshi.medium.com/data-architecture-trends-part-1-how-to-improve-data-quality-9967fdee9fc8"> <div> <div> <h2>Data Architecture Trends Part 1; How to Improve Data Quality</h2> <div><h3>Improve the Quality of Your Data by Observing It Every Step of the Way</h3></div> <div><p>hanzalaqureshi.medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/0*sXKMzyeunnWhsRZZ)"></div> </div> </div> </a> </div><h1 id="13e6">Conclusion</h1><p id="abb6">Moving to Data Productisation is more business change than technical, so bringing your business teams along the journey is imperative. Each organisation will have different existing challenges, determining how complex it would be to shift to product design and thinking.</p><p id="a5d5">One thing that will stay common in any data implementation is good quality data. It is one of the hardest things to achieve and, consequently, the most significant ROI.</p><p id="2437">Want to learn how to do that? Check out my FREE Ultimate Data Quality handbook and join my Medium email subscriber list.</p><div id="3aae" class="link-block"> <a href="https://hanzalaqureshi.gumroad.com/l/cfijx?layout=profile"> <div> <div> <h2>Ultimate Data Quality Handbook - FREE!</h2> <div><h3>Introducing "The Ultimate Data Quality Handbook: Best Practices for Perfecting Your Data" In today's data-driven world…</h3></div> <div><p>hanzalaqureshi.gumroad.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/0*OOVpynyGARw_6ox1)"></div> </div> </div> </a> </div></article></body>

Data Architecture Trends Part 2; How to Demonstrate Data Value by Productising

Treating Data as a Valuable Product in Modern Data Stack

Photo by Lars Kienle on Unsplash

For as long as I can remember, we have been talking about "data as an asset".

It's an asset for an organisation; we should treat it as such. However, it is impossible to get buy-in for this approach. If data truly is an asset, why do companies fail to invest in it? You wouldn't let your company's offices (an asset on the balance sheet) become derelict by not keeping up with repairs and maintenance, right?

The implementation of this approach has been littered with challenges. How do you quantify an asset? i.e. in a physical reality, what does it mean? If you can't explain that to a stakeholder, you can't reasonably expect them to own that asset.

Introducing Data Products; bridging the gap between loosely defined data assets and clearly defined physical outcomes with a business context.

So — What Is Data Productisation?

When Wozniak built the Apple I, he initially wanted to give away the design for free to other engineers.

Jobs saw this piece of kit as a "product", something that is real, tangible, valuable, sellable & usable. Similarly to Wozniak, in the data world, we have been busy building big data infrastructures, scaling large pipelines, and tinkering with different ETL tools — none of which the business cares about.

Linking data to value has been a fundamental challenge, and Data Productisation is here to solve this problem.

Data Products are a piece of information that addresses a fundamental business need. They directly link to a business outcome, which in turn drives a key business metric, like revenue generation (makes you more money), risk mitigation (mitigates risks, regulatory, reputation, etc.), and operational efficiency (makes your job easier/better).

Examples of Data Products are your C-suite dashboards, a model that helps you predict when a customer will churn, data for sales leads that allows your team to sell more services, etc.

But that's just the Data Products part; what about "treating as a product"? Well, your dashboard is your front end. You need underlying metadata, transformations and tools to make the dashboard possible. And when you package all that up into one operational item, it is your Data Product.

And when that Product meets certain principles like DATSIS, it is now productised. Discoverable (it can be found in a marketplace), Addressable (readily available tools can use it), Trustworthy (quality/lineage is known and limitations understood), Self-describing (all information related to is available), Interoperable (it conforms to product standards), Secure (it has relevant access controls applied)

Great — How Do I Get Started?

Most of today's organisations will have invested in their data, meaning this will not be a greenfield implementation.

Treating Data as a Product requires particular basic data management and infrastructure requirements. You can only productise something if you trust it enough. Implementing a solid data quality framework and data ingestion and retention framework, amongst other things, would help ensure you can truly market Data as a Product in your organisation.

You can start with 1 or 2 essential data products to avoid boiling the ocean. For example, start with the CFO dashboard, which shows customer churn leading to poor revenue outcomes.

  1. CFO Customer Churn Dashboard — Data Product
  2. Head of Performance Reporting — Data Product Owner — sets the vision of the product roadmap and is accountable for ensuring CFO requirements are met.
  3. Customer Domain related Data — Data Architect/Analysts — supports the Data Product Owner in creating relevant models designs to power the Product.
  4. Customer Domain Data Team — Data Engineers — creates the underlying data transformation code to meet the design set by the Architect and vision set by the Product Owner.
  5. Centralised Platform Team — Infrastructure Engineers — ensuring the platform & tool required to run the Product are maintained continuously
  6. Data Product Marketplace — a centralised tool where Products, all their related metadata and feature information are published

See Part 1:

Conclusion

Moving to Data Productisation is more business change than technical, so bringing your business teams along the journey is imperative. Each organisation will have different existing challenges, determining how complex it would be to shift to product design and thinking.

One thing that will stay common in any data implementation is good quality data. It is one of the hardest things to achieve and, consequently, the most significant ROI.

Want to learn how to do that? Check out my FREE Ultimate Data Quality handbook and join my Medium email subscriber list.

Data Science
Data Product Creation
Data Engineering
Data
Data Architecture
Recommended from ReadMedium