Avoid business terms in your physical datamodel

Why is it a bad idea to go directly from business terms to data entities in our IT-systems?

First of all, you make your model extremely dependent upon your existing application, making transformations much harder.

If you need integrations to other applications, or external parties, then you have a problem as their terms differ.

Business terms lack normalization, which result in inconsistency in the stored data.

Input and output in processes are often described as information entities. Not the actual tables in your IT-system.

Finally, the business people will have a hard time to learn how things are implemented in the applications.

This is why you need a conceptual layer, where you have information objects or information entities supporting the business, without relying on the implementation in IT or as manual tasks.

Lets start with a basic example.

A company have suppliers and customers. The old way is to treat them as separate entities. What if the same organization is both supplier and customer?

Another classic example is when you have organizations as customers, but end customers are individuals and you need to manage them.

Five different businesses terms, that could be described as party with one ore more party role.

An information object realizes one or more business terms. A term belongs to business capability, so you can link sn information object indirectly to a capability.

The special case where we have the same business term, but different meanings like an account is something we need to manage.

For the sales organization it's a customer account and for the accounting department it is a financial account. This is when we have to introduce specialisation into our information model, e.g. customer account or a financial account.

The information objects / information entities is also where we start to talk about data quality. A topic for next article.