Data Layer fireside chat

The Mutable Enterprise Data Layer – A fireside chat about the data layer, which is what “grounds” the disruptive idea of “Mutable” in the real world.

The Mutable Enterprise is a disruptive concept. It is not a better mousetrap but a new way of doing business, potentially as disruptive as Uber is to the black/yellow cab. I want to discuss it as it applies to data. Of course, the Mutable Enterprise is much broader than that. It is broader than IT let alone data, but data is my focus: at least today.

The first thing to bear in mind is that not everything has changed and it would be foolish not to exploit what we already know. Just as both Uber and conventional taxis have, at a high level, to move “people” between “locations” in “vehicles”, the data (entities and attributes) in the Mutable Enterprise is often not that different to the data in the conventional enterprise. What this means is that there is an underlying “data layer” beneath the Mutable Enterprise which “grounds” this disruptive approach in the real world. After all, even if the journey towards the Mutable Enterprise is important, it is vital that you make money today, and keep your existing customers engaged, or you will be out of business before you reach your goal.

It isn’t intended to be absolutely comprehensive but it is intended to be illustrative of the various elements required at this level. To put this into context, there are four layers within the Mutable Enterprise from an IT perspective: the Infrastructure Layer (cloud, software-defined architectures, hardware and so forth), the Data Layer, the Action Layer (applications, processes, DevOps, SaaS, visualisation, collaboration and so on) and the Interface Layer (social, mobile, IoT, legacy and others). The lower three layers (that is, excluding the Interface Layer) are encompassed by Automation as a goal and by Trust (Identity and Governance in the Data Layer) as a guardian.

Clearly, there is a lot to consider here. And I don’t have space to talk about it all. So, let me a take view from ten thousand feet: what does this mean in terms of innovative strategy, and what are the risks, if you adopt innovation too unthinkingly, or take the hype from vendors too seriously? Innovation is (should be) good, but it needs to be tempered with common sense, even in the brave new world of IT innovation!

For instance, there is currently an annoying advertisement by HPE (Hewlett Packard Enterprise) about analytics, in which it is stated that the company in the advert will manufacture 98,352 widgets in the following month, and that this is a fact not a projection. And that’s wrong. Why? Because, as Harold Macmillan said, “events, dear boy, events”. 98,352 can only be a fact if everything is pre-destined and pre-determined. Not only is this intrinsically unlikely but in a Mutable Enterprise – where everything is subject to change and innovation – it is arguable that it is actually undesirable to work from immutable figures that are cast in iron.

I mention this for a number of reasons. The first is that there is this mistaken assumption that data is everything. Data is just that: data. On its own it is meaningless: it needs context to give it meaning. Even then it needs corroboration. To illustrate, consider a sequence of numbers and letters. This might be a password, it might be a vehicle registration number, it might be a postcode or it may be a great many other things. Let’s suppose that context defines it as a postcode. But is it a valid postcode? And even if it is a valid postcode does it actually represent any sort of truth? Do I actually live there? I might not. So data is not factual unless it is contextual and corroborated.

So, do you really want a data-driven enterprise or would a fact-driven enterprise be better? Better certainly but otherwise no. Because facts also need context. Let’s suppose that we did actually manufacture 98,352 widgets last month. What does that tell you? On its own, nothing useful. How does that compare with the previous month? With this time last year? How does it compare with sales? Are we are overproducing or under-producing? What staffing levels did this require? Is productivity improving or declining? What were our costs? What was quality like? How many returns have we had? What is the rework? The difference between the context for data and the context for facts is that the former is based on metadata (data governance providing corroboration) and the latter is based on key performance indicators, reporting and business intelligence. Once you have these metrics then you are generating useful information about the business.

You might now imagine that the information-driven enterprise might be a good thing, as opposed to being fact-driven. However, what you really want to know about is information in the context of your business goals, both tactical and strategic. And here we come to the Mutable Enterprise, because business goals are never static, so the context within which you gather information is constantly changing and evolving.

We might call this the analytics-driven enterprise. This is where I think most companies are heading. And this applies not just to line of business environments but also within support services such as IT. More and more IT focused applications – data governance, security, metadata management and so on – are having analytics and visualisation capabilities built into them, in a way that is comparable to operational applications.

However, there is a drive to go further. To what we might call the insight-driven enterprise and, more broadly, the actionable insight-driven enterprise. I have no quarrel with the former: using information and analytics to try to better understand your current business environment and your standing within it, seems entirely sensible to me. However, I have profound suspicions about the latter.

The problem with actionable insight is the drive to automate the actions. To take a simple example, you might have an algorithm that uses applicant postcodes to help determine if he or she is a suitable candidate for a loan. This is on the basis that if you live in a poor neighbourhood you must be poor and must be a poor credit risk. Does this follow? Of course it doesn’t. You can think of all sorts of reasons why someone might choose to live in a less wealthy environment without impacting on their loan worthiness.

The fundamental problem is not with the algorithms. It is with the people who deploy or commission these algorithms without understanding them fully. And the truth is that the vast majority of business people who get to decide on the deployment of this actionable insight by way of algorithm have no understanding of the statistical principles that underlie these models. They don’t understand the concept of significance within statistics, they don’t understand the importance of having sufficiently large sample sizes, they don’t understand how important it is that data be representative and that there is no bias within the dataset being analysed.

A further problem with this sort of algorithmic processing is that most companies do not collect feedback to update their processes, which results in static algorithms that gradually get more and more out of date. Exactly the opposite of a Mutable Enterprise.

This is not to say that algorithmic processing is all bad. In the right circumstances it can undoubtedly be beneficial. What is needed is some way of monitoring the definition, evolution and use of algorithms and analytic models. Have they been created on the basis of an adequate and appropriate dataset, are they being updated through real-world events and are they being used appropriately? In other words, we need governance for analytics. While there are certainly model management capabilities offered by various vendors, I don’t think they provide governance in the way I have described it, though these may be a good place to start.