Wanted – Chief Data Officer

Your organisation's data wants you

My updates here have been notable mostly for their infrequency in recent years. Indeed, in the period since my last substantive piece (Forming an Information Strategy: Part III – Completing the Strategy), I have had time to become a father again; a very welcome event but undeniably one which is not the most conducive to blogging.

Readers who may recall a more prolific period in my writing on this site will also probably remember that I have had a long association with the information-centric seminars run by IRM(UK). They have been kind enough to ask me to present three times at their Data Warehousing / Business Intelligence (DW/BI) events and once at their Master Data Management / Data Governance (MDM/DG) one.

Enterprise Data & BI 2015

In a sign of the times, IRM DW/BI has now morphed into the IRM Enterprise Data / Business Intelligence (ED/BI) seminar. I will be returning this week, not to present, but to form part of a panel discussing “Beyond Big Data, Delivering Real Time Actionable Business Intelligence to Your Organisation”. This panel will be chaired by Mike Simons, associate editor of a number of IDG organs such as CIO.com and ComputerWorldUK.com.

However, plugging this seminar is not my main reason for putting fingertip to keyboard today. The last few years has seen the rise of a new member of the CxO pantheon, the Chief Data Office (or CDO). It is a toss-up whether this role, or that of Data Scientist (“the sexiest job of the 21st century” according to the less sober than usual Harvard Business Review) has had more column inches devoted to it in recent times. Perhaps in reflection of this, IRM have also asked me to attend the co-located CDO Executive Forum this week. While it can be argued that elements of what a CDO does have been done by people with other titles for many years (I have been one of them), the profile of this role is indisputably a new development and one worth commenting on.

In a way the use of “data” in this title is somewhat misleading. In my experience CDO’s don’t focus exclusively on data (the atomic level), but on the process of turning this into information (basic molecules created from atoms), from which can be drawn insight (more complex molecules containing many sub-units) and which – if the process is to have any value at all – has to finally lead to some form of action [1]. Of course part of the idea of Data Scientists is to go straight from data to insight, but this is less straightforward than might be thought and clearly doesn’t obviate the need for a complementary and more structured approach [2].

Further food for thought for me has been some interesting observations on James Taylor’s blog [3] about the relationship between CDOs and Chief Analytics Officers (the latter perhaps echoing my former ideas around the role of Chief Business Intelligence Officer). He covers whether these should be separate roles, or combined into one, drawing the conclusion that it maybe depends on the maturity of an organisation.

Looking around the market, it seems that CDOs are a varied bunch and come from a number of different backgrounds. I began to think about what might be the core requirements for success in such a role. This led into what can be viewed as a rough and ready recruitment advert. I present my initial ideas below and would welcome any suggestions for change or refinement.

 
Requirements for a CDO:

  1. A desire to do the job full time and not as an add on to existing responsibilities
  2. A background steeped in the journey from data → information → insight → action
  3. A firm grasp of the strategy development process
  4. A thought leader with respect to data and information
  5. Strong leadership credentials
  6. An excellent communicator
  7. Structured approach
  8. Ability to influence as well as set directions
  9. Highly numerate (likely with a post graduate degree in the Physical Sciences or Mathematics) and thus able to commune with analytical staff
  10. Equally a strong understanding of technology and its role in driving success
  11. Experience of implementing Data Governance and improving Data Quality
  12. Experience of delivering and embedding enhanced Information Capabilities

A background in one or more of the following and exposure to / understanding of the majority:

  1. Strategy
  2. Marketing
  3. Commercial
  4. Analytical business disciplines (e.g. Actuarial Science in Insurance, Customer Insight in Retail)
  5. Accounting – not least from a reconciliation point of view
  6. Statistical Analysis
  7. Technology (specifically Information Management)

 

Of the above, the desire to be a full-time CDO is crucial. The only point in having a CDO is if an organisation regards its data and the information it can generate as strategic assets, which require senior stewardship. If they are such assets, then these areas need the whole attention of an executive who is both accountable and whose has the authority to move things forwards. Simply adding data to the plate of an already busy executive in some other area (the CFO, CMO or CIO for example) is highly unlikely to drive a stepped change in business decision-making.

Of course while the above list is necessary background / expertise for a CDO, ticking these boxes will not in and of itself guarantee success. Instead – at least in my opinion – success is likely to be predicated on some rather less novel approaches to driving business change. It is my aspiration to be a bit more regular in my publications and so I plan to cover some of these (as well as talking more about specifics in the data → information → insight → action journey) in coming weeks and months.
 


 
Notes

 
[1]
 
Perhaps equating this to the tertiary structure of macro-molecules might be stretching the point here, but when has that ever stopped me getting the last drop out of an analogy.
 
[2]
 
I covered some similar ground some time ago in Data – Information – Knowledge – Wisdom.
 
[3]
 
James Taylor on EDM – Chief Analytics Officer Summit Opening Keynotes.

The need for collaboration between teams using the same data in different ways

The Data Warehousing Institute

This article is based on conversations that took place recently on the TDWI LinkedIn Group [1].

The title of the discussion thread posted was “Business Intelligence vs. Business Analytics: What’s the Difference?” and the original poster was Jon Dohner from Information Builders. To me the thread topic is something of an old chestnut and takes me back to the heady days of early 2009. Back then, Big Data was maybe a lot more than just a twinkle in Doug Cutting and Mike Cafarella‘s eyes, but it had yet to rise to its current level of media ubiquity.

