A shared data model needs agreed meaning

A shared data model provides a useful basis for an integration when the participating teams understand its data in the same way. The decision therefore starts with meaning. A shared field name alone does not resolve a business contradiction.

One field, two different meanings

In a fictional company, both the CRM and the ERP have an active field. In the CRM, it means that the sales team currently manages the contact. In the ERP, it means that the customer may place orders. Both systems can maintain their values correctly and still produce different results.

If the project squeezed both statements into one shared active field, a sales change could unintentionally affect ordering permission. The example therefore transfers two separate statements. Which system may change each one is decided separately.

A schema implements the agreed meaning

JSON Schema describes the structure and constraints of JSON data. A validator can check whether a message conforms to the agreed schema. The people responsible must decide whether contact management and ordering permission should mean the same thing. Technical validation can represent the rules subsequently agreed.

The exchange also needs rules for missing values and conflicting changes. Without that agreement, the same empty value could cause “unknown”, “delete” or “no change”, depending on the recipient. These possibilities need to be selected deliberately.

Use shared definitions where they help

For two stable connections, a clear field description may suffice. An enterprise-wide model is worth adding as a structure when several participants actually need the same meaning. Different local terms can remain, provided their translation is unambiguous.

We recommend checking a model against conflicting sample data from the participating systems. If the teams can determine the same target meaning for a concrete record, that decision can usefully be expressed in a technical schema.

Sources

• JSON Schema: What is JSON Schema?