Analytics Dashboard

Heads of Data vs Chief Data Officers

The data & analytics space loves to create new roles and titles. Often, it’s hard to tell exactly what these new roles do, or if their proposed responsibilities are already being met elsewhere. One role I’ve uncovered while researching data product management is Head of Data. While this sounds similar to the Chief Data Officer role, the two are really quite different. This post looks at some of the differences in these two positions.

Enterprises have been adding Chief Data Officers (CDOs) to their C-Suite since the early 2000s, hoping to support business strategy with a cohesive data strategy. The CDO is responsible for many aspects of data management, like:

  • Data governance at the corporate level, commonly overseeing some form of enterprise data governance team.
  • Data monetization strategies across the enterprise.
  • Creating a data vision and strategy around how data is managed, stored and used with what the business’ objectives are and ensuring alignment.

As you can tell, Chief Data Officers are focused on interacting with the business and how it uses data. There is less emphasis on technology and infrastructure, since those remain the responsibility of the CIO or CTO. CDOs may report to the CEO directly, but it’s also common to see them reporting to R&D or finance.

If CDOs are primarily focused on governance with an eventual goal of creating a data-driven enterprise (whatever that means), Heads of Data are a new type of role designed around growth-oriented customer-facing activities. Instead of taking an enterprise scope, Heads of Data are more like senior product managers. This role may be expected to:

Like many new data-centric jobs, Head of Data is a multi-faceted role that requires people to be effective collaborators and communicators, but also adept technologists. Prospective Heads of Data must have deep domain knowledge and be as comfortable optimizing SQL as presenting to executive and board-level stakeholders.

Alternative titles for Heads of Data include: Head of Customer Analytics, Head of Business Intelligence, Head of Analytics and Head of Digital Analytics.

Unlike the CDO, Heads of Data likely report to the Chief Product Officer or Chief Customer Officer, but the reporting structure will depend on the company.

Chief Data Officers often have a strong foundation in data governance or risk management, which I believe limits their potential upside to the business. Heads of Data are likely coming from product management, data science or engineering backgrounds, which focus more on customer value and growth. Unlike the CDO, which focuses on what can’t be done, Heads of Data focus on what can. While both roles may be required for enterprises going forward, the growth-focused Head of Data is a great career progression for data & analytics generalists looking to make the next step.

Photo by Stephen Dawson on Unsplash

Amazon DocumentDB vs. MongoDB – Simplicity vs. Complexity

Amazon Web Services is making a habit of disrupting smaller enterprise software vendors. At its re:Invent conference, AWS caused quite a bit of pearl-clutching in various open source communities for its managed Apache Kafka service. The company was accused of strip-mining open source while failing to contribute back to the communities it was appropriating software from.

Last week, AWS went further by announcing a new DBMS with a MongoDB-compatible API (based on the 3.6 version). MongoDB responded predictably, but the Amazon DocumentDB announcement didn’t trigger the same reaction from the OSS community. I imagine there’s far less sympathy for MongoDB after it relicensed as a proprietary product. There have been several takes about what AWS’ announcement means for open source software, but I believe those miss the point. The point isn’t about open source. The point is about delivering what customers value and what they don’t.

The majority simply don’t value open source. In certain cases, customers value their relationships with the vendor, but only when the vendor is an engineering partner instead of merely a rent-seeker. However, those instances are exceedingly rare. Customers don’t value operational opacity and complexity, especially for technologies with extremely limited skills available in the market.

Amazon Web Services hasn’t capitalized on open source software. It has capitalized on customer demand for removing complexity. Kafka and MongoDB won’t be the last OSS projects to get blindsided by the cloud providers. I can think of at least two other “open core” enterprise software companies with overly complex products that end users would love to have someone else manage.

A Cognitive Model for Decision-Making with Data Visualizations

Data visualizations increasingly inform our daily decisions. Traffic visualizations inform which route to take to the office, business intelligence dashboards indicate how you’re doing on projects and key performance indicators. And data collected by fitness trackers tell you how close you are (or aren’t) to reaching your weight loss or fitness goals.

Continue reading →

Google/Walmart Tie-Up Leaves Data Use and Ownership Unanswered

