Last week I attended a very interesting IAPA panel discussion in Canberra, organised by Peter O’Hanlon, head of the IAPA ACT chapter. The panel discussion was lively, informative and controversial, exploring as it did the often difficult relationship between Analytics and IT. A1′s very own Stephen Samild was one of five panelists. Peter did a great job of facilitating, and all five panelists made some great points. People in the audience also pitched in with interesting questions and reflections on real-world experience.

The conversation continued to return to a central topic, one that lives in the murky grey area between the two functions, and acts too often as a political football. I speak of the instantiation and deployment of Analytics outputs to IT systems. This essential activity, often referred to as “operational analytics” is the source of much confusion, conflict and business failure. Much of the trouble arises from poor fundamental philosophical distinctions which have arisen historically. These lead to unhelpful naming conventions and political turf demarcations. To explore the issue is to re-examine some fundamental definitions and distinctions. The first task is to ask what do we mean by Analytics. Two possible definitions might be:

1. Any electronic manipulation of large amounts of data.
2. Any exploratory analysis of data that results in information leading to innovation or insight.

Definition 1 covers both the quest for insight and its deployment and operation in an IT system. Definition 2 covers only the former. Which definition is preferable?

The operational step itself consists of two steps, which is the deployment of an insight (e.g. a predictive model) and the ongoing monitoring of its effectiveness.

Reasons for preferring definition 1, which places both steps within the Analytics realm, include the following:

• “Operational Analytics” has the word “Analytics” in it
• There is data crunching involved. Isn’t that what Analytics is?
• There is model evaluation/monitoring involved. That is stuff only Analytics people do, right?
• Historically, this has been stuff only the Analytics people cared about.
• The software that does all this stuff comes from Analytics providers.

There are however some solid counter-arguments to these:

• Could this just be an unhelpful and confusing historical accident?
• There is plenty of data crunching in payroll, accounts payable and other operational systems that few would think of as Analytics.
• Monitoring and evaluation should be applied to a lot more than just predictive models. In particular, it should be applied to any business process that Analytics would seek to improve. This is Performance Management and Business Intelligence, but hardly Advanced Analytics. While this kind of measurement is often seen as part and parcel of Analytics, there is no reason that the two need go hand in hand. The extent to which they do is an artefact of history, and a reflection of the poor penetration of empiricism and appropriate performance management across business generally.
• Historical accident is no reason to maintain a coupling of what are fundamentally different activities.

Naturally, there may be counter-counter arguments, and I invite readers to raise them in comments.

To argue for the narrower definition of Analytics is to demystify “models”, and to demonstrate that an operationalised predictive model is no different to an operational accounting system. The argument is simple:

1. Both deal with potentially large data sets.
2. Both apply a range of rules, consisting of if-then-else conditions and arithmetic.
3. Both produce outputs to some workflow.

And that is it. The emperor has no clothes where actual models are concerned: a predictive model is little more than a bunch of if-then-else logic and arithmetic. These rules can be read and deployed by IT staff. Indeed, it is not important to know where the rules came from, be it a Support Vector Machine or human defined rules laid down by the CFO.

The magic of Analytics lies in its ability to find the right set of rules. The rules themselves are not that complicated in comparison to the learning algorithms that find them. My favourite analogy here is the needle and haystack problem. A metal detector would be handy here, and is arguably a very sophisticated tool compared to the humble needle. The detector makes sure you end up with the needle and not just hay. Once found, you notice that the needle is a rather simple yet valuable tool, and one that can be put to work sewing. So far, so good. You might also agree that looking for metal and sewing are somewhat different tasks and that the metal detector guy can now go off and look for more needles in some other haystack, or for gold. Putting the needle to work sewing is a completely different skill for someone else.

The broader definition of Analytics creates commonality between sewing and metal detection. The narrower definition accepts that any such commonality is neither necessary nor natural. So historical baggage aside, there may be an argument that insight and innovation generation is the business of Analytics, while the operational deployment of business rules is the province of IT, as might be the ongoing monitoring of the effectiveness of such systems.

