Data are a User Experience

Francesco Giordano, Head of Enterprise Architecture, Cloud & DevOps, Generali Investments

Francesco Giordano, Head of Enterprise Architecture, Cloud & DevOps, Generali Investments

The importance of data

It is quite simple today to stress out the relevance of data and how much analytics is of key importance in determining the success in a fast-changing market like the one we have experienced in the last years. But I don't want to fall into the classic cliché of statements such as: "data is the new oil" or similar. I just want to say that it has become simply crucial to invest in a comprehensive enterprise-wide data strategy. Today more than ever. The importance of taking informed decisions is of paramount importance pretty much in every sector. But, maybe with a bit of a bias, not taking in serious consideration a profound renewal of the data stack in the financial sector (and for an Asset Manager in particular) means being lost in the dust by competitors.

What does it mean investing on data?

So far the obvious. But what does it mean concretely to invest on data? It means many things, of course. Namely, it requires to re-consider not only the creation of a modern technology stack but also to commit with patience towards a cultural shift of the overall behaviors in the Organization. It means also to re-think the use of analytics, that are no more just an overlying layer, used to show nice charts to management, but something more integrated that must be deeply embedded into the core transactional processes of the Organization. Decisions must be taken "in place". It means to "democratize" the access to information (just falling again into another quite abused expression) to everyone in the Organization. Unicorns are giving several examples in this direction.

Mesh up with data

It is not my intention to introduce the concept of Data Mesh but for the few of you that have ignored the buzz so far, Data Mesh is a cultural and technical concept that distributes data ownership across product domain teams, with a centralized data infrastructure and decentralized data products. The interesting readers may refer for example to the recent book of Zhamak Dehghani that first introduced the new term some years ago. Talking about data strategies, decentralized analytics, the importance of data democratization and the common path towards insights-driven Organizations, this paradigm is becoming more and more common.

There are for sure several pre-conditions that must be matched in the Organization for this strategy to be applied with any hope of success. But it is in the facts that Data Mesh is gaining momentum among big Companies that have to deal with data revolutions. And this is true especially because it addresses many of the concerns related with those key topics on data.

" Talking about data strategies, decentralized analytics, the importance of data democratization and the common path towards insights-driven organizations, this paradigm is becoming more and more common "

And so, as many others, we have been working hard in the last years to begin our Data Mesh journey and we launched with some success our first Data Products. With some success, because we have seen immediately the Business warmly welcoming a self[1]serve approach to data in a domain-driven brand-new product. But here ends the favor and begins the problem.

Product-driven design is not for everyone

Yes, because being an expert in a domain, knowing exactly (which is not often the case) what other colleagues might need from data, defining accurately the requirements (which again it is not always the case) does not mean to be a Product Owner. Orienting the evolution of data products with the concrete concept of Products at its foundation is something that requires simply a totally different approach to which old-fashion Companies might not be used at all.

Users are used to change requests, requirements, projects, deadlines and costs. Not vision. Not internal clients. And especially not user experience. Needless to say that for IT is the same. Great product teams are user-centric and proactive and everyone seems to accept that. But there seems to be no so general consensus around accepting that data teams must do the same to be great.

User-centricity

The same importance that a product team gives to users must be given by data teams. Both the teams are trying to solve user problems. Data Product teams are business teams on their own and therefore must prove their value for the Company by concretely listening to user feedbacks and needs, and solving their problems. Not simply and passively receiving requests but continuously adapting features and functionalities to solve problems and responding always better to unexpressed questions.

Data are a user experience

But it is even more than that. It is ultimately an user experience. Like it is with every other tool we are used to in our everyday life.

Why are we so unwilling to accept even the smallest delay or bug in the tools we use every day and we accept to have such a poor experience when it comes to work? Why are we accepting to have awful interfaces when it comes to internal applications? If we do not pay attention on those aspects, how are we supposed to deeply change the behavior of people in our Organizations, to make them pay that much attention on data and analytics to take decisions?

Data Mesh is just one of the cultural shift in the data ecosystem we are experiencing today. Data Fabrics and Data Contracts are other emerging patterns. Those are the mantra today, and with good reason.

Those approaches entail to move away from the classic old[1]fashion idea of internal transformation projects to rather consider a product-driven holistic approach. But being product oriented is not for everyone. It requires to radically change the way we build data systems and we try to persuade people to use them. It is not just a matter of quality and reliability (which of course are of paramount importance). For those systems to realistically drive the change, we need to threat users as clients (even when they are colleagues) and re-imagine their experience in a way they would love it. We should do product marketing, as well (even internally). We should sell our (data) products, ultimately. Exactly as we would do for any product.

Financial