If business rules stay with people, software only stores records

An operation is thought to have ‘moved to software’. Records sit there, lists open, export works. The work still advances in a chat, a spreadsheet, or one person’s memory. There is software. There is no rule.

That break sits in the business rules diagnosis. For as long as the rule stays outside the system, the software is an archive.

Where a rule can live

A business rule can live in three places. In the screen: a button is hidden, but the API still accepts the same action. With a person: ‘Ayşe approves this’, and the work stops when Ayşe is away. In the system: state transition, permission, and exception are enforced in the service layer and written to the record.

• Who may move this record into which state?
• Which fields lock in which state?
• Who may open an exception, and with what reason?

Spreadsheets and shared inboxes

When a table is used to carry rules, two things happen. Validation becomes optional. History disappears: the trace of who changed what, and why, dissolves into the last version of the file. Custom software exists to hold that trace and those transitions inside the system.

A web interface is not a solution on its own. A web-based system becomes the working surface of the operation only when the rule lives in the service. Otherwise it is a spreadsheet opened in a browser.

Why automation should wait

Automation built while the rule still lives with a person imitates that person’s behaviour. When the person changes, the flow breaks. Why process automation breaks is a separate note; the root cause is often an undefined rule.

Storing a record and running the work are not the same thing. The second requires the rule to be enforced in the system.

Once it is clear which approvals, exceptions, and permissions must live in the system, the scope can be discussed. Write to us.