There are then counter-arguments to this distinction. These rely on specific definitions of the words “exploratory” and “deploy”. Both are to a large extent a misunderstanding of terms rather than a true disagreement, but they can naturally lead to a preference for the broader definition of Analytics. Political factors also come into play. Again, the counter-arguments are on good footing with respect to history, but may lead to unhelpful category errors.

First of all, the word “exploratory” raises the hackles of many an Analytics manager. This is because analysts are by nature explorers, and rightly so. Unfortunately this can be taken to extremes, and a small but conspicuous minority of analysts are always at the ready to run off into uncharted waters, performing analysis of questionable or nil business value, treating their job like an open ended research project/video game, and perhaps violating a number of principles of science, reason and IT security in the process. While actually rare, this approach to Analytics is memorable enough to give exploration a bad name, especially among people in business not used to scientific inquiry.The good news is that pathological exploratory behavior is a small and manageable problem. It can usually be turned around by more attentive supervision, incentives and leadership.

There is also a cultural issue clouding an appreciation of exploration. Managers accustomed to process, best practice, and clear objectives often have trouble distinguishing dysfunctional exploration from more productive kinds. Further, they may have trouble identifying the successful performance of Analytics in an exploratory context due to the unexpected and seemingly random nature of outputs, as well as the need to interpret, evaluate and implement them before value is realised.

Analytics management based on a conventional, deterministic IT project management model is perhaps more common. Traditional project managers may not perceive exploration as delivering any value, and may share their concerns with others in the business. In this way exploration may earn an undeservedly poor reputation. Again, this understanding is in the minority—a shrinking one—and is being steadily replaced by more appropriate agile and Lean Startup approaches. And, once again, it’s a problem easily rectified by acknowledging the uncertain, exploratory nature of Analytics, and ensuring that the sandpit function is not led by traditional project management approaches, nor incentivised according to deterministic KPIs.

The very rare combination of the two pathologies is a perfect storm and a recipe for failure, but even then not irredeemably so. The management issue is the first one to fix in this case, and the analyst issue will either fix itself, or benefit from new resources.

A related argument is a political one, mindful of the organisational status of a unit that “only” does “exploration” as opposed to something “real”. This is certainly a cultural issue affecting many organisations, but there is no reason to take it as a normative argument for how Analytics should be defined in an ideal organisation. At best, it is an argument for a temporary arrangement that may allow Analytics to prove its true worth to the organisation and hopefully rearrange to a more logical structure at a later stage.

A related issue is one of deployment: the argument that for an insight to be valuable it must be deployed. The usual implication is that only Operational Analytics is of value. This is not an argument against the narrow definition of Analytics. Rather, it suggests that the business of Exploratory Analytics is entirely the creation of business rules to deploy in IT systems. The counter-argument here is not so much disagreement as a broadening of the definition of “deployment”, “data” and “IT”. If by “IT” we mean the brains of senior executives—“data” can be unstructured, graphical or tacit (e.g. verbal), and “deployment” can include sharing insights by word of mouth or PowerPoint slides—then there is actually no argument.

Take a predictive model as an illustration. While the model is a valuable operational rule set when deployed on an IT system and let loose on giga/tera/petabytes of data, it is also a valuable summary of behaviour—indicating key drivers, leading indicators, and interactions from which behaviour can be inferred. Such insights are valuable to executives, but not as business rules. Their “deployment” is largely manual and one-off, often requiring additional explanation and visualisation provided by highly skilled statisticians.

Thus, Analytics is responsible for “deploying”, valuable, complex, unrepeatable strategic insights, while the simple, repeatable ones are relegated to IT. Note also that both sets of “deployables”, strategic and operational, can come from the same predictive model.

This completes an outline of a case for a narrow definition of Analytics, demystifying deployment and leaving it to IT, along with model performance measurement, and leaving Analytics to act as an innovation, insight and strategic intelligence function.

Related Analyst First posts:

• *Aligning IT and Analytics to deliver sustainable innovation*