Master Data Management is now mainstream and those of us who have practiced it for a few years are battered, bruised and wearily displaying our scars. Typically defined as the people, processes and systems that govern the core data (e.g. products, customers, suppliers) needed to run a business, Master Data Management (or MDM) requires painstaking work in three broad areas: data standardization, architecture, and governance:

• data standardization – agreeing what to call things, which things are equivalent, which attributes are mandatory etc.
• architecture – where is the data, which is the item of record, how do we replicate the copies when they change etc.
• governance –  who “owns” the data, who is the steward, who gets to change things

MDM has significantly improved data interoperability for many organizations. The practice’s fundamental principle of solving the problem at the core – establishing the “authoritative source” of the data that runs the business – is a refreshing architectural development. However it’s grueling work and it is not getting easier.

The MDM world is growing larger and more complex. Organizations that have achieved single versions of the truth for their Master Data need only peer over one of their four walls to see the next of many more data reconciliation frontiers (product registries, for example). And even within the organization, MDM is an ongoing challenge when you consider reorganizations and acquisitions. When these occur, mapping and translation workarounds proliferate. Inelegant architecture is not the only result; the business ends up suffering from increased maintenance costs and error-prone systems.

And then there is the deceptively named “interim state”. Just ask those exhausted MDMers who have contended with incremental releases of an ERP project as it plowed new data standards into a legacy world of conversions, bridges, manual re-keying and impatient executives.

Help may be on the way. Semantic Technology brings some interesting possibilities to the MDM discipline, particularly in two of the three key areas: data standardization and architecture. This is because Semantic Technology differs from the traditional relational database approach in ways that could solve some specific MDM problems. And importantly, the timing may be right for a symbiotic relationship. The MDM acronym is starting to make its way into the strategic discussions of non-IT business managers. We are seeing senior executives actually starting to talk about the importance of consistent data definitions across the enterprise. Semantic Technology (not yet a mainstream term within enterprises) may be positioned to hitch a ride on the MDM movement.

Ontology
Generally speaking, an “Enterprise Ontology” in the Semantic world is equivalent to an Enterprise Data Model in the Relational world. (The word “ontology” is a daunting term in philosophy, however in information science it is simply a formal representation of a set of interrelated concepts). Developing an ontology is similar to creating a data model. However, one important difference is that ontologies allow you to seamlessly move from logical design to physical implementation, bringing logical rigor along for the ride. Said another way, when you establish a definition using the Web Ontology Language (OWL), you have encoded it in machine-processable as well as human-readable form. What follows are a few areas where Semantic Technology and ontologies can help with MDM data definition and architectural issues.

SameAs
Semantic Technology’s principle that two or more instances are allowed to refer to the same thing may have advantages in the MDM world. Relational databases (and the applications that use them) behave as if every row in a table is unique. So when a customer database contains “IBM” and “IBM Inc.,” the system behaves as if they are two different customers. (Then think about the work that is required to combine duplicate records). In the world of ontologies, at least in principle, we should be able to simply declare the equivalence of the two instances and be done with it.

Friendly Modeling
Semantic modeling may be able to bypass some of the logjams that often arise in traditional data modeling sessions. Think of the times we’ve sat in discussions where two departments use different names for the same entity. An example could be ‘supplier’ and ‘vendor’. When this happens we feel compelled to make a choice because we know an entity can only have one name. As a result, the modeling session invariably grinds to a halt and a massive change management activity looms ahead.

When designing ontologies we find we can often get around this roadblock by separating the definition from the name and taking advantage of the “namespace as prefix” technique. We can draw something called Purchasing:suppliers which is equivalent to A/P:vendors. Even if the term ‘supplier’ already has meaning to the A/P department (say a subset of vendor) all involved should be comfortable knowing that ‘Purchasing:supplier’ is something different. The modeling session can keep going.

Explicit Semantics
As mentioned earlier, a strength of Semantic Technology is that data describes itself in machine-processable form. This eliminates a lot of human interpretation. No matter how good a traditional data dictionary is, it is invariably out of synch with the semantics that are embedded implicitly in programming code and relational database schema. Though learning to read it might take some work, an ontology is closer to a self-documenting piece of code than we’ve ever seen1.

Also, Semantic Technology allows for definitions to build upon themselves. Once you’ve defined a “Financial Obligation,” for instance, you can use it in some other part of the ontology and everyone can be sure of what it means. If it were simply a text definition in a relational database environment, it could end up being used multiple times without assurance of it meaning the same thing. Further, Semantic Technology will allow you to actually test the consistency of the meaning of “Financial Obligation” wherever it is used.

The beginning of an interesting relationship
Now that MDM is beginning to resonate with people outside the IT organization, it is entirely possible that it could help drive semantic technology adoption. As it matures, Semantic Technology’s unique characteristics can aid MDM programs as they struggle with agreeing on definitions and managing physical data. As a practicing MDMer and a recent convert to Semantic Technology, I’m confident that the application of Semantics holds a key to some of the more pressing problems in MDM.

1We’ve been successful improving ontology readability through a tool that visually renders OWL