Alternative title for this blog: The Difference between Master Data and Application Data is Huge – and Missing!
Many users, and even some analyst, confuse master data with the other data used by a business application to support the intended work, analysis or business process. Both types of data are used and needed by business applications to instantiate the task. However, this distinction, relatively new in the industry, is lacking in a great many organizations. This distinction is increasingly becoming very important as business systems are getting more complex. With new business models emerging, new mobile apps, new cloud offerings, stuff is just getting more complex! Worse, some vendors don’t even want end users to “get this” distinction since those very same vendors are not (yet?) ready to help end users sufficiently.
Business applications, including operational line-of-business applications (ERP is a good example) as well as downstream analytical applications, or the new class of operational line-of-business analytical applications, all use data. Some of that data persists in some form in other applications. Sometimes that data persists in all the major applications. Some data persists in just one application. And some other data persists in several applications. We only formalized “master data” 6 or seven years ago in order to express the problem that it is inconsistent across those common uses.
So the difference between master data and application specific data is this:
- Application specific data is used ONLY by that application. This data does NOT appear anywhere else in the application landscape.
- Master Data is common across many applications. It is not specific to any one business applications.
For the great majority of our own IT lives this distinction was not that important.
“You want a new app, sir? Just tell me what data you need – and I’ll get it or create it for you. I will even supply you one application at a time.”
This has led to silo mania. You know this to be true – most of you live this experience every day.
Some MDM vendors will help end users “get this” distinction and can help them build sustainable, operational information governance programs that takes this distinction into account. If you DON”T take this distinction into account, the risk is that your new MDM hub will literally, over time, develop into yet another bloated ERP-like data model! We will have failed and gone full circle.
Other vendors don’t like this distinction since they only sell tools to help manage data in an application – probably their application. Better, they (the vendors) will even sell you this “application data stewardship” capability as if it was designed for MDM. A solution designed to manage the data maintenance in a specific application will differ in functionality to a solution designed to govern and steward information across any and all applications. The former is not an MDM-like design architecture; the latter is exactly that.
If we don’t make this distinction, the result is clear:
- Data silos proliferate
- Data integration tends to focus on copying data and moving it, even transforming it, but rarely helping in governing it for reuse
- Application, integration and storage (IT centric) costs are higher than they should be
- IT-based business agility is less than it could be
Bottom line: Investments in information fail to deliver the expected benefits and as a result, information driven business outcomes suffer.
Thisdistinction in the data is central to effective application, information and SOA strategy that it’s hard to convey. If DNA did not have a common map from which to copy itself, errors would overcome the purity of the living form. If printing presses did not offer a way to standardize the printed word, the core messages in each Bible would not persist from one copy to the next.
But even today, 2014, we see too many inquiries from end users where this distinction is not understood. If we don’t collectively get this point across, and embed it in our IM strategies and architectures, MDM really won’t succeed as we want, and need, it to. EIM overall will grind to a halt…. More to follow in Research in 2014.
Category: Application Architecture Chief Data Officer Data Governance Data Stewardship Data Warehouse Defining Master Data Enterprise Information Management Information Architecture Information Governance Information Innovation Yield Curve Information Leadership Information Management Information Stewardship SOA SOA Strategy Tags: