Takeaway: It can be surprising what little things can be a big problem for enterprise applications when trying to manage the data that each system produces.
One of the things I’ve noticed over the years in IT is that we often encounter the same problems, no matter what our specialty may be. Any time you go to an event or trade show and start talking to someone who has the same or a similar job title as you, you’ll quickly find affinities and possibly share a laugh or two.
Those who deal with enterprise applications face many of the same challenges; there is a big risk in today’s technology landscape on managing multiple enterprise applications within an organization — and the master data that goes with them. Master data management (MDM) is a term generally used in the Big Data circles (for a good backgrounder on MDM, read this narrative at Microsoft’s MSDN site.) But I’m convinced that Big Data can exist in “little” places (in fact I did an audio podcast on the topic). Now, I don’t want to scare anyone away with talk of Big Data — and the truth is I’m, indeed, afraid of Big Data myself. The more I know about it, the less I want to do with it. But besides Big Data purposes, MDM is a critical first step to fending off potentially big problems in the worst of places: your enterprise applications.
In an organization with multiple enterprise applications — even just two — a “little” data problem can crop up between them, and it’s very important to note. The reality today is that new enterprise applications are not all driven from the internal Mainframe or AS/400. The natural choice today may include Software-As-A-Service (SaaS) models, or maybe you’ll make an application decision due to platform support (such as rich virtualization support for DR).
This is where little data can lead to Big Data problems. Let’s take a common example. I had a chance to stop by Enterprise Data World in San Diego recently, and Stijn Christiaens from Collibra explained how some applications may refer to the United States as “US”, “USA”, “United States”, or even more variations. That’s a simple example, but those kind of anomalies between system data have the potential to keep important details buried, or in more relevant terms, decrease efficiency, agility, introduce increased costs, and make compliance difficult.
It may seem simple, but as we grow and interconnect our enterprise applications today, we have a great risk of little things causing big problems. When it comes to MDM and setting a framework to respond to business changes in your organization, how do you get the organization focused on details like this? Share your strategies below.
Powered by Facebook Comments