What’s in a Name?
The Problem with Roles & Sub-Domains in Data Analytics
Background
Tom Davenport, Professor of Information Technology and Management at Babson College, recently published a paper saying that data science success within organisations requires Data Connectors, people within the organisation who can close the gap between the business and technical domains. This is in a similar vein as the 2018 McKinsey paper on the need for Analytics Translators. Both Tom and McKinsey may each have their own nuanced interpretation of the situation, but both seem to converge on the path of creating new roles within the data science practice. This is lazy thinking — using humans to fill gaps rather than spending the time to re-engineer existing roles and work processes.
A bit of background. It all started when a friend of mine recently asked me, “What is the difference between Analytics and Analysis?” Koo and I co-teach an adult course in Visual Analytics using Tableau for the last 5 years. We spend much of the in-between time of the course (while the adults are doing their group work) conversing about the state of data analytics and AI in Singapore and on the wider stage. Our current line of conversation got me thinking about all the different types of sub-roles and sub-practices that have emerged around (data) analytics in the last 80 years. When I started my career in banking in the early 1990’s, ‘Business Intelligence’ was the commonly used term when it came to improving business processes and outcomes using data. Solutions took the form of reports and self-help databases; Oracle’s OLAP (online analytical processing) solutions were popular. Since then, we have ‘speciated’ into many different roles like data scientist, decision scientist, etc. Is it really necessary? Is it really useful? I’m beginning to think not.
It seems to me that what’s driving the continued creation of new roles and sub-domains is the age-old organisational war being played out between 3 competency groups — business competency vs math competency vs computer science competency, with each trying to assume the helm (see diagram below). And so I dedicate my 16th weekly article to debunking this cacophony of labels and roles in data analytics. This article will be a broad introductory piece to a sub-series where I will unpick each thread more meticulously.
(I write a weekly article on bad thinking and bad practices in data analytics / data science which you can find here.)
Who Let the Data In?
Business Intelligence was the grand daddy of the movement to leverage data to improve business processes and outcomes. The premise was simple: if I can get useful information into the hands of decision-makers, they would logically make better decisions. Where it started to go wrong was its disproportionate focus on the delivery mechanism of the said ‘intelligence’. We became inundated with reports leading to cognitive overload. We didn’t consider whether the users truly understood what they were digesting; many didn’t. We didn’t pay nearly as much attention to the nature of the metrics and its uncertainties. Business Intelligence became dominated by Computer Science types because it was perceived as IT. New roles were created in IT to support its growth.
Rather than addressing the deficiencies head-on, we supplemented it by creating a new sub-domain: Business Analytics. Business Analytics was dedicated to reducing uncertainty in the data and in its interpretation. It was a more statistical-based field, where practitioners used quantitative tools to make predictions and link it to business growth strategies. This sub-domain was dominated by statisticians and MBA / Marketing types who were data literate. It should be obvious to the reader that the Business Analytics was perceived as delivering higher economic value compared to Business Intelligence. New roles were created in Business to support its growth. Most business analysts were embedded into their respective business domains.
Both Business Intelligence and Business Analytics were outcome focused. If you didn’t have strong business domain knowledge, you couldn’t succeed as a business analyst. And so the math folks created Data Analytics as a new sub-domain to allow those who lack domain knowledge but had clever data-technical skills to distinguish themselves. Data Analytics brought in the use of new sophisticated statistical techniques and new computer algorithmic techniques such as machine learning. The objective was finding signals in the data; it was more input and activity focused rather than outcome focused. But then the Computer Science folks saw an opportunity to move out of the IT back office by claiming that they were much better at algorithmic programming and system integration. And voila!, we gave birth to Data Science.
Where is the Knowledge?
What both Tom Davenport and McKinsey are highlighting has to do with the domain of Knowledge. In Information Theory (see my previous article on this), information is defined as interpreted data (i.e. data + context) and knowledge is defined as information that is used for decisioning (i.e. information + consequence). We see that both Data Analytics and Data Science are low in knowledge creation; as the world shifted more from Data Analytics to Data Science, we saw a decline in sensemaking competency. In typical fashion, we addressed this gap by creating new roles and sub-domains. In comes Decision Intelligence and Decision Science. Cassie Kozyrkov, the former Chief Decision Scientist at Google, says that Decision Intelligence is a new academic discipline. I’m not buying it. Having seen and read many of her videos and articles, it’s largely (good) statistical discipline updated into a new bottle.
From the other end, we have the old practice of Knowledge Management (KM), which Google’s Bard (powered by the latest Gemini Pro) succinctly summarises as “… a systematic approach to creating, storing, sharing, and utilising an organisation’s collective knowledge to achieve strategic goals. It involves a set of practices and technologies that enable the organisation to capture, organise, and disseminate its knowledge assets effectively.” The entire definition is loaded with latent words (i.e. hard to define and measure in unique data-specific terms). Sounds clever but lacks clarity and execution-ability. I would further argue that this definition of KM isn’t really about knowledge but about Information Management. So the practice of KM also needs to ‘grow up’ in this current era. It needs to be about improving the inputs into and activities surrounding the decision-making process at the various hierarchical levels across the organisation. This also requires that the decision feedback loop is instrumented for. Having a systematic mapping of the ‘lay of the land’ is essential, but I don’t see organisations (and professors) spending enough of their time thinking about this.
A number of organisations have started to use the term ‘Decision Management’ to integrate the myriad of roles and sub-domains, to expand the responsibilities and scope, and to elevate the internal perception of their data analytics function. Citibank was amongst the first to do so more than 15 years ago; I was part of that function. I’ve since worked with a number of such organisations, and I can tell you that they are only similar in name and nothing else.
Coming Up Next
As mentioned, this article is merely an introduction to a wider set of issues concerning the speciation of roles and sub-domains in the practice of data analytics. I get the sense that with each new role or sub-domain that is created, the makers are trying to send a signal that this new group is smarter and more valuable than the previous. It’s a case of one-upmanship.
In my next set of weekly articles, I will explore the following questions:
- Can the various roles be simplified? Will there be new (meaningful) roles?
- What is the role that formal and continuous education play in ‘contributing’ to the problem?
- What does it entail to call your data analytics function ‘Decision Management’? Is this a step in the right direction?
- What is the implication of the growth in roles and sub-domains to the evolution of analytical leadership?
Stay tuned!
