Architecture Files #35 · Part of Binary and Beyond. LinkedIn newsletter edition follows.
We talk about enterprise software as if the hard part is technology.
Scale. Latency. Frameworks. Cloud regions.
Those matter. They are rarely what decides whether the system works for the business that paid for it.
Enterprise software succeeds or fails in negotiation: what a word means, who has authority to change a state, and which party absorbs the cost when reality does not match the happy path. The codebase is the residue of those negotiations. When the negotiations were vague, the residue is spaghetti, pending states that live in Slack, and integrations that "work" until two departments disagree.
The status that meant three things
Picture a mid-market distributor with dealers, a warehouse, finance, and a carrier portal.
Product asked for a single order status so the customer portal could look clean. Engineering shipped status with values like confirmed, processing, shipped, and complete. The demo looked modern. Leadership liked the simplicity.
Then operations needed confirmed to mean credit checked. Sales needed confirmed to mean the dealer accepted the quote. Warehouse needed confirmed to mean stock was allocated. Finance needed complete only after invoice posting. Customer success needed shipped to mean the carrier scanned the parcel, not that a label was printed.
Each group was negotiating meaning without saying so. The field became a compromise that satisfied the demo and failed every exception path. Support invented a private glossary. Nightly jobs patched edge cases. Two systems both "owned" the truth and neither could explain a refund after partial shipment (The Myth of a Single Source of Truth, Why Every Workflow Is Really a State Machine).
The production problem was not a missing microservice.
It was an unfinished negotiation wearing a status column.
Why enterprise work is negotiation first
Consumer software often has one primary party: the user, plus a vendor that can change the rules unilaterally.
Enterprise software sits between parties that do not share incentives, clocks, or vocabulary:
- Buyers and sellers
- HQ and regions
- Ops and finance
- Your company and partners
- Regulators and product managers
- Humans and the systems that must leave an audit trail
Each party wants the software to encode their definition of done. Each wants the other party to absorb exception cost: the late change, the partial fulfilment, the disputed invoice, the customs hold, the credit limit breach.
Code cannot dissolve that conflict. Code can only record which side won, which side compromised, and which exceptions were left as manual process. That is why enterprise software often feels slow: it is carrying the weight of authority, reconciliation, and multi-party honesty (Why Enterprise Software Feels Slow (and Why That's Often Correct)).
When teams skip the negotiation and "just build," they still negotiate. They do it in production, ticket by ticket, after the contract language has already been sold.
The mental model: three negotiations that become architecture
Almost every painful enterprise design choice is one of three negotiations made concrete.
1. Negotiation of meaning. What does available, paid, approved, or shipped include and exclude? Who may change that definition? What happens when two consumers need incompatible readings of the same field? Integrations fail here first, because every integration is a distributed agreement about payload meaning, not just a wire format (Every Integration Is a Distributed System).
2. Negotiation of authority. Who may move a record from state A to state B? For which amount, region, customer class, and channel? Authority is not a role matrix decoration. It is the product deciding which human or system is allowed to create irreversible economic facts.
3. Negotiation of exception cost. When the warehouse is short, the carrier is late, the dealer cancels after allocation, or two systems disagree, who eats the work: ops queue, customer delay, write-off, automated retry, or a blocking hold? Software that "handles exceptions" is really assigning labour and risk to someone. If you do not name the someone, the system invents one: usually support, usually at 2 a.m.
Architecture is how those three negotiations are stored so they survive staff turnover. A workflow engine, a data contract, an approval matrix, a reconciliation report: those are negotiation artefacts. The framework brand is secondary.
This is a tradeoff lens, not a claim that every meeting must precede every line of code. Small products can defer negotiation. Mid-market and enterprise systems that touch money, inventory, or regulated promises cannot. The cost of vague meaning compounds across parties.
How unfinished negotiation shows up as "technical" failure
Teams report symptoms that sound like engineering:
- Status fields that allow illegal jumps
- Shared databases used as integration because nobody agreed on an interface owner
- Retries that duplicate side effects because "once" was never defined across systems
- Dashboards that disagree with finance close
- Modernisation programmes that rewrite screens but preserve ambiguous domain language
Underneath, the same gap: the business never finished saying what the words mean, who decides, and who pays when the world misbehaves.
On legacy modernisation programmes, we treat domain workshops as architecture work, not soft preamble. Extracting a service without settling meaning and authority just relocates the argument into a new repo. The residue changes folders. The negotiation debt remains.
A framework for naming the negotiation before you encode it
- Which parties touch this flow, and what does each need "done" to mean?
- Where do their definitions already conflict in today's tickets or month-end close?
- Who has authority to create, approve, reverse, or override each critical state change?
- When the exception path fires, which party absorbs cost (labour, delay, write-off, customer impact)?
- What must be reconstructable later for audit, partner dispute, or support, and in whose system of record?
- What are we deliberately leaving manual for now, with a named owner, versus pretending the software settled it?
If you cannot answer meaning, authority, and exception cost, you are not ready to "just ship the workflow." You are ready to ship an argument into production.
Implications for how you build
Write the glossary like a contract. If confirmed means three things, split the states or accept three fields with three owners. Collapsing disagreement into one badge borrows from the support queue.
Put authority next to the transition, not only in a policy PDF. A state machine that ignores who may fire a transition is a toy. Real workflows encode eligibility.
Design the exception path as a first-class product. Happy-path demos sell. Exception paths run the company. Name the queue, the SLA, and the automated holds before you celebrate green CI.
Treat partner and finance language as requirements. "We'll map it in the integration" is how you get two truths and a reconciliation spreadsheet that becomes the real system of record.
Separate speed of UI from speed of agreement. You can make a screen feel snappy while still waiting on multi-party state. Lying about agreement is not latency optimisation. It is a negotiation you lost and hid.
None of this excuses accidental bureaucracy or cargo-cult approval chains. Sometimes the negotiation is overgrown and should be simplified. The point is that simplification is also a negotiation: someone loses a veto, someone accepts more risk, someone funds more automation. Pretending those choices are "just UX" or "just tech debt" is how programmes spend a year and still cannot explain a partial refund.
Code is necessary.
Clear negotiation is what makes the code defensible.
The fingerprint
If your architecture diagram looks clean but every incident turns into a meeting about what a field was supposed to mean and who was allowed to change it, you do not have a tooling gap.
You have unfinished negotiation, and the software is doing exactly what unfinished negotiation always does: freezing the argument in production.
Related reading
- Why Enterprise Software Feels Slow (and Why That's Often Correct)
- Why Every Workflow Is Really a State Machine
- The Myth of a Single Source of Truth
- Every Integration Is a Distributed System
Architecture Files #35 · Part of Binary and Beyond. LinkedIn newsletter edition follows. Settling meaning, authority, and exception cost before you encode them? Start a conversation.