When I examine someone else's system during an audit, the first thing I ask is a simple question: why does this order have this status? And very often nobody can answer. The status is "shipped", but there is no shipment in the system. The payment went through, but the invoice is marked as unpaid. The client is marked as "new" in the database, although he has twenty orders. The data is there, but it has no causes. The system shows effects that follow from nothing. This is the surest sign that someone forgot about cause and effect during design.
A business system is a set of reactions to events
Any accounting system, once You strip away its interface, is very simple. Something happens in the world: a client placed an order, a supplier delivered goods, an accountant posted a payment, a manager cancelled a deal. These are causes. The system reacts to them: it changes stock levels, creates documents, recalculates debts, sends notifications. These are effects. That is all. All the complexity of business logic comes down to correctly describing which event causes what, and in what order.
I like comparing this to a detective's work. A good detective does not just note that a vase in the room is broken. He reconstructs the chain: who came in, what they bumped into, why it fell. A good system must be able to do the same: for any state of the data, answer which event led to it. If it cannot, You are managing not a business but a set of random numbers.
Where causality breaks
Over the years I have compiled a list of typical modeling mistakes. They occur in projects of any size, from small shops to large accounting systems.
- Ignoring intermediate states. In the model an order is either "new" or "completed", with emptiness in between. In reality it goes through reservation, picking, awaiting payment, handover to a courier. When these states are not described, employees start encoding them with comments, row colors and verbal agreements.
- Breaking the sequence of operations. Money was debited but the goods were not reserved, because something failed between the two actions. The system was left in a state that could not have arisen from any sensible chain of events.
- Editing effects directly. Someone manually corrected the stock level without posting a receipt or a write-off. The number became "correct", but it no longer has a cause, and a month later nobody will understand where it came from.
- Mixing business logic with the interface. The rule "return goods to the warehouse when an order is cancelled" lives in a button on a screen. The order was cancelled through another screen, an integration or a mobile app, and the rule did not fire.
In a good model You cannot change an effect without creating a cause. This is not bureaucracy, it is the company's memory of what happened to it.
How to build a model in which everything can be explained
The first rule: design from events, not from screens. Before drawing forms, write down every event that happens in Your business, in the language of the business itself: "the client placed an order", "the warehouse packed the shipment", "accounting confirmed the payment". For each event, describe which data it changes. Screens will come later, as a way to trigger those events.
The second: describe every state of an object and the allowed transitions between them. From "new" You can move to "reserved" or "cancelled", but not from "shipped" back to "new". This is called a state machine, and it is one of the most useful tools in design. It immediately exposes the holes: what happens if a client cancels an order that has already been packed? What if a payment arrives after cancellation?
The third: carry out related changes as a single whole. Debiting money and reserving goods either happen together or do not happen at all. Engineers call it a transaction, everyone else calls it common sense. Half an operation is worse than no operation.
The fourth: keep a history of events. Not only the current status, but who changed it, when and why. Then the question "why does this order have this status" will always have an answer, and an audit will turn from archaeology into reading a log.
Predictability as the main quality
A correct model is predictable. Looking at an event, You know exactly what consequences it will lead to. Looking at a state, You know exactly which events led to it. It seems like a boring property, but it is exactly what allows a system to grow. Adding new features to an unpredictable system is scary, because nobody knows what else will break. In a predictable system new events are added calmly, like new moves in a game with clear rules.
In this sense I feel close to physics: the world is complex, but it obeys laws, and that is precisely why it can be studied and predicted. A business system should be a small universe with its own laws, not a collection of miracles that occasionally happen to the data.
What to do tomorrow
Take one key object of Your business, an order for example, and together with the people who work with it, draw all its states and the arrows of transitions between them on a whiteboard. Label each arrow with the event that triggers it. You will almost certainly find states that exist in real life but not in the system, and transitions that the system allows but real life does not.
At Ingello we do this on every project: at Systems this is where design begins, and in Fractal the map of screens and scenarios is described in a separate language, so chains of causes and effects are visible before the first line of code is written. A model in which every effect has a cause is not an architect's perfectionism. It is a way to make sure Your system can always explain itself.
