The Arithmetic Nobody Escapes
Connect two systems and you maintain one integration. Connect five and you maintain up to ten. Connect twenty-three — the number of applications in Own360’s System of Record — and the worst case is 253 pairwise paths. Nobody builds all 253, of course. They build the twelve they need this quarter, then the eight they need next quarter, and within three years the integration diagram is a plate of spaghetti that no single person can draw from memory.
The count is not even the real problem. The real problem is what each arrow is: a private contract between two codebases. App A calls App B’s API, which means App A has hardcoded assumptions about App B’s endpoints, auth, schema, and failure behavior. When B changes, A breaks — usually silently, usually at night, usually discovered by a user. Multiply that fragility by every arrow on the plate.
Fig 1 — The mesh grows quadratically and privately. The spine grows linearly and publicly.
Publish, Don’t Call
Own360 apps never call each other. Not sometimes, not for special cases — never. When something meaningful happens inside an app, the app publishes an event to OwnBus, the platform’s signed event spine: entity.changed, with the entity type, the id, the tenant, and the actor who caused it. That is the app’s entire integration responsibility. It does not know who is listening. It does not care.
Everything downstream is subscription. OwnBooks subscribes to sales-order events from OwnERP and raises vendor invoices when a PO is delivered. OwnDesk subscribes to incident events from OwnITSM and mirrors a public status ticket. OwnBI subscribes to nearly everything. Adding the twenty-fourth app to the platform means writing one publisher and choosing subscriptions — not negotiating twenty-three bilateral API integrations.
In a mesh, integration is something you build between apps. On a spine, integration is a property of showing up.
Anatomy of a Signed Event
The spine only works if events can be trusted, which is why every event on OwnBus is signed and enveloped. The envelope answers, cryptographically, the questions an auditor or an on-call engineer will ask later:
Fig 2 — The envelope carries who, what, where, and proof. Subscribers verify before they trust.
Two properties fall out of this envelope that point-to-point calls can never provide. Attribution: every downstream effect traces back to the actor — human or agent — that caused the originating event, across any number of hops. Replay: because the spine retains the ordered event log, a new subscriber can be brought up from history, and an on-call engineer can re-drive yesterday’s events through a fixed consumer instead of reconstructing state by hand. This is the integration-topology counterpart to the storage argument in our event-sourcing piece — same log-first philosophy, applied between apps instead of inside one.
Failure Is Local by Construction
In a call mesh, failure propagates. If Books is down when ERP tries to notify it about a delivered PO, ERP now owns a problem it shouldn’t have: retry queues, circuit breakers, alerting for a dependency it never wanted. Multiply by every arrow.
On the spine, the publisher’s job ends at publish. If a subscriber is down, its events wait, durably, in its consumer stream; when it recovers, it resumes from where it stopped and works through the backlog. The publisher never blocks, never retries, never even notices. A slow subscriber gets backpressure; a broken one gets a paged owner and an intact backlog — not a lost update and a reconciliation project.
How the 42 Workflows Ride the Spine
Own360’s agent task catalog includes 42 verified cross-app workflows — quote-to-cash from CRM through ERP to Books, hire-to-onboard from HRMS through Wiki to Tasks, incident-to-public-status from ITSM to Desk. Every one of them is an event cascade, not a call chain. Each hop is a subscriber reacting to a signed event and publishing its own, with the originating entity id carried in every envelope. The workflow’s full history is therefore already written — hop by hop, actor by actor — in the one place an auditor needs to look.
And because agents subscribe to the same spine the apps do, an agent doesn’t need bespoke plumbing to react to the business in real time. DealAgent hears deal.changed the same way OwnBI does. The spine is one more reason agent context compounds on a connected stack — the same argument we make in The 42 Workflows, seen from the infrastructure side.
Fig 3 — Quote-to-cash as events: each hop reacts and publishes. Ids accumulate in the envelopes.
“Isn’t This Just an ESB?”
The enterprise service bus of the 2000s failed for a reason worth naming: it became a place where transformation logic went to hide. Teams pushed mapping, routing, and business rules into the bus until it was the most complex, least-owned system in the building. OwnBus refuses that job. It moves signed envelopes; it does not transform them. Business logic lives in the apps that own the entities — the bus guarantees delivery, ordering, attribution, and replay, and nothing else. Thin spine, smart endpoints, published contracts. That division of labor, not the topology alone, is what keeps the twenty-third app as cheap to connect as the third. And unlike an iPaaS subscription, the spine ships with the platform — it is not a second vendor with its own renewal, its own credentials vault, and its own opinion about your schema.
The Test
Ask your integration diagram two questions. How many arrows would a new system add? And when an arrow breaks at 2 a.m., does the failure stay on one side of it? If the answers are “N” and “no”, you are maintaining a mesh, and the mesh is charging you interest. The alternative is not better middleware. It is a stack where publishing is the only integration primitive — and everything else is a subscription.
Watch the spine carry a workflow
Deal to order to invoice — three apps, zero direct calls, one ordered and attributable event log.
See it live →