Generic "Customer"

Almost every session I'm in, explaining the power of Fact Modeling, there are questions on how to deal with different departments having an entity called "Customer" while they all mean something else, or use a different identification for it. This little article will show a possible verbalization for this issue.

Suppose we have four different departments, and they all have their own siloed application.

1. Helpdesk has a ticketing system where people have an account. The helpdesk considers them to be customers.
2. The sales department has bought an off-the-shelve CRM system which identifiers online customers by their email address.
3. The website handles orders and they've developed numbers to migrate an old system into it, and identify customers by an artificial number.
4. The financial department has a portal in which payments are handled and uses a fourth and different alphanumerical key to identify customers.

It goes without saying that these keys are crucial for all four departments. However in integrating them, the reporting department wants to unify the data and keys to be able to perform audits over all systems.

This requires the various systems to integrate. The issue at hand is that every department calls their contacts "customer" while they obviously contain different identifications. Fact Oriented Modeling finds this to be of no problem. Below you'll find simple fact statements qualified by the various departments:

Customer Ticket
"Customer HD1234 entered ticket 20190299."
Customer Contact Moment
"Customer This email address is being protected from spambots. You need JavaScript enabled to view it. is contacted at 2019-01-01."
Customer Order
"Customer 10090 placed order 83366846."
Customer Outstanding Payment
"Customer XYZ has an outstanding payment of Eur 99,00."

For every department (and system) we state different facts. They all involve the entity "customer", and all have a different identification for it. However by simply stating facts, and qualifying these facts, we slowly build a generalized entity called "Customer" which may have one of many identifications, and still have a single name within the organization. The verbalizations of facts are structured differently:

Combining all these facts will generate the following diagram which demonstrates how various customers fold into one object type:

Various identifications for a concept may sometimes get confusing in regular data models. Fact oriented modeling allows for this without problem.