Most architectural conversations start with the platform. Which CRM, which CMS, which ERP. The data model emerges from whichever platform was selected — shaped by its assumptions, its category structures, its custom field conventions.
This is backwards.
The data is the durable asset. The platforms are replaceable. An organisation that lets the platform choose its data model has handed an external vendor authority over how the business thinks about itself.
Free · 4 minutes
When two of your systems disagree, do you know which one to believe?
Fourteen questions on ownership, lineage, and quality — the difference between a number on a dashboard and a number you could defend. Banded finding on screen, full sheet by email.
What platform-first looks like
The pattern is consistent across CRM, CMS, ERP, and the enterprise platforms that sit alongside them.
A platform is selected. Implementation begins. The platform expects certain entities — accounts, contacts, opportunities, pages, products — defined in certain ways, related through certain mechanisms. The business adapts its model to fit. Custom fields are added to extend the platform’s standard schema. Relationships that the business actually has are encoded through whatever the platform supports. Taxonomy that does not quite match the business’s mental model is accepted because the platform’s structure is what the team has to work with.
A year passes. Two years. Five.
The platform now contains everything the business knows about its customers, its products, its content, its operations. It is also full of platform-specific compromises. The custom fields express relationships the platform did not anticipate. The category structure reflects the platform’s hierarchy, not the business’s actual segmentation. The integrations are built around the platform’s API, which exposes some entities cleanly and others not at all.
The business has not made a data model. The platform has made one on its behalf.
What it costs
The cost is not migration. Migration is the visible expense. The structural cost is manoeuvrability.
A business that has woven its data model into a platform has, by that act, restricted its ability to change. New initiatives that require a different data shape encounter resistance — not because the people are resistant, but because the underlying platform was not designed for that shape. New integrations have to negotiate with the platform’s API rather than the business’s actual structure. New analytical questions require workarounds because the data is held in platform-specific ways that do not align with how the business now wants to query it.
The board wants the business to grow. The platform is anchored to a version of the business that existed when the platform was selected. The data woven into the platform expresses the business as it was, not as it intends to be.
When the platform eventually has to change — and it always eventually does — the migration is not a data transfer. It is an exercise in unweaving years of platform-shaped decisions to recover the underlying meaning, then expressing that meaning in a new platform’s vocabulary. The translation is lossy. Important relationships are flattened. Implicit categorisations are lost. The new platform asks different questions. The old data answers different questions. The gap is paid for in months of work, lost fidelity, and the discovery of inconsistencies that the previous platform had been quietly hiding.
What data-first looks like
A data-first architecture inverts the relationship. The data model is defined first, in the language of the business. Entities, relationships, taxonomy, and rules are expressed independently of any platform.
The platform — CRM, CMS, ERP, or otherwise — becomes a view onto that model. It renders the data, supports operational workflows, and provides whatever user experience the business needs. But the data does not live in the platform. The data lives in the model. The platform references it.
This sounds abstract. In practice it means a structured data layer — a database, an API, a defined schema — that holds the canonical version of the organisation’s information. The website is one expression of that model. A member portal could be another. A mobile app could be another. A partner integration, a reporting dashboard, a print artefact. Each is a view of the same underlying structure.
When the platform needs to change, the data does not. The view changes. The model stays. The new platform is connected to the existing data model rather than being given authority to redefine it.
The cultural shift
Data-first is not primarily a technical architecture decision. It is a posture toward vendors.
Most organisations defer to their platforms because the platforms have arrived with confidence, opinions, and a complete set of conventions. The vendor knows how things should be structured. The organisation, often, does not. The path of least resistance is to accept the vendor’s assumptions.
A data-first organisation does the harder work of defining how it sees itself, in its own terms, before any platform is selected. This requires an internal capability — usually senior technical leadership combined with clear business ownership of the data — that the organisation either has or has to develop. It is not free. It is significantly cheaper than the alternative.
Once that capability exists, platform selection becomes a different conversation. The question is no longer “which platform can we adapt to” but “which platform can we use as a view onto the model we have.” Some platforms accommodate this well. Others do not. That assessment is the basis for selection.
A few rules
Define the data model in the language of the business. Not in the language of any platform. The model should be readable by someone who has never seen the platforms it will eventually be rendered through.
The platform is a view. The data is the asset. Every architectural decision should reinforce this hierarchy. The moment a platform starts defining entities the business did not define, the relationship has inverted.
Custom fields are a warning sign. When a platform requires extensive customisation to express the business’s actual structure, the fit is wrong — and the customisations are themselves a form of lock-in.
Migration cost is the symptom, not the disease. The deeper problem is the loss of manoeuvrability while the platform is in use. If the data model is portable, the platform becomes replaceable. If it is not, the platform owns the future.
Senior technical leadership matters here. Platform-first is the default behaviour of organisations without an architectural function. Data-first requires someone whose job it is to defend the model from the platform — and to make that defence credible to the business and to the vendors.
Richard King is CTO at Sixteen Pillars — technical leadership, architecture, and governance for organisations that need it without the overhead of a full-time hire.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.