4. The Peace of Mind That Used to Be Bought

Whoever bought software took home two things and paid for only one. They paid for the features. The other came included and nobody wrote it into the budget: peace of mind.

What was that peace of mind made of?

Of two certainties. Many others used the same thing, and it worked for them: in my judgment, an ERP that runs in thousands of companies has been through thousands of accounting closes, and a serious error has fewer places to hide, although the history of software has its famous counterexamples. And someone answered: if the system miscalculated a tax, there was a vendor with a contract, with a name and with something to lose.

That peace of mind belongs to what is bought: to the service that is rented and the package that is licensed. Custom development almost never had it, because a single company uses it and a team that usually leaves answers for it. Whoever comes from there loses little by moving to a system of their own. What they discover is that the question below, who vouches for it, never had an answer.

What question arrives when you build?

Let us imagine the board of a company that decides to build its system instead of buying it. The IT department gets to work, the agents start operating, and one day someone at the table asks what they never asked of the platform they used to buy: are they doing it right? Are the numbers this system produces correct?

The same question appears at other scales. The members of a family whose wealth is managed by a third party may doubt, with reason, whether what they see in the report is true or has been manipulated. The client of an accountant who keeps their books with a system the accountant built asks the same thing. And the regulator, which receives a company’s reports, has no reason to believe that the system that produced them does what it says.

Behind the question there are concrete risks. Of any construction: reaching a dead end, running late and spending more than planned, delivering something of lower quality than expected. Of agents in particular: that one makes a mistake in something that touches money or the customer, that it acts without clear authority or without leaving a trace, and that its performance degrades without anyone noticing.

Isn’t building well enough?

It is not enough, because the question is not about the quality of the work. It is about who vouches for it.

An audited process is one observed by someone with no relation to whoever executes it. From that definition follows a consequence: an organization can build its system as well as it likes and still cannot be the one that guarantees to its customers, its shareholders and the regulator that what is recorded is true.

This has to be separated from something else that is also needed. An organization that builds needs technical judgment: a chief technology officer, an expert partner or a trusted vendor who makes sure that what is done is done well. That judgment can be hired or developed in-house, and it ensures the quality of the construction. The guarantee that what is recorded is true comes from somewhere else.

Which piece is that?

The conversation with my friend led me to a provisional name. I suggested he look at it as a black box: you put things in, you take reports out, and its value lies in the fact that what comes out is not what someone recorded as they pleased, but something an auditable process guarantees. He corrected me: nobody wants a black box. What is needed is something anyone can open and verify.

I later called it a truth base, by kinship with the database, but the word “base” suggested a shelf. I ended up at the name I use in the rest of the book, built on a term that systems architects already use. A system of record keeps the official version of a piece of data. What is needed is one step more: a system of truth.