I think you're mixing things up.
People don't need to have the same language at all.
Compression can happen by "users" at a higher level when interacting with the data model.
The data model itself does not need to encode this.
HR may want to look at employees from one view and your accountant might want to look from an entirely different one. They communicate with people in their own field using their own compression. You don't need to settle on one abstraction for everyone.
The data-model designers need to communicate with each other.. sure.. but it's their job to think in a non-compressed way about the data model.
Data model here is not necessarily what is in the DB, I think TFA is using "data model" more abstractly, is the model of the business domain that is prevalent in the organization and structures how they talk about the domain.
An interesting take. In the abstract it probably makes sense. You can't make a large org like Instagram start doing a Twitter or something like that.. Though I read the subtext to be talking about code
> By the time the architecture solidifies around these implicit choices, it’s nearly impossible to change.
> Incumbents couldn’t match this without rebuilding from scratch.
My point is that if your actual code-level datamodel is flexible then you often architecturally can pivot to a different view (the Rippling example). My guess as to why HipChat can't change to a Slack model is because they "coded it wrong". It's not somehow inherently orthogonal. The essay present the models are a fait accompli when in fact, if you step back they're for the most part just views on the same fundamental data/relationships - and if modeled correctly I don't see any reason why you wouldn't be able to change between views.
The central thesis that "Your data model is your destiny" does not have to be true
Though that said, there are some examples that probably can't pivot due to some inherent design limitation (ex: the Adobe case)
HR may want to look at employees from one view and your accountant might want to look from an entirely different one. They communicate with people in their own field using their own compression. You don't need to settle on one abstraction for everyone.
The data-model designers need to communicate with each other.. sure.. but it's their job to think in a non-compressed way about the data model.