Your future requires you to define your real master data

Register now

I was talking today to a real smart client. They had two questions that begat one premise.

The premise was that their future, now, was getting more complicated: It was increasingly clear they would have to operate with a multi-cloud environment; yes there were fewer application vendors overall compared to, say, 10 years ago, but still quite a few. There would also be persistent a number of on-premises applications too. The future was, we agreed, going to be more complex than when all applications were on-premises. This is because the ability to achieve and maintain semantic consistency across the growing landscape was harder.

When you subscribe to a SaaS solution you tend to not be accessing the application metadata, nor its business rules, and no you are not paying for the rights to change either or both. So you end up looking for new services to help integrate and stitch together the complex fabric – but that integration work is far harder than it was when on premises for the lack of access to all the metadata, rules, ETL and so on. Additionally micro-services make it more complex; and API’s just give you access to un-trusted data quicker.

What to do?

Here is where the clients’ questions were really smart, because they went (I believe) to the heart of the most important decisions that are needed to be answered by every organization:

  1. How much of our MDM program can or should we outsource, and where is the liability?
  2. Should we maintain any IP internally for our core business process and data models?

The first question is pretty much word for word; the second is somewhat paraphrased but captures the essence of the dialog.

We parsed the work of MDM into core elements (which we have done many times before. Here is a short explanation: The Case for Stewardship versus Governance. Some of the work needs to be executed by business leaders; some of the work can be outsourced but firms that get the mix wrong struggle with effective MDM or data (and analytics) governance.

The second question was really more interesting to me since it reminded me of a pattern we saw 20 years ago. That pattern we saw concerned the rise of ERP and what it meant for the then known skill and practice related to a firms internal data or information architecture.

Basically, as firms adopted large-scale ERP systems they got rid of their information architects. The assumption was that a firm as adopting the ERP vendors’ data model.

So why do I need to maintain my own view? That turned out to be a bad move and as MDM got moving some few years later, the pickle got worse since MDM became so complicated, it almost all came to a grinding halt. One of the problems was the scoping and boundaries of MDM. This was cleaned up fairly recently: Comparing Master Data Management (MDM) with Application Data Management (ADM). But it takes a lot of effort for a firm to accept the past failures and shift gear to get it right at the second (or third) time of trying.

Here was the ah-ha: We (the industry) have had this conversation before. It turns out that in 2017 I came up with a name to capture the core data that underpins the whole MDM/ADM/application integration/multi-cloud complexity issue. I coined the term business information architecture.

In a nutshell, if you follow all our MDM advise, and ignore most of what goes by that name in all the books you can buy (and I have read many of not most of them), you will discover your business information architecture and this is the least amount of data that drives the most business impact; it is what a firm needs to define and keep, to help ensure you can manage the growing complexity in the multi-cloud environment that is in your future.

We never used this term in our published research; the concept and how to define it emerges contextually in our research notes and the advice we give clients. But the idea is not that complex; how to get there is the secret.

Have you defined, and do you govern, the most important data in your business?

(This post originally appeared on Andre White's Gartner blog, which can be viewed here).

For reprint and licensing requests for this article, click here.