Firmitas, utilitas, venustas

The architectural terms firmitas, utilitas, venustas offer a useful way to think about enterprise software: durability, usefulness, and beauty. For a system used to run a business, we interpret that last quality as clarity. Can the person relying on it understand what it is telling them?

These qualities are connected. A useful application can become difficult to maintain. A well-maintained application can go unused. A system that gives an answer without enough context can leave users checking it in a spreadsheet.

Does it do the job?

A forecast can run successfully and still be unusable for planning. Test whether the output helps the intended user complete the task.

For a planner, that might mean making a schedule that accounts for materials and changeovers. For an accounts payable team, it means identifying which invoices can proceed and which need investigation.

Define those tasks before testing. Include the incomplete records and exceptions the system will encounter after launch.

Will it survive ordinary changes?

Consider three events: the engineer who built the system leaves, the business unit is reorganized, and the ERP is upgraded. What would the next person need to keep it working?

Code and support instructions matter. So do the agreements behind the code: what counts as a customer, how margin is calculated, which source takes precedence when systems disagree, and who can change those definitions.

Write those decisions down and assign responsibility for maintaining them. Otherwise, an ordinary upgrade can turn into an investigation of rules nobody remembers choosing.

Durability also requires access. The team taking over needs the permissions, tools, and training to make a change without relying on the original developer.

Can people tell when it is wrong?

A planner needs to see enough of the reasoning behind a proposed quantity to judge it. Which demand estimate was used? What stock was available? Did the calculation include an order that has since been canceled?

Showing that context helps the user investigate an unexpected result. It also gives them a way to report a specific problem to the support team.

When that context is missing, people may build their own checks beside the application. Those checks deserve attention. They can reveal information the design omitted or a level of trust the system has not yet earned.

Check all three before handover

Before calling the work complete, ask whether users can do the intended job, whether the receiving team can maintain the system, and whether people can investigate a questionable answer.

Test these with the people who will use and support it. A demonstration by the team that built it cannot answer every question about life after handover.