This past week, Tom Davenport, of the "Competing on Analytics" fame published an HBR article that he could have named: "What They Don't Teach You at Harvard Business School: Big Data Edition". The piece follows a long list of mainstream articles that have attempted to highlight the shortcomings of "Old School Data Strategy". Here is what you might have missed and why it could matter to your company and career.
What is Your Data Strategy?
Enterprise CIOs have the opportunity to build a better data strategy if they delineate the work of their data teams across two concepts: data architecture and information architecture. Here is a quick summary:
Data Architecture: "A company’s data architecture describes how data is collected, stored, transformed, distributed, and consumed". Data architecture is therefore primarily about choosing database technology (Hadoop or traditional) and implementing ETL processes (ETL stands for extraction, transformation and loading). The key drivers of good data architecture design are control and governance. And when organizations invest millions in the science of data movement and extraction, they might forget to put emphasis on agility and decision-making speed. When that occurs, analysts spend more time on data discovery and data preparation than on business discovery and insights generation. A key data point highlights this issue: 80% of analysts’ time is spent simply discovering and preparing data.
Organizations that win have modernized their data architecture. Rather than simply focusing on data movement, they engineer processes that allow data to be secured and have queries in place. They've moved people and their processes to the data. To see how it's done, watch the story of American Express and how they scaled Analytics for Big Data.
Information Architecture: "Information architecture governs the processes and rules that convert data into useful information". Historically, enterprises have thought about data architecture and information architecture as one. And they have consistently gotten in trouble because enforcing "one version of the truth" is hard. As we discussed earlier, the typical trade-offs CIOs deal with is control versus agility.
This article creates a framework for leaders to think about data and information as two different concepts. Data is stored and governed. Information is accessed and used. Data becomes information because it's defined by logic. That logic is called a "semantic layer".
When referring to "Information Architecture", we're not talking about dashboards or reports here. But rather, we refer to the definitions, calculations and metrics that can be applied to all reports, dashboards or scorecards. If you feel you could use a crash course on this topic, check this blog from our CTO and co-founder Matt Baird:“What is a Semantic Layer” & Why Would You Want One?".
Data is nothing without Actions
Harvard Business Review is not the only publication to discuss the many shortcomings of "Old School" data strategy recently. The Economist also provided two great pieces on the topic. Each focused on data collection and insight generation.
How to effectively collect and use data: In a recent piece about how large energy companies use data, The Economist shows that enterprises only use 5% of the data they collect. And when they do, they manage to cut operating costs by 60%. Imagine what they could achieve if they could use all the data they collect. What's your current situation?
Driving insights from data: The Economist also finds that only 1% of the data collected reaches the people that need it to make decisions. This is precisely caused by what Tom Davenport discusses in his HBR article, "while a small portion of the data is collected (data architecture), an even smaller percentage makes it to decision makers (information architecture)."
We're not advocating that all data be made available to all users of course. In fact, as Tom Davenport highlights it in his article, more than 70% of employees have access to data they should not. Data security is important. So is decision-making agility. The question is: how can you get both?!
Can You Have Your Cake and Eat It?
The history of the data analytics industry has been punctuated by extreme positions that either favored governance over self-service (and created end-user frustration) or provided self-service but no governance (and created chaos).
The question every enterprise CIO has today is: How can we have both governance and self-service? How can an organization provide its employees with the data and tools they need to innovate and outperform while at the same time adhere to data access policies?
The answer might be simpler than you imagine. Our customers typically take three key steps:
1) They avoid moving data around. They store data once and secure it in-situ.
2) They engineer processes so that data can be queried in its place of origin (you'll have to consider scale, security and speed requirements).
3) They decouple "Information Architecture" from users' analytics tools. Enterprise business logic deserves to be treated as a standalone asset. It can and should live autonomously from your data store and your analytics tools.
Not sure how to get started? Check out our blog:“What is a Semantic Layer” & Why Would You Want One?".
The Delta Model
Still need help to get your teams to move? You're in luck! The Harvard Business Review provides a quick primer video on Big Data Analytics. We've embedded it down below and highly recommend you pass it on! The video details the key dimensions you'll need to master in order to get more people to follow your lead. The video takes you through a concept Tom Davenport popularized in 2010: the DELTA model. Here is what it stands for:
D is for Data. You can't succeed if your data is not accessible in one warehouse. This can be an enterprise data warehouse or a data lake.
E is for Enterprise. You need capabilities across your enterprise. No point having fiefdoms or spreadmarts with their own siloed logic. A universal semantic solution can help you get there (for more see earlier resources).
L is for Leadership. You can't succeed if your leadership doesn't mandate a better big data analytics strategy. In the most recent industry big data maturity survey, companies whose executives lead their big data transformation were 50% more likely to succeed than others.
T is for Targets. No science projects. Your big data initiatives are designed to help employees. Many of them. Ideally all of them. Not just a few data scientists. Check out these customer examples to identify the key use cases you might want to pursue first.
A is for Analysts. Business Analysts matter. But analytical talent matters more. Your title doesn't have to say "Business Analyst" to be considered an analytical person. Strive to hire people who have a strong bent for analytics. And realize that your "analytical champions" only represent 1% of your enterprise analytical talent pool.