Data modelling before you build software

Modelling means describing the business before describing the tool. We look for the objects that matter to you. A customer, a site, a job, a sample, a contract. For each one we ask what defines it, what it contains and what it is linked to.

Then we look at the rules. Can a quote be changed once it is signed? Can a job exist without a site? Who is allowed to approve it? These questions sound simple. They are what fills the code later on, and when they are badly framed they fill it with exceptions.

Developers call the result a conceptual data model or a domain model. The name sounds daunting but the idea is not. It is a map of your business that you should be able to read and correct without being technical.

The first job is the words. Within one company the word customer does not always mean the same thing. For sales it is a person to call back. For accounts it is a company that receives invoices. For the technical team it is a site where they go to work.

If the software mixes those meanings, every team ends up working around it. So we pin down a definition for each important word and write it down. Eric Evans calls this a ubiquitous language in his book Domain-Driven Design. The same words are then used in meetings, in the specification, on screen and in the code.

When two meanings cannot be reconciled we do not force them together. We split them. A sales contact and a customer account become two separate objects linked to each other. Martin Fowler describes this kind of split as a bounded context. The software gets clearer and each team recognises its own work in it.

These examples come up on a lot of projects. They show how a request for a new screen often hides a question about the model.

Without a model you start from the screens. You draw a form, then a table, then another form. Each screen creates its own data. A few months later the same piece of information lives in three places and nobody knows which one is right.

The rules hide in the code. One condition added for a special case, then a second, then a dozen. The software still works but every change becomes risky because nobody has the full picture any more.

Then one day the structure has to change. Two ideas that were merged need splitting, a level needs adding to a hierarchy, years of history need reworking. That is a data migration. On live software with real data it is often the most expensive part of a project. It is also what makes some code takeovers so delicate.

For us modelling is not a separate phase. It happens during scoping, which is free. The whole process is set out in our 3-meeting method.

At the first meeting, about an hour long, we listen. You tell us about your business in your own words. We note the objects that keep coming up, the steps, the exceptions and the words that have more than one meaning. You have nothing to prepare.

Between meetings we break your idea down into a table of features. Each line rests on the model. Create a job, schedule it, close it, invoice it. We can see straight away if an object is missing or a rule is unclear.

At the second meeting, about two hours long, we present the specification. We go through it line by line with you. This is where you correct the model, often without noticing. You tell us it doesn't work like that in your company, that another case happens too or that a word means something else. Each remark changes a line in the table and sometimes an object in the model.

We then take half a day to estimate and plan. At the third meeting, around thirty minutes, we present the fixed price, the schedule and the milestones.

Nobody can commit to a fixed price for software they do not understand. The model is what lets us do it. Once every object, every state and every rule is written down, we know what has to be built and we can estimate it properly.

It also protects the project while it is being built. If your needs change, we look at what the change does to the model. A new field on an existing object stays simple. A new object linked to several others takes more work. We price the change before starting it and you decide with all the facts in hand.

The schedule becomes easier to read as well. For custom software we generally allow 2 to 3 months for a first version and 4 to 8 months for a full project. A model set out at the start helps the project stay within those ranges.

Modelling does not mean freezing everything. A good model separates what is stable from what changes often. The main business objects move very little. Rules, statuses and permissions change much faster. We organise them so they can change without breaking the rest.

That is what guided us on Diaglibs, sampling software for the building trade. Missions, sampling campaigns, samples and measurement traceability are separate objects linked together. The software keeps evolving with feedback from the field.

On FUUZ, the training platform we built for Mosh, everything is structured around organisations, teams, roles and learning paths. The same model serves several organisations, each with its own space.

Some businesses are mostly made of links. Permissions that pass through several levels, equipment that depends on other equipment, processes that contain sub-processes. In those cases a graph database represents the model more faithfully than a set of tables.

We explain that choice and its limits in our article on Neo4j. The principle stays the same. The model comes first and the technology is there to serve it.

You have nothing to prepare for the first meeting. But if you want to start thinking about it, three questions are enough. The answers don't need to be right. They give us a starting point and we build the model with you from there.