The FD Principle

There is a curious fact about finance software that most people in IT have never noticed.

Sage, Xero, QuickBooks, Business Central, Sun Accounts, Oracle Financials — deeply competitive products, fighting for the same clients, with every commercial incentive to lock customers in. And yet every one of them exports your data in a standard format. Every one of them lets you take your transactions, your chart of accounts, your audit trail, and move to a competitor.

They didn't do this out of generosity. The Finance Director demanded it. GAAP required it. The auditor needed it. The regulator expected it. The data has an external definition that no vendor controls — a transaction is a transaction, debits equal credits, the audit trail belongs to the business — and the FD knew it and insisted accordingly.

The result: finance systems have genuine portability. The buying decision maker had enough power, and enough external constraint, to force it into the product.

The managing partner of a professional services firm doesn't have an equivalent of GAAP for their firewall. There is no regulatory standard requiring the network configuration to be exportable in a human-readable format. So the vendors didn't build the export. They built the GUI. They built the proprietary format. They built the certification programme that makes the configuration legible only to people they've trained and paid.

When you want to leave, you discover that the configuration lives in a vendor-specific format that requires their tools to read, their engineers to interpret, and their blessing to migrate. The hardware is yours. The configuration — the set of decisions that determines what traffic is permitted and what is denied — belongs to the vendor's abstraction layer.

The FD had the power to demand portability. The managing partner didn't know to.

Every δivergent Byte deployment is built on the FD principle from day one.

Your network configuration is a plain text file. It reads like this:

# Block everything by default
block all

# Allow outbound web traffic
pass out on $ext_if proto tcp to port { 80, 443 }

# Allow inbound SSH from management network only
pass in on $ext_if proto tcp from $mgmt_net to port 22

That is a complete network security policy. In plain English. Under version control. Stored in your own systems. Readable by any competent engineer without vendor training, proprietary tools, or a certification programme.

Your backup configuration is documented. Your monitoring scripts are four shell scripts in plain text. Your hardware is commodity, replaceable from multiple UK suppliers within 24 hours. At deployment, you receive a break-glass credential — a YubiKey-backed key pair giving you full access to your own device, independent of any managed service relationship. It lives with your managing director, in your deed safe, or wherever your governance arrangements require.

If δivergent Byte raises prices unacceptably, you unlock your own device with your own key and continue.

If δivergent Byte ceases trading, any BSD-competent engineer can read the complete configuration documentation and resume operations without rebuilding from scratch.

If you want a second opinion on your security posture, you hand an auditor a text file. They read it. No vendor permission required.

If your insurer asks what your firewall does, you show them the ruleset. Three lines, or thirty. Readable in an afternoon.

Before your next IT procurement decision, ask the question your Finance Director asks automatically:

"If I need to leave this vendor tomorrow, what do I take with me and what do I lose?"

For your finance system, the answer is: everything. GAAP ensures it.

For your network and backup infrastructure, with δivergent Byte, the answer is the same. The configuration is yours. The hardware is yours. The break-glass key is in your deed safe. The documentation describes every decision and the reasoning behind it.

See also: The Managed Service →    We Need Extra Friday Double Maths →