3 ms·

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 i

by prmph 1y ago

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.

geokon 1y ago
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)