Nostalgia is not going to be enough for me to start quoting from my various articles of the time [2] and neither am I going to comment on the pros and cons of Information Builders’ toolset. Instead I am more interested in a different turn that discussions took based on some comments posted by Peter Birksmith of Insurance Australia Group.

Peter talked about two streams of work being carried out on the same source data. These are Business Intelligence (BI) and Information Analytics (IA). I’ll let Peter explain more himself:

BI only produces reports based on data sources that have been transformed to the requirements of the Business and loaded into a presentation layer. These reports present KPI’s and Business Metrics as well as paper-centric layouts for consumption. Analysis is done via Cubes and DQ although this analysis is being replaced by IA.

[…]

IA does not produce a traditional report in the BI sense, rather, the reporting is on Trends and predictions based on raw data from the source. The idea in IA is to acquire all data in its raw form and then analysis this data to build the foundation KPI and Metrics but are not the actual Business Metrics (If that makes sense). This information is then passed back to BI to transform and generate the KPI Business report.

I was interested in the dual streams that Peter referred to and, given that I have some experience of insurance organisations and how they work, penned the following reply [3]:

Hi Peter,

I think you are suggesting an organisational and technology framework where the source data bifurcates and goes through two parallel processes and two different “departments”. On one side, there is a more traditional, structured, controlled and rules-based transformation; probably as the result of collaborative efforts of a number of people, maybe majoring on the technical side – let’s call it ETL World. On the other a more fluid, analytical (in the original sense – the adjective is much misused) and less controlled (NB I’m not necessarily using this term pejoratively) transformation; probably with greater emphasis on the skills and insights of individuals (though probably as part of a team) who have specific business knowledge and who are familiar with statistical techniques pertinent to the domain – let’s call this ~ETL World, just to be clear :-).

You seem to be talking about the two of these streams constructively interfering with each other (I have been thinking about X-ray Crystallography recently). So insights and transformations (maybe down to either pseudo-code or even code) from ~ETL World influence and may be adopted wholesale by ETL World.

I would equally assume that, if ETL World‘s denizens are any good at their job, structures, datasets and master data which they create (perhaps early in the process before things get multidimensional) may make work more productive for the ~ETLers. So it should be a collaborative exercise with both groups focused on the same goal of adding value to the organisation.

If I have this right (an assumption I realise) then it all seems very familiar. Given we both have Insurance experience, this sounds like how a good information-focused IT team would interact with Actuarial or Exposure teams. When I have built successful information architectures in insurance, in parallel with delivering robust, reconciled, easy-to-use information to staff in all departments and all levels, I have also created, maintained and extended databases for the use of these more statistically-focused staff (the ~ETLers).

These databases, which tend to be based on raw data have become more useful as structures from the main IT stream (ETL World) have been applied to these detailed repositories. This might include joining key tables so that analysts don’t have to repeat this themselves every time, doing some basic data cleansing, or standardising business entities so that different data can be more easily combined. You are of course right that insights from ~ETL World often influence the direction of ETL World as well. Indeed often such insights will need to move to ETL World (and be produced regularly and in a manner consistent with existing information) before they get deployed to the wider field.

Now where did I put that hairbrush?

It is sort of like a research team and a development team, but where both “sides” do research and both do development, but in complementary areas (reminiscent of a pair of entangled electrons in a singlet state, each of whose spin is both up and down until they resolve into one up and one down in specific circumstances – sorry again I did say “no more science analogies”). Of course, once more, this only works if there is good collaboration and both ETLers and ~ETLers are focussed on the same corporate objectives.

So I suppose I’m saying that I don’t think – at least in Insurance – that this is a new trend. I can recall working this way as far back as 2000. However, what you describe is not a bad way to work, assuming that the collaboration that I mention is how the teams work.

I am aware that I must have said “collaboration” 20 times – your earlier reference to “silos” does however point to a potential flaw in such arrangements.

Peter

PS I talk more about interactions with actuarial teams in: BI and a different type of outsourcing

PPS For another perspective on this area, maybe see comments by @neilraden in his 2012 article What is a Data Scientist and what isn’t?

I think that the perspective of actuaries having been data scientists long before the latter term emerged is a sound one.

I couldn't find a suitable image from Sesame Street :-o

Although the genesis of this thread dates to over five years ago (an aeon in terms of information technology), I think that – in the current world where some aspects of the old divide between technically savvy users [4] and IT staff with strong business knowledge [5] has begun to disappear – there is both an opportunity for businesses and a threat. If silos develop and the skills of a range of different people are not combined effectively, then we have a situation where:

| ETL World | + | ~ETL World | < | ETL World ∪ ~ETL World |

If instead collaboration, transparency and teamwork govern interactions between different sets of people then the equation flips to become:

| ETL World | + | ~ETL World | ≥ | ETL World ∪ ~ETL World |

Perhaps the way that Actuarial and IT departments work together in enlightened insurance companies points the way to a general solution for the organisational dynamics of modern information provision. Maybe also the, by now somewhat venerable, concept of a Business Intelligence Competency Centre, a unified team combining the best and brightest from many fields, is an idea whose time has come.
 
 
Notes

 
[1]
 
A link to the actual discussion thread is provided here. However You need to be a member of the TDWI Group to view this.
 
[2]
 
Anyone interested in ancient history is welcome to take a look at the following articles from a few years back:

  1. Business Analytics vs Business Intelligence
  2. A business intelligence parable
  3. The Dictatorship of the Analysts
 
[3]
 
I have mildly edited the text from its original form and added some new links and new images to provide context.
 
[4]
 
Particularly those with a background in quantitative methods – what we now call data scientists
 
[5]
 
Many of whom seem equally keen to also call themselves data scientists