Multi-Entity MDM vs Multidomain MDM

puzzleOn the upcoming MDM Summit Europe 2013 in London this April you will be able to learn about Multi-Entity MDM as well as Multi-Domain MDM.

So, what is the difference between Multi-Entity MDM and Multi-Domain MDM?

To my knowledge it is two terms having the same meaning. It is doing the two main preceding disciplines for MDM being Customer Data Integration (CDI) and Product Information Management (PIM) at the same time presumably using the same software brand.

Multi-Entity MDM was probably the first term used and still used by The MDM Institute while Multidomain MDM is used by Gartner (the analyst firm) and most tool vendors today. For example Stibo Systems is focusing on mutidomain recently in this press release about latest achievements.

Talking about Gartner and the vendor crowd Gartner analyst Andrew White wrote a blog post the other day: Round-Up of Master Data Management (MDM) 2012, and looking forward to 2013.

Herein White bashes the vendors by saying:

“Vendor hype related to multidomain …. continued to be far in excess of reality”.

What do you think? Is Andrew White right about that? And what about Multi-Entity MDM, is that any better?

Bookmark and Share

11 thoughts on “Multi-Entity MDM vs Multidomain MDM

  1. Hadar Gorodesky 17th January 2013 / 20:22

    I think there is much more marketing “noise” about this issue then it should.
    Although many (if not all) of the vendors are saying that they are on route to be multi dimension, my believe is that having multi dimension is not necessarily the target.
    As we all know:
    1. There is quite significant between product, customers etc.
    2. Organizations never do projects on several data type at once
    3. Expertise for product versus customer is not the same.
    4. Looking on the MDM vendors landscape, you can easily see companies coming from PIM background and CDI background

    I agree that vendors should aim to have a single MDM platform/foundation however I think it is still debated issue.

    • Henrik Liliendahl Sørensen 18th January 2013 / 10:37

      Thanks for commenting Hadar. All valid points in my eyes.

  2. Clive Tiney 18th January 2013 / 11:06

    As Hadar says, there are (or can be) significant differences between data and processes in product and customer.
    I take issue with point 2 as I have implemented product/vendor/customer projects all at once in the same product. And it makes sense – if you set up a vendor and a vendor’s products it would be better not to have to enter vendor details in two places but link the data.
    Generally it’s true though that specialist customer and product systems will do the other job less well, so there needs to be good quality integration between them

    • Henrik Liliendahl Sørensen 18th January 2013 / 11:12

      Thanks for joining and adding in Clive. Good point about vendor/customer actually both belonging to party (or business partner) master data management and thus covering both CDI and PIM.

  3. Bill Hewitt 18th January 2013 / 12:24

    I find this “debate” rather humorous because the only people that define what is and isn’t master data is the business. To say that only customer, product or any other master data type is relevant is short-sighted. For sure, customer and product data are important, but what good is customer master data without financial and cost data to be able to clearly see customer profitability? We’ve long espoused the concept of “any domain” at Kalido because we believe the customer should decide. Sadly, Gartner continues to evaluate vendors only on satisfying a specific use case rather than satisfying the customer’s business requirements.

    • Henrik Liliendahl Sørensen 18th January 2013 / 12:46

      Bill, thanks for “going all in” in this game. Definitely there are (MDM) domains beside customer (party) and product and certainly we sometimes needs solutions for supporting a very important entity no one else is doing or doing it a way that makes your business more competitive than the others. That said it is a balance of being original but not reinventing the wheel.

  4. Mike Wheeler 22nd January 2013 / 14:40

    It’s quite shocking to see a bit about multi-domain/multi-entity MDM and only have people weigh in on PIM and CDI. What about the rest of your master data? Above, Bill Hewitt mentions financial and cost – there are dozens, if not hundreds of others that must be modeled for the business, mastered, and managed in order to ensure that organizations have a fully goverened information foundation to support both operations and analytics.

    • Clive Tiney 22nd January 2013 / 14:55

      Well of course there are lots of data domains that need to be mastered and managed. But are they all domains that need another piece of software to do that job? The issue with Product and Customer/Vendor data is that historically businesses have built the data into a proliferation of systems that can’t/won’t syncronise and as a result businesses have found themselves wading through a boggy marsh of data rather than a good solid foundation to build on. Are all data domains like this?
      Having said that there are undoubtedly other areas where mastering will help; its just that product and people data are the main ones addressed at the moment

  5. FX Nicolas 23rd January 2013 / 10:08

    Hi Henrik,

    Nice discussion! Let me jump in!

    Multi-entity means being able to handle “companies” and “contacts” entities (or “parties” and “locations”, if you like neat modeling), in a single (“customer”) business *domain*. So every MDM solution is multi-entity. Mono-entity systems would be to MDM what a CSV file is to RDBMS. 🙂
    Multi-domain means being able to handle simultaneously multiple business domains (*customer*, *suppliers*, *products*, *finance*, etc) in a single solution. This is what CDI and PIM solutions cannot do.

    We all agree on the fact that MDM is a initiative that *ideally* leads to having all enterprise master data managed in a governance program and a single platform.

    In a such an initiative you would start with “products”, then extend to “customers”, then to “financial hierarchies/cost centers” and “employees”. At that stage, you would build high value relationships such as: “employee product skills”, or “customers product ownership”. With such high value relations, you would be able to solve in 5 seconds problems such as:
    “VIP customer X has a critical issue with product Y. Which employee in my entire organization can I put on the case?”.

    In this vision, you must be thinking multi-domain. Going for a PIM or CDI product is IMHO a short term strategy (hence not a true strategy), leading to a huge “MDM silo” issues on the long run.

    PS: Here at Semarchy, we also wait for a Gartner’s MDM quadrant (I mean, not the PIM or CDI one) !

  6. datasherpa 31st January 2013 / 19:41

    I think that the concept of master data is flawed. Some vendors have abandoned the pursuit of master data and have reverted to keeping versions of the entities typically targeted as master data candidates such as product or party.

    ERP systems, the grandfathers of master data now retain versions of these entities and are retiring the concept of master entities because they do not reflect the realities of the business that demands variability. Products vary across time, space and subjectivity. Master data attempts to collapse these variances into a singularity which is contrary to nature and certainly contrary to human behavior. We are not all alike. The industry needs to develop diversity data management (DDM) solutions and abandon the concept of master data.

  7. Henrik Liliendahl Sørensen 31st January 2013 / 22:31

    Thanks Mike, Clive, FX and datasherpa for raising your voices on what is multidomain MDM and if there is such a thing as MDM at all.

    On the last question I will agree that MDM certainly has to embrace diversity of various kinds in order to be broadly accepted by people doing different business function. It’s not about survival of the fittest data but about survival of data being fit enough, a subject revisited often on this blog.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s