Google and Walmart have announced a partnership where Google Home users can purchase Walmart’s products using voice ordering. As Recode points out, the intent of the partnership is to blunt Amazon’s initial foray into voice-based ordering. Coming at this from the data and analytics perspective, my first question is what happens to the customer data from, potentially, millions of orders?

Google’s partnership position is clearly more advantageous than Walmart’s. For Google, the data from voice-based ordering is likely to be combined with the existing customer profile it already has and will feed its advertising efforts. Obviously Walmart also gets the order data, but who else? Can Google resell that data to other parties? These details weren’t included in the partnership announcement, but Google’s terms and conditions make it clear that they can use data however it sees fit.

As partnerships between consumer-centric companies proliferate, the questions about who owns customer data and how it is used must become prominent questions for both the companies involved and the impacted consumers. After all, consumers provide the data that drives revenues for companies like Google.

Data Lake Webinar Recap

Last Thursday I presented the webinar “From Pointless to Profitable: Using Data Lakes for Sustainable Analytics Innovation” to about 300 attendees. While we don’t consider webinar polling results valid data for research publication (too many concerns about survey sampling), webinar polls can offer some interesting directional insight.

I asked the audience two questions. First, I asked what the data lake concept meant to them. There were some surprises:
datalake webinar q1

The audience’s expectation for a data lake is as a platform to support self-service BI and analytics (36%), but also as a staging area for downstream analytics platforms (25%). It’s not unreasonable to combine these two together – the functionality for a data lake is largely the same in both cases. The users for each use case differ, as well as the tools, but it’s still the same data lake. A realistic approach is to think of these two use cases as a continuum. Self-service users first identify new or existing data sources that support a new result. Then, those data sources are processed, staged and moved to an optimized analytics platform.

It was reassuring to see smaller groups of respondents considering a data lake for a data warehouse replacement (9%) and as a single source for all operational and analytical workloads (15%). I expected these numbers to be higher based on overall market hype.

The second polling question asked what type of data lake audience members had implemented. Before I get into the results, I have to set some context. My colleague Svetlana Sicular identified three data lake architecture styles (see “Three Architecture Styles for a Useful Data Lake“):

  1. Inflow lake: accommodates a collection of data ingested from many different sources that are disconnected outside the lake but can be used together by being colocated within a single place.
  2. Outflow lake: a landing area for freshly arrived data available for immediate access or via streaming. It employs schema-on-read for the downstream data interpretation and refinement. The outflow data lake is usually not the final destination for the data, but it may keep raw data long term to preserve the context for downstream data stores and applications.
  3. Data science lab: most suitable for data discovery and for developing new advanced analytics models — to increase the organization’s competitive advantage through new insights or innovation.

With that context in place, I asked the audience about their implementation:
datalake webinar q2

63% of respondents have yet implemented a data lake. That’s understandable. After all, they’re listening to a foundational webinar about the concept. The outflow lake was the most common architecture style (15%) and it’s also the type clients are asking about most frequently. Inflow and data science architectural styles tied at 11%.

The audience also asked some excellent questions. Many asked about securing and governing data lakes, a topic I’m hoping to address soon with Andrew White and Merv Adrian.

Five Levels of Streaming Analytics Maturity

Data and analytics leaders are increasingly targeting stream processing and streaming analytics to get faster time to insight on new or existing data sources. Year to date, streaming analytics inquiries from end users have increased 35% over 2016. I expect that trend to continue.
In getting to real-time, these leaders are presented with a range of proprietary commercial products, open source projects and open core products that wrap some existing open source framework. However, in many cases, streaming analytics capabilities are little more than commercially supported open source bundled with some other product. Creating a streaming analytics application is left as an exercise for the buyer.
The challenge is that getting real value from streams of data requires more than just a point solution. Stream analytics is a cross-functional discipline integrating technology, business processes, information governance and business alignment. It’s the difficulty integrating these areas that keeps many organizations from realizing the value of their data in real-time. I’ve been working with my colleague Roy Schulte on a streaming analytics maturity model to help organizations understand what’s required at each maturity level:
In “The Five Levels of Stream Analytics — How Mature Are You?”, we present structured maturity levels for data and analytics leaders to evaluate the current state of their stream analytics capabilities and how to advance their respective organization’s maturity to become smarter, event-driven enterprises. The report is focused on the use of event streams for analytics purposes, with the goal of improving decision making. Gartner clients can download it here.