Warning: Creating default object from empty value in /home/johnnz/public_html/wp-content/themes/simplicity/functions/admin-hooks.php on line 160

How SCV Causes Fragmented MDM

It’s ironic that a major activity, whose advocates claim will bring integration to Master Data Management (MDM), is actually a major driver of MDM fragmentation in enterprises.

Sadly, in the case of Single Customer View (SCV) this is the case and, when you look closely at it, fragmentation is inevitable.

Wrong Place, Wrong Direction

Single Customer View (SCV) is an initiative that is starting in the wrong place and heading in the wrong direction.

It is starting in the wrong place because it is mistaking a relationship for a Master Data Entity.

It is heading in the wrong direction because it is in danger of developing into a tribal activity, determined to gather all of the followers of ‘Customer’ under one banner, blind to the damage that it is doing in the enterprise.

Unity is Good! Is it Not?

Because MDM has become so fragmented over recent years (mainly due to the almost epidemic spread of off-the-shelf silo centric software) that it might seem that any initiative that would bring integration would be a good thing.

It would. But, contrary to what you might initially think, SCV is no such initiative. On the contrary, in its current form it is in danger of creating a major rift in MDM in every enterprise that practices it.

Seriously Compromised Venture?

SCV is a fundamentally flawed approach to MDM as it is based on a major misconception.

The fact is that Customer is NOT a Master Data Entity, it is merely a Role that a Third Party plays in its commercial relationship with an enterprise. The true Master Data Entity is the Third Party or, more simply, ‘Party’.

‘Customer’ is just one Role that a Party can play.  Other roles are ‘Supplier’, ‘Guarantor’, ‘Beneficiary’, ‘Employee’, etc.

All of these Roles are just as vital to the success of the enterprise as that of ‘Customer’.  For example, without some instance of Party playing the Roles of ‘Supplier’ and ‘Employee’ there would be no opportunity for any Party to play the Role of ‘Customer’.

It is because SCV totally ignores these other critical Roles, that it is creating MDM fragmentation.  When an enterprise fosters the idea of a single ‘Customer’ view in its customer facing departments, it actually creates the ludicrous situation of forcing other parts of the enterprise to have such things as a single ‘Supplier’ view, single ‘Employee’ view, etc.

Every part of an enterprise, whether it is customer facing, supplier facing or managing some other commercial Role with Party, needs to strive for a Single Party View.

Party is the Master Data Entity with whom the enterprise has all of its commercial relationships.  It is through all of its commercial relationships with Party that an enterprise derives value and drives revenue.  Without Party, in all of its Roles, an enterprise would cease to exist.


The integration of Master Data Management in enterprises is essential if the true benefits of MDM are to be realized and an enterprise is to prosper.

Single Customer View is a flawed approach to MDM that will result in even greater fragmentation than at present.

If you are serious about achieving successful MDM in your enterprise, then you must speak out loudly about the flaws of SCV and reject it as a viable MDM practice.

Every enterprise must strive to achieve a Single Party View.

MDM Resources

Here are some MDM Resources that you might find of value:

Work With Me

If you would to work with me and prevent these errors occurring in your enterprise then  email me at john@jo-international.com or Skype me on johnowensnz. I look forward to connecting with you.


