MVP for a data product

This article is the continuation of the article EA case study: Example of a data product.

Data as a product

Creating data products that lend themselves well to sharing and re-use in hitherto unimagined ways should be the focus. Dehghani lays down 8 characteristics Data-as-a-Product should adhere to:

  • Discoverable (we must be able to find it when searching)

  • Addressable (when we have discovered it, we need to able to get to the data)

  • Understandable (we should be able to understand the data, their internal relationships. and their relationships with data in other products without calling a friend)

  • Trustworthy and truthful (the data must give a high quality and trustworthy representation of the concepts they are describing)

  • Natively accessible (it should be easy to access the data with the tools we prefer)

  • Interoperable and composable (it should be easy to correlate the data with other data in the organization, and create new products by combining others)

  • Valuable on its own (we should not have to combine it with other products in order for it to be valuable)

  • Secure (we should only be able access data in accordance with the company's security policies, respecting any limitations imposed by laws, regulations and internal guidelines (e.g., GDPR))

Design concept for an MVP

What if we start with a very simple design concept to show the fundamentals for a data product?

We create one page called “Data products” in our searchable intranet (discoverable). This page consists of a number of entries, with a data product description (understandable) and a link to the different data sources (addressable). 

For each source system we need to have a person who is responsible for the data quality (trustworthy and truthful).

They are downloaded as using CSV-files (natively accessible) and from the source system for those who have access (secure).

We can use the information in the data product directly (valuable), but also, by combining several data products in Excel, we can create new data products (Interoperable and composable).

The image above shows a page with links to existing data in Teams.

From an organisational point of view, we only need two roles to solve this MVP. One role who is responsible for the actual data product page and one role who is responsible for the data quality.

The major problem with this design is that it’s not scalable or flexible enough, so the question is how to solve these to issues.   

CSV-file for actors (empty). We have more than 200 actors in file that ben participating in our productions.

Too simple? We are talking about setting up a new business with (data) products, we don’t know if we have enough customers for.

Next design iteration

Discoverable - For us, this means internal store integrated in Office 365 and/or mobile devices.

Addressable - Interface directly without any need for middleware or conversions, and without wait.

Understandable - Use of business vocabulary and aligned with APQC processes for broadcasting.

Trustworthy and truthful - There should be named persons responsible for data in each domain (business capability), or more gradual. E.g. the production manager is responsible for data quality in his/her production.

Valuable on its own  - Based on business KPI and/or compliance with regulations.

Natively accessable - The tools we are using are based on Microsoft Office 365, thus, the data products should be accessible from this platform for all business users.

Interoperable and composable - One, and only one information model for the organisation. As part for TME sector, we will use TM Forum’s models and make additions when needed.

Secure - Privacy by design is a an Architecture Principle and all designs must adhere to this paradigm.

The third article in this series will be about an example high-level design for data products and management.