“Integrated suite” is a phrase that usually means the opposite of what a buyer hears. It means separate products, kept in agreement by machinery, sold behind one invoice.
Trivena is not integrated, and the distinction is the most important technical decision in the product.
What integration actually is
When a sales order in system A must produce a stock movement in system B and a ledger entry in system C, something has to carry those facts across. A webhook, a queue, a nightly batch, an integration platform.
That machinery has failure modes, and they are all the same failure wearing different clothes:
- The message is delivered twice, so a stock movement is doubled
- The message is not delivered, and nobody notices until a count in March
- The message arrives out of order, so a cancellation lands before the thing it cancels
- The batch runs while a document is mid-flight and captures half of it
- System B rejects the record for a validation reason system A did not know about
Every engineer who has worked on this knows the mitigations: idempotency keys, dead letter queues, retries with backoff, reconciliation jobs. They are good techniques and they work. They also add a layer whose entire job is compensating for the fact that the truth is stored twice.
The alternative
All applications in the suite are one deployment writing to one database. A sales order, its stock movement and its ledger entries are written inside a single database transaction.
Either all of them exist or none of them do. There is no window during which the warehouse and the ledger disagree, because there is no interval between the writes at all.
That single property removes:
- Reconciliation jobs, because there is nothing to reconcile against
- Duplicate customer identities across systems, because there is one customer table
- Staleness, because reporting reads the same rows the applications write
- The entire class of partial-failure bugs described above
It also means a report cannot be out of date relative to the system it describes. Not “refreshed every fifteen minutes”. The same rows.
What it costs
This design has genuine downsides and I would rather write them down than let a customer find them.
You cannot swap an application. They are not modules with clean interfaces to the outside; they share a schema. If you want a different CRM, you want a different product.
Our releases are coupled. A change to a shared concept touches everything that uses it. This makes us slower and more careful, which is the correct trade for accounting software and would be the wrong trade for a consumer app.
Scaling is per Site rather than per service. We cannot scale the helpdesk independently of the ledger. In practice this matters far less than it sounds, because a single company’s workload is small relative to a machine, and it is why plans are sized on compute rather than on modules.
Where integration still belongs
Outside the company boundary, integration is correct and unavoidable. Your bank, your carrier, your payment provider, the tax authority and your identity provider are genuinely separate parties with their own systems, and connecting to them properly means all the machinery above: retries, idempotency, delivery logs.
We build that carefully, and we publish what it covers. The difference is that the list is short, because the things a company usually integrates are already inside the same database.
The agent consequence
There is a second-order effect that only became obvious once the agent layer existed.
An agent answering “why is this customer unhappy” needs the order, the shipment, the invoice, the support history and the last three emails. In a stack of six systems that is six authentications, six permission models, six freshness assumptions and a federation layer to hold them together. Most vendors solve it by building a unified index, which is a copy of everything, sitting outside the permission model.
With one database it is one query path under one permission model. The agent inherits your permissions because there is only one set of permissions to inherit. Nothing needs to be copied anywhere, which is why we can promise that nothing is retained.
The architecture decision made in the first month turned out to be the reason the agent layer could be built safely three years later. That was not foresight. It was luck, arriving on top of a decision made for much more boring reasons.
