Software You Buy Is Someone Else's Opinion About How Your Business Should Run

The model is the software: why the enterprise should start from a computable model of the business, and let software conform to the company.

November 3, 2026
Industrial press with gears and cubes
For fifty years, enterprise computing has been application-first, with ERP at the center. But ERP wasn't enough, so companies bought additional systems: PLM, CRM, WMS, planning, procurement, analytics, etc. Each application solved its local problem while creating its own partial version of reality. So, companies built integrations, data warehouses, and BI to bring them together, and, of course, end users created spreadsheets because BI can't give them the answer they need today.

An application is at its best on the day it goes live. From then on, the business changes while the software does not, and the gap, “operating drift”, grows more each day. A supplier changes a price, demand shifts, or a constraint appears, and one system knows while another doesn't. The more software a company buys, the wider the “drift” gap gets (what everyone thinks is happening vs what is actually happening). They figure it out two weeks after month close, but by then there's nothing to do about it. Businesses operate continuously, but what everyone knows about what is happening is reconciled periodically.

Now AI threatens to industrialize the problem. Code is becoming almost free, every vendor is embedding agents, and every department can generate its own workflows. More software on an application-first architecture creates more versions to reconcile.

The problem is that enterprise software has always forced a business to conform to the boundaries of its applications.

The alternative is an entirely new approach. Imagine starting from how the business actually operates and then creating software around that structure. A computable model at the core of every business that describes all of a company's financial and operational activities: its resources, commitments, activities, and constraints; what drives what among them; and how they connect to revenue, cost, margin, and cash. It's completely backward from how software has been developed for the past 50 years.

A computable economic model allows software to conform to the boundaries of the business.

That model is continuously “closed” (always reconciled) but it is never “complete” (describing every business possibility). Closed means the numbers add up. Predicted results vs actual results teach or correct the model. Unknown does not become zero, an estimate does not quietly become an observation, and missing information does not become truth because AI can generate a plausible answer. The model reconciles what it claims to know and identifies what it does not.

Then applications make it more complete. Applications become the business's sensors and actuators. Their purpose is to add to understanding, not just automate a business process.

The computable model knows the company's current state, its constraints, and the economic consequences of available actions. People decide where they want to go; the model can calculate the paths available and generate the software needed to execute one. What happens flows back into the same model. Expectation becomes execution. Execution becomes actual. The difference becomes learning. The old software industry encoded workflows. This architecture can compile them from the state and intent of the business.

A computable model of your business is at its worst on day one. It gets better every day it operates. When it finds an economically important gap, it generates the smallest application needed to close it, and every workflow makes the same model more complete instead of creating another truth. Cheap code, which accelerates drift in the old architecture, accelerates completeness in this one.

This solves a really important problem: most of the decisions that determine a company's economics happen before finance can see their consequences. A price is quoted. Inventory is committed. Capacity is allocated. A supplier is chosen. By the time those choices arrive in the P&L, much of their economics is irreversible. Application-first software records the trail. A computable operating model can calculate the consequence while choices still exist.

For fifty years, enterprise computing began with applications that forced the company to reconstruct itself from what those applications recorded.

We reverse that.

Build a continuously closed, computable model of the company first. Let its use make the model more complete and the underlying data better. Generate applications as the business needs them. Let every action return evidence to the same model.

The company no longer has to conform to its software. The software can conform to the company.

That is not an evolution of enterprise software.

It is a different computing architecture for the enterprise.

‍

The model is the software.

Read More

October 31, 2026

Economies of Small

The Future Belongs to Those Who Connect

October 31, 2026

The End of the Legacy Supply Chain

How CreateOne Builds the Dynamic Value Chain Networks for Fashion

OFFICE

Pier 59, Chelsea Piers, New York, NY 10011

CONTACT

hello@resonance.nyc

Resonance