There are cases when you experience two different problems in some relational graph that seem to be the same problem but are not actually the same. They have the same sound, a similar definition, but the root causes and the solutions are very different. These usually manifest as conflicting definitions based on business unit perspective.

Scenario A

A company called ExampleCorp takes data from other companies and provides some kind of revolutionary data analysis to drive revenue. ExampleCorp's customers at the top level are people who pay them to analyze data. One of their customers is FoodCorp. FoodCorp has an app that people use to buy food. These are FoodCorp's customers. FoodCorp also has people who deliver food. They are also FoodCorp's conceptual customers.

When ExampleCorp signs a contract with FoodCorp, you have a lot of confusion. The exec team and sales team calls FoodCorp the customer. The app team calls FoodCorp's buyers customers. The database team calls FoodCorp's delivery people customers. This is a problem. No one knows what anyone means when someone says "customer".

Scenario B

ExampleCorp has database, finance, and legal teams. Every time they have to talk about compliance auditing, there is confusion about who is talking about what when the word transaction is used.

Database team thinks transaction means something specific about an interaction with a database engine inside the construct of a session, with certain guarantees about outcomes, failure modes, and data persistence.

Finance team thinks transaction is an event that has monetary impact on the company's financial position and is recorded in a ledger. (There's probably more to it than that. I don't know.)

The legal team thinks a transaction is an event involving two or more parties that involve the formation and performance of an obligation or contract. And contract all by itself has its own specificities around offer, consideration, acceptance, capacity, legality, and a bunch of other stuff I don't know because I'm not an attorney.

This is a problem because no one knows what anyone means when someone says "transaction".

Analysis

At first blush, we appear to have two problems that are equally well-described by the same diagnosis: we have different teams using the same words to mean different things. This causes confusion and inefficiency.

These are not actually the same problem, and the solutions are not the same.

Scenario A is a mismatch between words and meanings that stems from a lack of business context. If everyone involved in the different teams got into the same room at the same time and realized the hierarchical structure of the business model, it would be immediately obvious that we need terms like client, buyer, deliverer. It might take some executive pressure to force this meeting of minds to happen, and people might have different reasons for rejecting these specific terms, but everyone would eventually agree that there needs to be an unambiguous way to differentiate these different groups of people.

Compromise is possible, and things can move forward.  In Scenario B, the name confusion has nothing to do with a lack of business context.

These are terms of art that are required to function in the individual domains. There is no compromise available. The data engineer can't say, "Well, I'll give up strong consistency if Finance team gives up ledger, and legal gives up obligation." It doesn't even make any sense to write what I just wrote.

No amount of executive pressure can alter this situation. The solution is local. The solution is an agreement to make it clear when we are talking about which term of art.

The solution is a collaboration between teams that share specific words with different technical definitions to reach out to the other teams and share their technical definitions, educate each other, learn from each other, and decide on a communication strategy to differentiate between them.

For example, finance team will use financial transaction instead of just transaction. DB team will use database transaction instead of transaction, etc.