The Company Is a Flowchart

Utsav Mathur

Essay2026 · 088 min read

• enterprise-software
• architecture
• open-source
• process-mining

I. The problem nobody puts on a slide#

Every system that lets its users change its own structure eventually dies of the same thing. Not scale. Not performance. Version drift.

The mechanism is dull and inevitable. Configuration evolves. Data written under configuration v14 must remain interpretable under v27. So you write a migration. Then another. Then you write migrations for the migrations, because someone needs to restate FY24 under the FY26 chart of accounts, and the transformation is no longer invertible. By month eighteen the migration surface is larger than the product surface, and the honest engineering answer to any new requirement becomes "we can't, not safely."

This is why SAP implementations freeze. Not because SAP cannot express the change, but because the cost of propagating it through a decade of accumulated data has become larger than the benefit. The system stops being configurable and becomes archaeology. Every ERP built in the last forty years, proprietary or open, arrives at this wall.

The standard response is better migration tooling. Typed migrations, reversible migrations, shadow execution, migration test suites. All of it helps. None of it changes the shape of the problem, because the problem is not that migrations are hard to write. It is that they exist at all.

They exist because of one assumption, so foundational it is rarely visible: that a company's configuration is a single global artifact with a version number.

Drop that assumption and the problem does not get easier. It disappears.

II. The reframe#

A company is a flowchart.

Not metaphorically. Structurally. A till closing is a flowchart. A goods-receipt is a flowchart. Replenishment for one SKU at one store is a flowchart. Purchase-to-pay across a chain is a flowchart whose nodes are those smaller flowcharts. Quarter-end close is a flowchart of flowcharts of flowcharts. The company itself, viewed from far enough away, is one process with inputs, outputs, and a set of invariants it must not violate.

The important property is that these are all the same kind of object. A process node, at any scale, has:

• a typed input contract
• a typed output contract
• a set of invariants that must hold across it
• a body, which is either atomic or a graph of other process nodes

Micro and macro differ only in depth. There is no separate abstraction for "workflow" and "module" and "system." One recursive type, instantiated at every scale.

This sounds like a modelling nicety. It is actually the thing that dissolves migration, and the reason is worth being precise about.

III. Why this makes migration disappear#

Under the conventional model, configuration is global. Schema v14 becomes schema v27, and every stored fact must be dragged across the gap. The cost is (all data × all version transitions), and it compounds forever.

Under the process-graph model, nothing global has a version. Each node is small, immutable, and content-addressed - identified by the hash of its own definition rather than by a name and a release number. Every event recorded carries the hash of the node that produced it.

Four consequences follow, and they are the whole argument.

Change is local by construction. You do not upgrade the system. You replace one node. The only compatibility question is at that node's interface. If the new definition satisfies the same input and output contract, there is nothing to migrate at all - not because the migration was cheap, but because there was never a global version for it to be relative to.

Old definitions never die, so history stays readable. The v14 node is not deleted when v27 replaces it. It remains in the store as the reader for the events it produced. Interpreting a two-year-old transaction means resolving its hash and running the definition that actually created it. Historical data is not migrated forward. It is read through the lens that wrote it. Restatement becomes an explicit, deliberate act - re-folding an old event set through a new definition - rather than a thing that happens implicitly and destructively during an upgrade.

Versioning is compositional. A change to a leaf does not bump the root. It propagates upward exactly as far as contracts change and no further. Most changes touch one node and stop. This is the difference between a monolith and a graph, and it is why the blast radius of a change becomes something you can compute rather than something you discover in production.

In-flight work is unambiguous. A process instance pins to the definition it started under and completes under it. A purchase order opened in March closes under March's rules even if the policy changed in April. This is not a workaround. It is the correct semantics, and it is what auditors have always wanted and never been able to get.

If this feels familiar, it should. It is the same insight that content-addressed code applies to software dependency hell: the pain comes from names and global versions, not from the code itself. Remove the global version and the class of problem goes with it. Enterprise migration hell is dependency hell wearing a suit.

