Proven Enterprise Solutions

Which platform fits, and when none of them do

Four platforms with overlapping capability is genuinely confusing from the outside. The distinction that matters is not feature lists — it is which system owns the record, and which regulatory obligation the deployment has to satisfy.

Start from the system of record, not the feature list

Every platform decision in an enterprise estate reduces to one question: for a given entity — a customer, a transaction, a case, an invoice — which system holds the authoritative version, and which systems hold copies?

Getting this wrong is the most common cause of the integration problems we are called in to remediate. Two systems both believing they own the customer record produces reconciliation work that never ends, because there is no principled way to resolve a conflict between them. Decide ownership per entity before you decide anything about the platforms, and the rest of the architecture follows.

Where each platform sits

NovuShield owns compliance decisions and the evidence behind them — screening outcomes, monitoring alerts, case dispositions, and the regulatory submissions that follow. It is the only one of the four with a hard external schema contract, because reporting to a financial intelligence unit is validated on submission and rejected outright when it does not conform. That constraint shapes everything about how it is deployed, and it is covered in detail in our goAML integration guide.

NovuPay owns money movement and the ledger behind it. Its defining requirement is not throughput, it is finality: on an instant rail a credit is applied and irrevocable within seconds, so validation moves ahead of the transaction and correction stops being a technical option. The engineering consequences — idempotency enforced at the database, reconciliation as a first class process rather than an error path — are set out in our RAAST integration guide.

NovuERP owns operational and financial process — the internal record of what the organisation did. NovuCRM owns the relationship record: who the counterparty is, every interaction with them, and the commercial pipeline. The two are frequently deployed together, and the boundary between them is the most common place we see duplicated customer data take root.

Deployment and data residency

For regulated institutions, where the data physically sits is usually a harder constraint than any functional requirement, and it is worth establishing before a demo rather than after. Financial and health data frequently carry residency obligations that rule out particular hosting arrangements outright, and a platform decision taken without that constraint in view is a decision that gets revisited.

All four platforms are designed to be deployed into infrastructure the client controls where that is required, rather than assuming a single shared tenancy. What that means concretely for your estate — and what it costs in operational overhead — is a conversation to have with an architect, because the honest answer depends on your existing infrastructure and your regulator's position.

Integration is where the effort actually lives

In our experience of these deployments, the platform configuration is rarely the long pole. The work is in the integration surface: the core system these platforms have to sit alongside, the identity source they authenticate against, the data migration from whatever is being replaced, and the reconciliation between old and new during the transition window.

Migration in particular is routinely underestimated. Historical data almost never conforms to the model the new system expects — records with missing mandatory fields, identifiers that were free text, duplicate entities that were never merged. Deciding what to do with non-conforming history is a business decision with regulatory implications, not a technical one, and it needs an owner early.

When a platform is the wrong answer

If your requirement is genuinely standard, a mature commercial product will almost always beat anything built or configured for you — on cost, on time to value, and on the amount of maintenance you inherit. We say so when that is the case, and we have written up the reasoning in our note on custom platforms versus off-the-shelf ERPs.

The case for a platform like these is strongest where the requirement is shaped by a regulator whose schema you do not control, wired into systems nobody else runs, in a market too small for the large vendors to have built for properly. That is a real and specific situation — it is most of what we do — but it is not every situation, and a supplier who tells you it is should be treated with caution.