Inspiration for your first data platform product catalogue

Imagine you own a café and your ambition is that customers leave your establishment with their batteries recharged, stress released or full of optimism for the day. That is what you are selling.
However, on the menu you have coffee, tea, homemade yoghurt, chia biscuits — perhaps even yoga and massage. That is what you are also selling.
So when do you use the first list (battery recharge etc.) and when do you use the second list (coffee etc.)? And what has this got to do with a data platform?

This short article describes how the understanding of the data platform products and services developed during the first 1,5 years of the data platform’s life in Danske Bank. The main take away is that more than one level is needed: both a detailed practical catalogue and high-level utilities or capabilities.

Might very well be that you have approached the challenge of building a data platform product catalogue differently. Please comment and include links to other approaches.

When data volumes grow and data consumer numbers grow: enter the data platform

As organizations advance in their digital transformation, the relevance of data to understand customer needs and preferences grows. Digital channels become the way customers use companies’ services and products. Data volumes grow on so many levels and so does the number of consumers in an organization.
The purpose of the data platform is to bring data — together with appropriate tooling — to hungry consumers in a fashion that is cost efficient through scale, generates network effects, and offers complementary products. Cost efficiency includes finding the sweet spot where self service and governance balance.

Both digital native organizations and more traditional organizations embarking on a digital transformation are now building data platforms. Banking organizations have advanced to build their first generations of data platforms in recent 2–3 years to accommodate the growing enterprise-wide need for data-driven decision-making. This activity has to deal with the historical context: There are already multiple existing solutions that have been established to drive data-driven decision making in a pre-digital era; spread around the organization solving various use cases. Compare the situation in digital native companies, where data platforms have been built and grown together with the enterprise.[1]

In Danske Bank, we started the endeavour in 2019 of bringing together main solutions and tools in use in the organization. This article describes how the understanding of the data platform products and services developed during the first 1,5 years of the data platform’s lifecycle. We learned a lot and also have our share of hindsight about what could have been done differently, but the overall conclusion is that for anyone building or developing a data platform, a product-centric perspective is strongly encouraged. Not much is published about this topic yet, which is surprising given its importance and complexity.[2]

2019: Data platform products as utilities or generic services

The data platform was established in Danske Bank by bringing together a number of core banking data solutions that had previously been managed separately as part of local, more or less vertically integrated teams consisting of business users, analysts, data engineers, and software engineers. Without going into details with the solution stack, it was comprehensive in terms of the variety of storage, processing and tooling. In cases where the solutions were shared among several teams, the coordination was minimal or a bit above.

We applied Gartner’s 4-tier capability framework[3] as the reference point to describe what a data platform should deliver. In a concise overview, this explained who the user groups were and what the data platform would provide for them. We had two broad user groups and two modes of working (Innovation mode and Execution mode).

We broke each capability further down into 2–3 sub capabilities. This was our initial ‘product catalogue’. We called them utilities or generic services to emphasize that the whole enterprise, despite their different applications of data, should be able to use the platform.

The structure provided by this approach had the benefit that it provided direction for the architectural design that focused on how to deliver these utilities in a cost efficient, scalable way that would strengthen the large group of consumers throughout their lifecycles of innovating and implementing data products. We mapped the existing solutions into this design, which made it clear how they complemented and overlapped each other. It also became clear which functional components were missing. In this way, we could use it create a first architecture roadmap.
We also found that consumers and stakeholders generally responded positively to the story that the data platform’s mission would be to deliver those utilities and we could concisely explain why we needed funding. We also used them internally to group requests and options, because it allowed looking across technologies and our previous silos to find solutions. This proved extremely useful to reduce time to delivery, improve matching of exact requirements and avoid ad hoc solutions.

Despite their intuitiveness to users, utilities were not appropriate as contents of a product catalogue. We found that in the actual dialogue with users, the requests were generally quite simple and specific, or they would be quite complex and vague and we would need to have small workshops to work out the actual requirements. The utilities were also aspirational — guiding where we were heading — whereas users needed knowledge of what we could offer at present. The utilities were not very helpful in either of these types of conversations.

2020: Data Platform products as simple, intuitive building blocks

In 2020, we have turned to more detailed product catalogue that tries to reflect and structure what consumers are actually requesting — and words they use to describe it. This is more practical for the actual conversations because we use the terminology that people have become familiar with and there are many different ways to combine the data platform products for consumers. The general lesson — proving a basic principle of product management — is that you have to offer products that consumers will purchase. For example, the data consumer does not want an ‘information platform’, but a SQL data mart.

The table below contains the product categories and examples of data platform products that we currently offer. The full list currently has 31 products and is a beautiful mess of simple and complex products, high and low involvement, and some a more services than products. Following the principle to use familiar terms, many of the products contains reference to specific technologies and vendors.

As this list takes the current situation as its vantage point, there are obvious questions, such as should we really offer that products or is another team in a better position, or whether they really meet the criteria and quality level we require of a product. It is part of the product roadmap to answer these questions while maturing and developing the products in general.

Organizationally we are not quite there but as product owners are assigned and will take action, roadmaps will be defined and the products be improved continuously. Next year a new chapter on data platform products will be written.

Conclusion

Other organizations might very well have approached to challenge of building a data platform product catalogue differently, so please comment and include links to other approaches.

The main take away from the last 2 years is that both levels are needed: both a detailed practical catalogue and high-level utilities or capabilities: With the former, you structure the daily consumer dialogue and develop iteratively. With the latter, you assess new solutions and connections, and set ambition.

Notes

[1]See for example Uber’s story of its data platform generations: https://eng.uber.com/uber-data-platform-2019/

[2] Some articles do exist, see https://towardsdatascience.com/how-to-build-your-data-platform-like-a-product-6677e8abe318,

https://www.accenture.com/_acnmedia/PDF-99/Accenture-Platform-Product-Management-Final.pdf

[3] See e.g. https://itlc.it.wisc.edu/wp-content/uploads/Harnessing-Data-and-Analytics-Carlie-Idoine.pdf