IV. Where it does not work, stated honestly#

Any architecture that claims to dissolve a forty-year problem should be examined for the places it does not.

Cross-cutting change defeats locality. A GST rate revision touches every node that computes tax. Graph locality buys nothing. The only defence is discipline: tax, currency, approval thresholds and similar concerns must be injected capabilities that nodes call, never logic that nodes contain. Get this factoring wrong once and you have re-created the monolith inside the graph. This is a design tax paid continuously, not a property you get for free.

Topology change is harder than node change. Replacing a node is clean. Inserting a new node into the middle of a chain is not, because events recorded before it existed have no values for its outputs. You need explicit backfill or default semantics, declared as part of the change. This is real migration work. It is just rarer, and scoped to one edge of one graph rather than to the whole system.

Some domains are not flowcharts. Revenue recognition, cost allocation, and consolidation are constraint systems, not sequences. They are better expressed as declarative rules over an event set than as process graphs, and forcing them into boxes-and-arrows is a category error that produces unreadable diagrams and wrong numbers. The architecture needs both forms, with a clean seam between them.

Concurrent versions have a running cost. Pinning instances to their originating definitions means operating many versions simultaneously and indefinitely. That is a storage and reasoning burden. It is smaller than the migration burden it replaces, but it is not zero, and it is a cost that grows with age rather than with scale.

V. Why this failed in 2005 and might not now#

Modelling the enterprise as executable process graphs is not a new idea. It was an entire industry. BPEL, BPMN, the workflow engines, the process suites.¹ Consultancies sold it as the end of custom development. It failed comprehensively, and any argument for reviving it has to explain what changed.

Two things failed. The first was authoring cost. Someone had to sit with the business and draw the flowcharts, and the drawing took longer than the process took to change. The models were obsolete before deployment. The second was the fiction of top-down truth. Companies do not run on their documented processes. They run on exceptions, workarounds, tacit judgment, and the WhatsApp group where reordering actually happens. The drawn flowchart described an idealised company that did not exist, so the executable version could not survive contact with the real one.

Both failures were failures of acquisition, not of the model. And both are now attackable.

You no longer draw the graph. You mine it. If every business fact is an immutable event with an actor, a timestamp and a resource, the actual process structure is latent in the log and can be recovered from it. Process mining proved this commercially over the last decade: the discovered graph is not the documented graph, and the discovered one is correct. The workarounds show up. The exception paths show up with their real frequencies. The company describes itself.

Then the second collapse. Turning a mined graph into an executable definition, in the terms of a specific trade, with the right invariants attached, was expert work priced at consultant rates. That is now a generation problem against a constrained target language, verifiable mechanically because the target is declarative and total. The consultant was never selling code. They were selling the translation from how a business actually works into how a system can express it. That translation is what got cheap.

So the honest form of the claim is narrow: the process-graph model was always right and always unaffordable. What changed is not the architecture. It is the cost of populating it.

VI. The turn#

Follow this through and something uncomfortable falls out.

If the graph is mined rather than authored, and the definitions are generated rather than written, and the generated output is verified mechanically rather than reviewed by hand, then the application layer of enterprise software has no defensible cost. Not low cost. No cost. The thing customers have been paying for since 1972 is the labour of translation, and the labour is gone.

Which means the only sane strategy is to give it away, and the interesting question is not whether but which layers.

VII. The case for free#

Trust requires readability. A business is being asked to put its ledger, its tax position and its statutory filings inside a box. If the kernel is closed, the correct response is refusal. Auditors, banks and tax authorities have to be able to read the rules that produced a number. Open source is not a marketing posture here. It is the only structure under which the product is acceptable.

Code is not the moat and everyone knows it. If authoring is free for you it is free for your competitors. Whatever advantage exists has moved entirely to distribution, accumulated deployment corpus, hardware, and the trust to be believed. Giving away the layer that is not defensible in order to reach the layers that are is not generosity. It is the only correct trade.

