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

There's No Such Thing as a Customer!

Customer Is Not Real

If your data models or databases have an item called Customer, then you might be further away from Data Quality than you imagine.

This might come as a surprise to those business people and data quality practitioners who put Customer at the heart of their Master Data Management (MDM) practices.

The Great “Customer Entity” Myth

“Customer” as a Data Entity is a myth. It only exists as such in embryonic Logical Data Models and in standalone, unintegrated databases.  As an enterprise develops and improves its Logical Data Model the entity Customer should disappear. If it does not, then there are severe problems with the Model and with the level of modeling skills.  How soon should it disappear?  In many cases, it could be removed as as soon as the entity Employee is added to the model, but it should definitely go once the entity Supplier is added.

Data Model Evolution

The following diagram shows the entity Customer as it might appear in a Logical Data Model in its early stages of development.

customer_data_structure

We now add the entity Supplier to the logical data model.

supplier_data_structure

When we look at the above two diagrams we see that their layout is almost identical.  The only difference is the names of the entities.  This is one of the major benefits of using the Dead Crows Fly East layout convention for data models.  It highlights similarities in structure and forces us to ask, “Are these really the same thing?” With the above two examples the answer is a very definite “Yes”.

In essence a Sale is a commercial transaction between the organisation and another party, which can be either a corporation or an individual.  Likewise a Purchase is commercial transaction between the organisation and another party, again either a corporation or an individual.

So, Sale and Purchase are simply synonyms for Commercial Transaction.

Generic Data Structures

One we are able to spot the similarities in structure we are able to identify and remove lots of duplication from the Logical Data Model.  Doing this for Sale, Purchase, Customer and Supplier would give us the following generic data structure.

party_data_structure-copy
Derivable Relationships

So what happened to Customer and Supplier?  Were they merely synonyms for Party?  Not really.  When we develop a Logical Data Model and introduce more sophisticated generic structures, some entities disappear completely.  Supplier and Customer are two such entities.  They disappear because they were never true entities in the first place.

What they really represent is a derivable commercial relationship with a Party.  It is derivable because it can be determined by asking a question such as, “With which Parties have we had a Commercial Transaction where  the Transaction Type was ‘Sale’?” The relationship of that party to the enterprise is “Customer”.

By asking other similar, appropriate questions we can also find out what Parties have relationships of “Supplier”, “Employee”, “Director”,  “Creditor”, etc.

Read more posts on Data Structure Modelling or look at Data Structure Modelling eBook

Leave a Comment: I would love to hear what you think, so please leave a comment in the box below.

Share With Your Friends: Click on the Retweet icon to the right to share this post with your friends and colleagues.

Tags:

