The schema is the deliverable: model before you pick tools

The thesis fits in one sentence: the data model comes before the tool and outlives it. When an SME switches CRM, invoicing software or no-code database, a well-thought-out schema — customers, products, orders, and the relationships between them — travels with it. The reverse is false: nobody rebuilds a clean model from a confusing export.

Computing history proves it. In June 1970, E. F. Codd (IBM Research) published "A Relational Model of Data for Large Shared Data Banks": describe data by its natural structure, independently of the machine and the programs that use it. Fifty-six years later, no tool from 1970 is still in service; the relational model, however, remains the foundation of the SQL standard, whose latest edition (ISO/IEC 9075) ISO published in June 2023.

The relational model from 1970 is still readable; no software from that year survived. The long-lived asset is the structure; the tool is a consumable you eventually replace.

We call this approach structure-first: structure your data — entities, relationships, reference tables — before comparing tools. The schema is the project's first deliverable, not a by-product of configuration. This logic runs through how we build.

You don't need to be a developer to model data. Microsoft's documentation sums up normalization in ten words — "Normalization is the process of organizing data in a database" — with two goals: eliminate redundancy and make the database more flexible. William Kent had already popularized the "normal forms" back in 1983 in the Communications of the ACM, without a single line of mathematical formalism.

The first three forms are enough for an SME data model. In plain language:

The canonical example comes from that same Microsoft documentation: if a customer's address exists in the Customers table but also in Orders, Deliveries and Invoices, every copy is a divergence waiting to happen. The customer moves, and three tables out of four are now wrong.

The practical rule: a piece of information lives in exactly one place; everywhere else, you reference it. That is the core of normalization for non-developers — the rest is refinement.

The published figures are dated, but they converge — and dating them beats recycling them without a vintage. In 2020, Gartner research put the average cost of poor data quality at 12.9 million USD per year per organization. In 2017, a study published in Harvard Business Review (Nagle, Redman, Sammon; 75 executives each auditing 100 recent records from their own organization) found that 47% of newly created records contained at least one critical error; only 3% of the batches met an acceptable bar.

Its protocol, the "Friday Afternoon Measurement", can be replayed in-house: gather the team, pull the last 100 records created (contacts, orders, tickets), highlight every visible error. Two hours are enough to get an objective read on your data — before any tool debate.

The link to the schema is direct. A free-text field where a reference list was needed, an address copied into four tables, two "customers" files kept by two departments: all errors the structure would have blocked at entry. Each department then fixes them in its own corner, unknowingly redoing the initial modeling work.

The cost of doing nothing — 12.9 million USD per year per organization (Gartner research, 2020, a dated order of magnitude); 47% of new records with at least one critical error (HBR, 2017); 60% of AI projects unsupported by AI-ready data expected to be abandoned through 2026 (Gartner). An SME doesn't operate at these magnitudes, but every duplicate is paid for in hours of reconciliation.

Application sprawl is measured every year.

The MuleSoft sample (1,050 IT leaders) covers large organizations; Okta's 101 applications describe organizations closer to SMEs. The mechanics are identical: every unmodeled application adds one more registry to deduplicate someday.

The pattern worth keeping: it is not the tool that creates the silo, it is the absence of a shared model across tools. Two applications aligned on the same schema — same entities, same identifiers — integrate well; ten applications with no common registry never truly integrate.

AI makes this urgent. Gartner predicts that "organizations will abandon 60% of AI projects unsupported by AI-ready data" through 2026; the same survey (1,203 data leaders, July 2024) shows that 63% of organizations either lack AI-ready data practices or don't know whether they have them. A clean schema is the prerequisite for the AI use cases being pitched to SMEs; it is the first workstream in our method.

Portability is not a whim; two references confirm it. First, the standard: ISO/IEC 25012 defines the data quality model and lists portability alongside accuracy, completeness and consistency. Quality data is, by normative definition, data that travels.

Then the law. EU Regulation 2023/2854 (the Data Act), applicable since September 12, 2025, regulates switching between cloud providers; its Article 29 bans switching charges between cloud services from January 12, 2027, as confirmed by the German regulator Bundesnetzagentur. Leaving a tool becomes a right.

But exporting without a schema is moving house with unlabeled boxes: the law guarantees the truck, not the plan. An export only has value if someone knows what each column means, which table references which, and which file is authoritative. That is what a structure-first approach produces: a documented model that gives exports their meaning and makes switching tools reversible in practice.

Before any tool comparison, run your model — even sketched on paper — through these eight questions. Every "no" will reproduce itself in whatever tool you pick. For help with this diagnostic, see our services.

Eight "yes" answers don't guarantee the right tool; they guarantee that whichever tool you choose inherits a sound structure — and so will the next one.

Full normalization is not always practical — the literature itself says so, from Kent (1983) to Microsoft's documentation. Three normal forms are enough for an SME; chasing the fifth is overzealous, and denormalizing is legitimate when ease of use demands it. Likewise, to test an idea on thirty rows of data, prototyping first is reasonable: models are also learned by doing. Structure-first pays off as soon as a piece of data is shared across several people, several tools or several years. Below that threshold, a disciplined spreadsheet will do — as long as you know you are taking on structural debt.