Tell us a little about yourself, Manish, and the history of Reltio.
I can’t really discuss the motivation and inspiration behind Reltio without first discussing a bit of its history. I started Reltio in 2011, and one of the first things that became clear was the number of applications that continued to grow and proliferate in the enterprise landscape. It was clear even back then that the pace was not going to slow down, and there was going to be an increasing number of applications that would be created.
The second thing that became obvious was the need for a visual transformation. Every company, especially in the past 24 months, has to have a digital orientation for their businesses. Without that, it’s a question of survivability more than even growth.
The third piece in the early stages was the notion of cloud adoption. In 2011, there was only one cloud provider: AWS. It was becoming clear that if you have to manage data, it will continue to grow and need to scale horizontally. The best place to store all that data would be the cloud.
Having seen some past experiences and hurdles with adopting MDM-type concepts, my fundamental belief has always been that MDM is the right concept. It was a bit too early for its time and, as a result, didn’t have the right underlying technology capabilities to support a customer’s journey because of some of the problems we solve in MDM.
Think of it as a concept where you have to bring together data from multiple sources, unify it, and stitch it together into a holistic answer. Those requirements always have an increasing number of systems to tackle and will always present a challenge. If you don’t know all the integrated systems, how can you possibly know what schemes those systems have? And yet, people were trying to define a singular data model that was fixed as a relational construct in the middle of that as a way to integrate. For example, I don’t know if I will encounter a record for a customer that has one email address or five. So why define the data model with one-to-one cardinality for a person to have an email address?
Those types of issues were at the crux of why some of the previous generation capabilities failed or ran into problems. That is because the method of solving those problems was not in line with the nature of the problem itself.
If you think about an enterprise, everybody has business process automation and refined how they use applications at scale across the enterprise. But the biggest hurdle for every business today is the number of siloed applications and data silos. That is a friction point for many organizations. Then, the next wave of optimization is how to have data as a continuum while continuing to drive business evolution. Because the data they have today drive the business decisions of tomorrow. We saw an opportunity to create a capability that supports businesses for the next 15 or 20 years. I just couldn’t shake that out of my head, so I had to work on that problem. The answer to that was creating Reltio.
How do data governance and MDM interplay? Does MDM exist to solve the lack of clear data governance? Or once you have good data governance, do you no longer need MDM?
Great question. Having lived through various evolutions of master data management and data governance as an overarching concept, my take is that it is an ever-evolving continuum where these two things have to go hand in hand. For example, consider data quality. What exactly is good enough?
Let’s say you can claim you reached 70% as the milestone in improving data quality. Does that mean your work with data quality is over, or can you now tackle the remaining 30%? Or, instead of tackling all of the 30%, you improve it from 70 to 75 and then 75 to 78. You keep making incremental progress in these areas. It is a long tail of opportunity and effort involved.
What is the best way of solving these things in concert? I think this is where certain principles have to be thought through. How does MDM aid data governance, and how does data governance aid MDM? Both go hand-in-hand. As we bring together aggregate and unified information, we have to think about the different governance models we can apply.
Instead of being fragmented with siloed data spread across all different systems, even if you put a system of governance and curation in place, you have to think about how the data governance policies drive continuous improvement on top of it. Instead of having data governance spread across different parts of the organization, do it in a manner that empowers more people to participate in data governance cycles.
This is why we created the UI capabilities, and many customers give us feedback on how differentiated or good the UI capabilities are. Our goal has been to put data in the hands of more users. The more people are looking at and working with the data, the better the data's quality and governance. Otherwise, it’s in a black box. Nobody understands the governance policies and practices. When we bring in more users with the data together, it drives better outcomes.
Are there any data governance frameworks we’ve seen working across various clients and their feedback?
There are several different data governance models that customers have adopted. A lot of customers start with a highly centralized data governance model. It works in very controlled environments, but we see that even those customers are now enrolling in a more distributed governance model. Before, the distributed model was too fragmented, and customers could not go to a distributed system of governance. Now, by centralizing the data, they distribute the governance of that information into a single data repository.
They may seem like opposing constructs but unifying and centralizing the data makes the distributed model more accessible. Distributing the governance is the model we see evolving as more customers adopt and find success.
If you want access the entire conversation with the Ask Me Anything with Manish, you can access the recording AMA here, as well as some additional community questions he answered here.