17 Responses to “There's No Such Thing as a Customer!”

  1. Willem January 23, 2012 8:07 am #

    I think this discussion is about declarative versus derivative roles. I just read about these in Len Silverstons Data Model Resource books.

    I agree that a Customer is not a basic entity, but a relationship between two parties. Still, an enterprise could have the need to declare that relationship (before the first transaction has occurred) rather than derive it. Also, extra attributes may be required for that specific relationship subtype.

    Example 1: An enterprise may want to export all its customers, whether they have done any transactions [at that time] or not.
    Example 2: When choosing a customer for a sale, the system may want to restrict that choice to declared, valid customers.
    Example 3: When a new customer is accepted, an enterprise may want to store his credit limit and customer number or other customer-specific attributes.

    This requires a subtype of Party-Party-Relationship, which may very well be called “Customer”. The extra attributes could be added to this entity.

    Len Silverston proposes PartyRoles to declare roles, I currently think I prefer expressing all roles as Party-Party-Relationships because no party is every just a Customer, but always a customer OF/TO another party.

    My opinions are not set in stone though, I’m really curious about other views.

    -Willem.

    • john January 24, 2012 2:30 am #

      Hi Willem

      The discussion is really about hard coding what are actually derivable Roles. Amazingly, very many enterprises do this and have ‘Customer’, ‘Supplier’ and ‘Employee’ both hard coded and duplicated in several systems around the enterprise.

      The Role ‘Actual Customer’ will always be derivable as, until a Party makes a purchase, it is not actually a customer. Running a report that lists all Customers to whom the enterprise has ever made a sale would be an oxymoron!

      However, declarative Roles are usually desirable, but it depends on what business rules exist. For example, it might well be desirable to be able to identify Parties to whom the enterprise would be willing to sell goods or services before actually doing so or, just as importantly, those to whom it would not be willing to do so. The data structure, to support this would depend on those business rules governing this business decision, e.g. would an extra attribute in Party suffice or would it require a relationship to another entity to support the rule?

      The structure required to support examples 1, 2 & 3 would again depend on the business rules.

      I will expand on this model shortly and post it in a new blog. Let me know what you think when I do.

      Once again, thank you for your input.

      KInds Regards
      John Owens

      • Bhushan January 25, 2012 10:23 pm #

        Hi John,

        This is a very interesting discussion. Wouldn’t you think that in a mutli-product, multi-division company with a lot of cross-selling, a party-partyrelationship would be appropriate? For example, Mr. Z, the high-net-worth-individual has a savings account with ABC Bank, so he’s a client of ABC Bank, while he’s a prospect for ABC Insurance, ABC Wealth Management etc. Of course, if all these divisions are maintaining separate data models that never talk to each other then, all relations can be wrt a base party, and a property of the Party business object.

        Thanks,
        Bhushan

  2. Paul Erb January 13, 2011 3:04 am #

    Hello, John–

    It’s worth asking WHY this lower level of abstraction is so appealing to modelers. Treating the cause may help alleviate the symptoms.

    In my recent and repeated experience, the world is full of data modelers. You might even say that human beings are data modeling engines, since we make so many assumptions when we speak. (Example: “humans speak” is a data modeling structure. As Dave Dutton always says, data modeling is sentence diagramming. And vice versa, I say.)

    Faulty modeling comes when modelers prefer to model data according to their horizon of expectations, and to use the modeling to eliminate ambiguity or uncertainty. To think of a transaction abstractly is to think of it going two ways: out, or in. But to say “Customer” is to think of proceeds coming only in. Which is less ambiguous, and serves the local interest of the client who is paying for the data model.

    Abstraction is instead for disinterested philosophers, who rarely have the ear of the paying customer with his eyes on the visible horizon. So data modelers must learn to imagine, and to convey their imagination of possibility–and of the flexibility your model proposes–to the client. Only then can the frontier of the business be expanded, and waste avoided when the client crosses the near frontier, and facing new circumstances, wishes that he had modeled his future information more flexibly.

    Paul Erb
    USA

    • imm January 24, 2011 8:17 am #

      Hi Paul

      Thanks for the comments. I think what you say is valid. The “worldview” of the data modeller is far too often so narrow as to present the business with a thought bottleneck rather than in information highway.

      Good to hear from you again.

      John

  3. Richard Ordowich January 10, 2011 3:38 pm #

    I would like to be in the room when some technical maven declares to the senior management:

    There’s No Such Thing as a Customer! Customer Is Not Real!

    Taking this to its nonsensical conclusion, nothing in a database is “real”. It is a fictional representation of an imaginary reality.

    The approach suggested is a technical and database view of reality. But if the reality in the database does not reflect the realities of the imaginations of senior management, a paradox results. The paradox is usually resolved by senior management declaring that their reality is the only one that applies and those technical mavens are told to accept this reality or find another imaginary fictional construct (company) in which to create their own version of reality.

    Practically speaking every entity can be resolved to a single representation called a “thing”. If we design databases to contain things then the problem of abstracting these things into constructs such as customer, supplier, employee is made easier.

    Things can be represented in the illogical data model.

    Which leads me to a more profound question. Should a logical data model conform to logic? Seems like logical data modles may not be so “logical” after all.

    • imm January 24, 2011 9:17 am #

      Richard

      The title of the post was meant to be provocative in order to get people thinking about some of the major modelling errors being carried out in the world of Master Data Management (MDM)

      In business there are very definitely individuals or organisations with whom an enterprise may a relationship that can be described as “customer”. This relationship is of vital importance to the enterprise as it is from it that the enterprise derives most, if not all, of its revenue.

      The enterprise can also have a different, yet equally important, relationship with these same individuals or organisations that can be described as “supplier”.

      So are these individuals or organisations “customers” or “suppliers” or both? No, no and no. They are individuals or organisations, collectivly called “Parties” or “Third Parties”.

      It is the relationships with these Third Parties that is “Customer” or “Supplier”.

      So is there such a thing as a “Customer”? Yes! But it is NOT a Master Data Entity! Rather, it is a DERIVABLE relationship with a Third Party and good data analysts will very definitely make this essential difference clear to senior management.

      John

    • OldArchitect November 19, 2011 6:28 am #

      This is all too familiar. I am also dealing with TCA and having experience with Teradata’s FSLDM model, the whole abstraction verses specificity becomes painfully obvious that trying to force abstraction on the business is a very geeky approach. Put yourself in their shoes, some computer geek tries to convince you that a good model shouldn’t include “customer”. Really? Or on the other hand, that party has some inherent great abstract meaning and that good business people will understand its great super powers to conquer the data world. I think sometimes in our zeal for the perfect model we forget why we model. We slip in our preferences for flexibility and physical implementation biases into our logical model and we wonder why the business goes away thinking we’re geeks. I hate to break the news – we are if we give into our natural inclinations. There is a balance between abstraction and specificity and the need to respect business terminology (while also requiring “good” definition at the same time) is more art than science. In the end the model and the structures the business is exposed to better match what makes sense to them. If we don’t do that we fail, end of story.

      BTW…don’t forget – abstraction requires reference data sets that make them specific. Purchased models NEVER respect that critical success factor. And reference data sets are not visible on a model. Sorry, party type means absolutely NOTHING to a business user until it is in the context of its contents.

      • john November 20, 2011 8:09 pm #

        Thank you for your comments.

        I admire your passion, however, I feel you are falling into some of the many traps that surround this subject. You talk about “abstraction” and then get it the wrong way round. It is “customer” that is the abstraction, not “party”. “Customer” is merely a role played by “Party”. Sadly, when people sitting in departmental silos were building applications, they created the abstract entity “Customer” from the role or relationship that a “Party” has with the business. People in different silos made similar mistakes with “Supplier”, “Employee” and several others.

        “Party” does NOT have an abstract meaning. It has quite a specific meaning and is consistent across the whole business. It the relationships that a party has with the business that are abstract – and can indeed be derived, or abstracted.

        You then infer that good data modelling is more an art that a science. This is quite untrue. Good data modelling always applies a set of rules and standards that remove ambiguity and turn it from a black art, that can only be understood by a gifted few, to a logical practice that can be understood and practiced by all.

        Good analysts will always listen to business terminology. Further, they will look for the reality behind the phrase. They will ask questions like, “What do you mean by ‘Customer’?” The business would reply with something like, “anybody to whom we sell a product or service”. The analyst would then ask, “could you purchase things from these people” and “could you sell things to someone who works for you?”

        These questions would quite clearly show that customer is an abstraction and simply refers to a relationship that the business can have with a party. It is in fact a derivable relationship. When you realise this you will see that to have “Customer” as a master data entity is as erroneous as having “Debtor” or “Creditor”

        One other thing, there is also no such thing as a “business user”. This is a horrible, meaningless term concocted by IT departments. There are only two industries that consistently refer to their customers as “users’. One is IT and the other is drug pushers. Sadly, it is also quite possible that the latter group might value their customers more that the former and, some might suggest, do less damage!

        Once again, thanks for your comments.

        Regards
        John

  4. George McGeachie January 10, 2011 12:47 pm #

    While I agree with your overall premise, I believe that there IS a role for Customer and Supplier entities, and potentially sub-types of those entities, in two specific circumstances:
    1. when the focus of a data model is the management of relationships with suppliers or customers. For example, financial institutions are obliged to keep track of customer-related information for money laundering, ‘know your customer’, and several other regulations.
    2. When the data model focus is gaining agreement on the key business concepts – it would be very difficult to convince any business that customer and supplier are not important concepts in their own right. For example, it is important for businesses to agree on the definition of ‘customer’; one bank I worked for included people who might become customers, even though we hadn’t contacted them yet. The bank had no commercial arrangement or transactions with these people, but they wanted to manage their data with the ‘customer management’ processes. You can argue whether or not this is a good approach, but that was their business model.

    • imm January 24, 2011 9:38 am #

      Hi George

      Your example proves my point. The bank you talk about wanted to know about Third Parties with whom they had not yet done business. Because they had not yet done business they had no commercial transactions, therefore such a Third Party can be neither a Customer nor a Supplier. So what are they? Prospects, I would suggest.

      But! And this is the essential “But”! The information about the Third Party remains the same. Their name, address, age, weight, height, sons, daughters, wife, dog and anything else you want to know is all the same, whether the relationship that the enterprise has with them is Prospect, Customer or Supplier.

      This is the greatest clue to the flawed approach of having Customer, Supplier or Prospect as a Master Data Entity.

      And, yes, I would argue that the bank’s approach was severely flawed.

      Thanks for the comment, George.

      John

      John

  5. Peter Perera December 7, 2010 8:13 am #

    Hi John,

    Stumbled upon this article. Glad you bring this topic up. Your party model under Generic Data Structures looks a lot like Oracle TCA (Trading Community Architecture). Though they don’t have the name usage part, I think. The Commercial transaction equates to their “Account”.

    The other point I’d make – one that I have been highlighting for some time – is that the customer, er party, may actually be a collection of parties. You cannot exclude relationships among parties as a party itself. Customer, supplier, party, whatever, are singular and plural words akin to “fish” or “chicken”. Sometimes these party collections have a name and address “usage”. Increasingly they also have a transaction. You need to express the relationships among the parties that constituent the “group party”.

    Increasingly important in representing trading communities and social networks where the network of the individual persons and/or organizations is a party itself. Oracle TCA has a “group” as a third party type and “model” relationships among the parties.

    Peter Perera

    • John Owens December 7, 2010 9:01 am #

      Hi Peter

      Thank you for your feedback.

      You are quite right. ‘Party’ may well have be comprised of other ‘Parties’ and, if these relationships are of significance to the enterprise, that structure must be included in the Logical Data Model.

      This relationship might be a simple recursive relationship to Party itself or a many-to-many, resolved with an intersection entity, to show the nature of the Parties relationship(s) and when they began and ended.

      These structures are important and should be modelled. But more important is to first move data modellers and Data Quality practitioners away from modelling “Customer” and “Supplier” as master data entities.

      Regards
      John

  6. Vitaliy September 20, 2010 5:29 pm #

    I must say it is not really new – SAP has been using a term “Business Partner” in its CRM data model for a while, where BP is everything – Customer, Prospect, Supplier, Employee – and can be Organization or Individual.

    • John Owens September 20, 2010 6:22 pm #

      Hi Vitaliy

      You are quite right, this is nothing new. Some enterprises have been doing it for years. Sadly, however, some have never come to this realisation.

      Some enterprises, applications and ERPs who think they have implemented the proper generic structures fall into a more subtle trap, yet still serious, trap of having an entity called “Business Partner” linked to one called “Business Partner Type”, with allowable values of “Customer”, “Supplier”, etc.

      This is a type of backdoor “hard coding” and totally misses the point that these relationships are, and most be, totally derivable from the type of transactions performed with each external entity or third party.

      Regards
      John

  7. AB September 15, 2010 3:26 am #

    It’s amazing to see how many people are still using “Customer” as a data entity.

    I’m happy to report that in a recent project we used a model like the one you describe to define a datamart bringing together information about suppliers, customers, partners, sponsors, etc., into a single view. In this particular project, customers are also in most cases sponsors and suppliers, which further highlights the fact that “customer” is not a type of entity, but rather one of many relationships a corporation or individual can establish with another party.

    • John Owens September 15, 2010 11:17 am #

      Thanks for the feedback, Adriana. Good to hear about your enlightened project.

      Regards
      John

Leave a Reply