Case Studies Todd Goldman May 17, 2017

Going on Offense with your Data Catalog is the Difference Between Success and Failure

This week we had three new installations of the latest version of the Waterline Data Catalog.  Because this is a relatively new release with some major functionality improvements, our VP of products has closely monitored and sought out customer feedback. When I asked him how things were going, he said, “the installations went very smoothly and I can tell you now, that customers A & B will be successful.” But when I asked about customer C, he said “if we don’t do something, customer C, will fail.” Customer A is a large manufacturer in the computer industry, customer B is a worldwide restaurant chain and customer C is a data analytics company.


When I asked why he thought customer C needed help, he said the answer was very simple. “Companies A & B have a plan and very specific objectives. They know what they are going to do once they discover, organize and tag their data. However, company C only knows that they don’t have a good grasp of their data assets and that understanding them better is good for business. But they don’t have a specific project in mind, so no one is going to use it.”


This is a classic deployment problem for pretty much any kind of enterprise software. In this case, Company A, the large manufacturer, has two projects. The first is GDPR compliance and the second is for cross-business unit marketing analytics. Today their data lake supports limited access for business analysts because they can’t sort out which data is sensitive and who should have access to it. The result is that only five of their data scientists currently have unfettered access to the data lake. By cataloging the data in the lake, tagging sensitive data and implementing tag-based security, they can more securely give access to over 1,000 data analysts. This will give them the ability to unleash a torrent of research that they believe will lead to new data-based product offerings. Company B similarly is concerned about GDPR compliance but they also want to do end-to-end supply chain analysis, including data from their suppliers, in an effort to reduce their in store inventory, which directly impacts profitability.


Company C, as mentioned, is much vaguer with their intentions. They believe that good data governance, good metadata and good data management is important. However, this doesn’t translate into real business results and is exactly why the idea of “Data Governance” has taken so long to catch on. Everyone who deals with data knows that good governance equals good business. But very often data governance projects end up being a means to an end or something done just to satisfy the regulators as a defensive measure. The result is that projects are poorly funded because they don’t lead any type of measurement back to the bottom line.


So what should be done about Company C?  Our plan is to sit down with them and review the use cases from some of our previous successfully deployments to help them connect the dots between where a poor understanding of data has resulted in project failure. Their CDO officers and their business users need to jointly identify some specific projects where connecting the dots between data across business silos and to the right business analysts is likely to lead to better business results.


But the key here is to not just make arguments that better data leads to better results. Instead, the key is to go on offense, find real projects and make your data catalog as well as your entire data management organization key contributors to delivering real business value.