Search for data architecture and you will find diagrams. Layers of ingestion, storage, processing and serving. Lakes, warehouses, catalogues. They are drawn for organisations with data teams, and they are useful there. A company of a hundred people with a CRM, an accounting system, a help desk and a few other tools does not have a data team, and what it needs is not a diagram.
It needs a short list of decisions, made once for each thing the business keeps track of. Three decisions per object, for perhaps eight objects. Twenty-four answers, most of which can be settled in a morning, and which do more for the company's data than any platform.
An object is a kind of record the business cares about: customer, contract, product, employee, invoice, order, ticket, project. Each exists in at least two systems, and the trouble starts there.
Who writes it. Exactly one system may create and change each object. Others read it. This is the decision we covered in system of record versus source of truth, and it is the one most companies have at least thought about, even if they did not write it down.
What key joins it. How does a record in one system find the same record in another? This is the decision that is usually skipped, and its absence is the commonest reason a report built from two systems does not add up.
What history is kept. When the object changes, what happens to its past? Is the old value kept, with the date it applied, or overwritten? This is the decision that is almost never made, and its absence surfaces months later as "why did last year's report change?"
The first decision stops two systems fighting. The second and third make the data usable after the fight is over.
Two systems hold a customer. One calls her "Acme Ltd" and one "ACME Limited". One has her email address, the other has her accounts payable contact. A person can tell they are the same company. A report cannot.
The join key is a value that both systems carry and that never changes: an identifier created once, by the system that writes the object, and copied to every other system that refers to it. The name is a poor key, because names change and are written differently. The email is a poor key, because people leave. A tax number is a good key where it exists and is a good deal less reliable than people think when it must be entered by hand.
The practical rule is that the writing system generates an identifier and that every other system stores it in a field, with a rule that the field is never edited by hand. When a new record appears in a reading system without an identifier, it is an exception, and a person is asked to match it.
Three small things make the key work. The identifier is generated at creation, not at the first sync. It is stored in every system that holds the object, including the spreadsheets. And duplicates are merged into one surviving identifier, with the retired ones kept as aliases so old reports can still find them. We looked at the version of this for customers in customer master data.
An object changes. A customer moves, a price rises, an employee changes role, a contract is renewed. The question is what the data does with the old value.
For some fields overwriting is fine: a corrected typo does not need history. For others the past is the point. The price a customer paid last year should still be last year's price. The team an employee belonged to when a deal closed determines whose number it was. The terms on a contract that has been renegotiated are needed to understand an old invoice.
The rule is a short list, per object, of fields whose history is kept, with the date from which each value applied. It can be as simple as a second table of changes, with the field, the old value, the new value and the date. It does not need a warehouse. It needs someone to decide that these six fields matter and to make the system record their changes.
Without it, a report for last quarter run today gives a different answer than it gave in July, because customers, prices and owners have been overwritten. People stop trusting the reports, which is the real cost.
Take the contract. Writer: the CRM, because the account manager creates it and sets its dates. Key: a contract number generated by the CRM at creation, copied into accounting and the help desk, never typed by hand. History: the term, the renewal date, the price and the service level are kept with the date each value applied; everything else is overwritten.
Write that on one line and four questions go away. Which system do I trust for the renewal date? How does the help desk find the right contract for a ticket? What did the customer pay last year? Why does the finance report for March say something different now? The rest of the objects follow the same shape, and the line is short enough for a new hire to read in a minute.
Make a table with the objects down the side and the three decisions across. Eight rows, three columns. Take it to the people who use the systems and fill in the cells, in order: writer first, then the key, then the history.
You will find three things. Several objects have no clear writer, which is the first list of decisions. Almost every object has no join key beyond a name and an email, which is the second. And nobody has decided which fields keep history, which is the third. Each is a short conversation, and each resolves into a rule written in the table.
The table is the architecture. It is one page. It fits on a wall.
At some point a company may need layers, a warehouse and a catalogue. The decisions above are what they will have to be made anyway, and the diagram will be easier to draw with them. A company that builds the warehouse first, without the decisions, builds a place to put records whose keys do not join and whose past was overwritten. It is more expensive and it fails in the same way.
An agent working across systems depends on the same three things. It needs to know where to write, how to find the same record elsewhere and what the past looked like. A company with the table can give an agent clear rules. A company without it gives the agent a mess and hopes the model works out the rest, which is how agents come to merge two customers that were different.
We run the three-decision workshop for companies of 50 to 500 people, produce the one-page table and then enforce it through the integrations and the identifiers. Discovery is no-risk: we fill in the table for your first five objects and show you which cells are empty, and you pay only if you go ahead. The build carries a guaranteed estimate, so if we estimate low, we absorb the difference.
Data architecture at this size is not a picture. It is a table that says who writes, what joins and what is remembered.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