6 Responses to “How SCV Causes Fragmented MDM”

  1. Philippe Bourgeois July 4, 2013 10:33 am #

    Thank you very much for your post John! You are pointing to difficulty that we are facing in MDM and in particular in Data Governance topic.

    I fully agree with you when you propose to integrate data in a higher conceptual level than the role played. A customer is a party playing the role of customer. But as always in modeling area, the issue is to determine where put the limit. Indeed, if you go further, you could make it even more generic by modeling a MDE that would be the “legal entity” that plays a “party” role, or an “entity” playing a “legal” role and so on until the Higgs boson (or beyond :-) )

    The major stake for me is hidden in the data governance. I the case of customer/party you describe, who will be the owner of “parties” ? Finance ? Sales ? Supply-chain ? HR ? Legal ? Executive Management ?
    Let’s take a small illustration. Imagine that sales department would like to create a new customer XYZ based in Lausanne (Switzerland). In the PARTY MDE already exists XYZ S.A. company based in Geneva which has been created by Legal. Let say that XYZ S.A./Geneva is the legal name of the company and XYZ/Lausanne is where this company is physically located. Who is able to decide whether we are talking or not about the same party ?

    Personally I don’t have the answer, but that’s the kind of issues we are struggling with and that could be solved by a proactive data governance model like a top management decision which would give the responsability of “parties” to a neutral and transversal department.



    • John Owens July 4, 2013 11:52 pm #

      Hi Philippe

      Thank you for comments.

      Setting the limit on the definition for Party can be made relatively simple by asking and answering a series of questions like the examples given below.

      “In the context of this enterprise, what is he definition of a Party with whom we would want to enter into commercial relationships? Is it the legal entity, or a trading name of the legal entity, or something else?”

      “In the context of this enterprise, what is the Unique Identifier of Party? (This will NOT be a code) What is it that makes one occurrence of Party uniquely different from every other occurrence of Party?” For example, is IBM Dallas different from IBM washington?

      “In the context of this enterprise, is there a significant difference between the legal entity and its trading outlets at specific addresses that we would need to know about ans model?”

      The questions must always be phrased “in the context of this enterprise” as the view of what constituted a Party for a stationery wholesaler in Detroit would be different to the view of the Internal Revenue Department in Washington.

      The question sometimes needs to refined to “in the context of this enterprise and the context of the Business Function” (where Business Functions is a a core activity) For example, when placing contracts this might be done with the legal entity, whereas sales and purchases are done and measured at the level of the trading outlets.

      Trying to give ‘ownership’ of a Master Data Entity (MDE) entity to a particular department can present problems and start ‘turf wars’. These can often be avoided by giving ‘ownership’ to the business rules that drive the definition of the MDE. When this is the case, then everybody who carries out a Business Function in which the business rule is embedded has the (corporate or legal) responsibility to define, create and update the MDE in the correct form.

      I hope that this helps.

      Again, thanks for your input.


  2. Richard Ordowich July 1, 2013 12:32 pm #

    I agree that the single customer view is a flawed approach but then I would add that MDM itself is flawed. There is an assumption that the diverse instances of customers can be somehow “mastered” and that the technology can master the data.

    Tracing back the archeology of customer data exposes interesting characteristics. The people who specified the requirements for customer data for each system were probably different. Different capabilities, knowledge, experiences and biases. Then each of the model designers themselves each had their own perspectives. The attributes and metadata varies in each system along with the relationships. Then the business policies and processes that affect the instances of customer data varies from system to system. I suggest a relative state of customer data chaos exists to begin with.

    Then we attempt to apply rules to harmonize, link, merge, consolidate, and integrate this data. The rules becoming increasingly complicated and contradictory and confusing. Which isn’t surprising since the humans who each created these diverse environments were themselves complicated, contradictory and confused.

    We think we engineered a solution we call MDM to create order in this chaos. But we begin to realize we need humans to intervene to resolve the conflicting rules in the MDM system and we add another level of chaos to the environment of customer data. Success is typically creating a view of the customer (not a single view) for a single person’s use or perhaps for the use of a particular department such as finance. But this view is only temporal. A new person such as a CFO comes on board and the view changes. Or the business changes and this view is no longer suitable. We are then back to the beginning of defining a new view, but once again only within a confined context.

    Understanding and appreciating the above is critical before starting down the MDM path (or as some as suggested, journey). Realizing that this maybe a journey to nowhere.

    • John Owens July 1, 2013 7:18 pm #

      Hi Richard

      Very nicely put. However, a great deal of the confusion you describe could be avoided in the first place if the enterprise had a clear definition of what types of Third Party they wished to trade with and then modeled this as part of the Logica Data Model – which every successful enterprise should have.

      Then, before they bought any off-the-shelf software, they would compare their definition of Party to the software definition and, if it did not match, reject the software.

      Having a clear, consistent view os Party across an enterprise is not difficult – if people have the right skills and use the right tools. Sadly, there is a severe lack of the appropriate skills out there and very few good tools.

      But it is possible!

      Thank you for your feedback.


  3. Elena Zhuravleva July 1, 2013 11:01 am #

    Thank you for interesting insight.

    But really i didn’t get you know what? Is it a great problem to add 1..n attribute Role to SCV and download Supplier/Employee data into it?

    • John Owens July 1, 2013 11:24 pm #

      Hi Elena

      The real problem is not the means of holding the data on Party, it is the fact one part of the enterprise is gathering information on what it calls ‘Customer’, another part on what it calls ‘Supplier, another on ‘Employee’ and so on.

      What none of them realises (because they all operate in organisational and systems silos) is that these are all the same thing, they are occurrences of the same data entity, namely Party. They need to become aware that there is no such entity as Customer, Supplier, Employee, etc.. and manage Party in a consistent manner across the enterprise.

      I would also advise against the ‘add another field solution’ approach to database design. I used it often in my programming days and, although it sometimes works for small databases, it is not a robust solution for use in any large system.

      Always start with the Logical Data Model (LDM). Modelling your data at the logical level will enable you to build robust databases of any size for any industry.

      Thank you for your input.


Leave a Reply