Compliance surveillance cannot be staffed. A jurisdiction pack - GST with e-invoicing and e-way bills, TDS schedules, state establishment rules, sectoral licensing - needs continuous human attention, roughly two to four people per jurisdiction, permanently. No company staffs that for a hundred countries. A distributed contributor base does, and it is the only mechanism that ever has.

And this time contributions can be accepted safely. This is the point that distinguishes the argument from every previous open-source ERP. Community contribution normally trades quality for volume, which is precisely why enterprises will not run community modules. But if contributions are constrained declarative definitions rather than arbitrary code, they can be statically checked for type soundness, conservation of value, and termination, then property-tested and shadow-executed against real event streams before anything is accepted. The verification harness removes the trade. You can take contributions at a rate no proprietary vendor can match without the quality collapse that has always been the price.

Standards accrue to their authors. If the intermediate representation for business process becomes the common substrate, authorship of it is worth more than a licence stream on any single implementation. This is the Kubernetes trade, the LLVM trade, the Linux trade.

And the incumbents cannot follow. SAP and Oracle defend tens of billions in licence and maintenance revenue.² Matching a free kernel means destroying it. The asymmetry is structural, not tactical, and it is the most reliable advantage available.

VIII. The case against, taken seriously#

Open source ERP already exists and has not won. ERPNext, Odoo, Tryton, Dolibarr - all real, all mature, all a rounding error against SAP.³ This is the strongest objection and it must be answered directly rather than waved at. They have not won because the licence was never the barrier. Implementation was. A free ERP that still costs eight months and a consultancy to configure is not meaningfully cheaper than a paid one. Which means open source, on its own, attacks the wrong cost entirely, and any argument that leads with "it's free" has already lost. The claim only holds if the specialization loop genuinely collapses implementation time from quarters to days. Open source is a consequence of that collapse, not a substitute for it. If the loop does not work, none of this is interesting.

Free is not cheap to build. A kernel ontology, a constrained IR, a verification harness and a migration model are three to five years of compiler-grade engineering by people who are hard to hire and impossible to hire in volume. Somebody funds that. The only coherent funders are those with a downstream interest: silicon vendors who need demand, or hardware margin that makes the software a loss leader. Android is the precedent and it is an exact one.

Strip-mining risk is real. A free kernel invites a hyperscaler to host it. The defence is that the value proposition is local-first - data gravity, latency, bandwidth economics, sovereignty - and a hosted fork abandons the entire reason the thing exists. That is a decent defence. It is not an impregnable one.

Governance decides whether "open" is true. If one company controls the kernel ontology, contributors are building someone's product for free and will eventually notice. Foundation governance is the eventual answer, and moving too late is how projects lose their contributor base at exactly the moment they need it.

IX. What is actually free, and what is not#

The resolution is a layer cake with a clear line through it.

Free and open, permanently: the kernel ontology, the event log format, the intermediate representation, the deterministic execution kernel, the verification harness, the process mining and specialization tooling, and the reference jurisdiction packs. This is the substrate. Its value is in being universal, and any attempt to charge for it destroys the property that makes it worth having.

Not free: the hardware. Signed, tested, warranted jurisdiction pack updates, priced against penalty risk rather than as a software rental. The federated corpus - the accumulated structural patterns from thousands of real specializations, which cannot be forked because it accrues only to whoever has units in the field. Support, at the hour a store cannot close its till.

That is the Red Hat shape, applied to a category that has never had one. The source is free. The assurance is not. And the assurance is what a business with a statutory filing deadline is actually buying.

X.#

The migration problem was never a problem about data. It was the consequence of modelling a company as a schema when a company is a graph of processes, all the way down, each one small enough to replace without disturbing its neighbours. That model has been available since the 1980s and has been unaffordable for the whole of that time, because populating it required an expert to sit in a room and translate.

The expert is what got cheap. Everything else follows: if translation is free, the application layer is free, and if the application layer is free, the only rational move is to give it away and hold the layers that compound. The hardware. The corpus. The assurance.

The category has spent forty years selling the translation and calling it software. It was always the translation.