How We Built an Enterprise Digital Risk Platform: Architecture, Decisions & Results

The Brief

Novem operates at the intersection of enterprise asset management and facility operations — managing physical infrastructure for organisations that cannot afford unplanned failures. Their clients run critical facilities: substations, water treatment plants, industrial campuses.

When Novem approached us, their risk intelligence process looked like this: asset data lived in one system, risk assessments happened in spreadsheets, and predictive modelling outputs came from a separate analytics tool their data science team maintained independently. A facility manager who needed to understand current risk exposure had to pull data from three places, apply their own judgement to reconcile the outputs, and produce a report manually.

That process worked when the portfolio was small. It stopped working when Novem’s client base grew to the point where a single risk lead was managing hundreds of assets across multiple client organisations simultaneously.

The brief was specific: build a platform where risk assessment, predictive modelling, and portfolio-level reporting exist in a single interface. Make it configurable enough that each client organisation can define what “high risk” means for their asset classes. Make it fast enough that a facility manager can get a current risk picture in under thirty seconds.

---

The Problem With Existing Tooling

Before scoping the solution, we spent the first two weeks of the Discovery phase understanding exactly why existing tools had failed to solve the problem. The answer was not that the tools were bad — it was that they were built for different purposes and assembled into a workflow that created gaps at every handoff.

The spreadsheet-based risk assessments had a structural problem: they were point-in-time snapshots. Once a cell was filled in, it did not update when the underlying asset telemetry changed. A risk score from three months ago looked identical to a risk score from yesterday. Users had learned to check the date on every assessment before trusting it, which added friction and introduced human error.

The separate analytics tool had a different problem: it produced correct outputs but was accessible only to the data science team. A facility manager who wanted to understand why an asset had been flagged as high risk had to file a request and wait for the data science team to respond. The bottleneck was not analytical capability — it was access.

The combination of stale data and access barriers meant that by the time risk intelligence reached the people who needed to act on it, it was often too late to act proactively. Novem’s value proposition was precisely the opposite of that.

---

The Solution: A Configurable Digital Risk Platform

We designed a platform around three principles derived from the Discovery findings:

Real-time over snapshots. Risk scores recompute when the underlying data changes, not when a human updates a spreadsheet. Every score on the platform carries a freshness timestamp, and assets with stale data inputs are flagged automatically.

Self-service over gated access. Any authorised user can drill into any risk score and understand the contributing factors without involving the data science team. The predictive module outputs are surfaced as readable explanations, not just numbers.

Configurable over fixed. Each client organisation can define their own risk scoring parameters — what weight to assign to each predictive module, where to draw the Yellow and Red zone boundaries, and which asset categories to apply which scoring model to.

The Five Predictive Modules

The platform’s risk intelligence is structured around five predictive modules, each modelling a distinct failure mode:

Module	What It Models	Primary Data Inputs
Arc Flash	Electrical incident risk at switchgear and substation assets	Equipment age, maintenance logs, fault history, IEEE 1584 parameters
Wildfire	Asset exposure to wildfire propagation	Geographic position, vegetation proximity, historical fire perimeter data, wind patterns
Transformer Failure	Probability of transformer failure in 90/180/365 day windows	Oil analysis, thermal imaging, load history, age, DGA results
Mechanical Risk	Aggregate mechanical failure probability for rotating and static equipment	Vibration analysis, maintenance frequency, age, OEM MTBF data
Water Leak	Leak detection and propagation risk for water infrastructure	Pressure variance, material age, soil conditions, historical repair records

Each module produces a 0–100 score. The composite risk score for any asset is a weighted average of the relevant module scores, with weights configurable per tenant.

The Risk Scoring Engine

The scoring engine deserves explanation because it was the most consequential architectural decision in the project.

The naive implementation of a risk score is a formula: take the inputs, apply fixed coefficients, return a number. This works for a single client. It breaks the moment a second client has different domain expertise about what the numbers mean.

We built a configurable scoring engine with the following structure:

Module weights — each client defines what percentage of the composite score each predictive module contributes. A client focused primarily on electrical infrastructure might weight Arc Flash at 40% and Wildfire at 10%. A client with water utilities might do the opposite.

Zone thresholds — each client defines where the Green/Yellow/Red boundaries sit on the 0–100 scale. The defaults are 0–39 Green, 40–69 Yellow, 70–100 Red. A more risk-tolerant client might push Red to 80+. A client with regulatory reporting obligations might pull Yellow down to 30.

Category multipliers — certain asset categories can have their scores multiplied before zone classification. An asset designated as critical infrastructure can have a 1.2× multiplier applied, meaning an underlying score of 60 becomes 72 and lands in Red rather than Yellow.

All configuration is stored per-tenant in the database. The scoring engine reads the configuration at query time, applies it to the module outputs, and returns the composite score and zone classification. A configuration change takes effect immediately on the next score computation — no redeployment required.

The risk scoring matrix for Novem’s default configuration:

Zone	Score Range	Recommended Action	Review Frequency
Green	0–39	No immediate action	Annual review
Yellow	40–69	Schedule preventive maintenance	Quarterly review
Red	70–100	Prioritise for immediate intervention	Monthly + alert

---

Technical Stack

Frontend: React 19 with TypeScript. We adopted React 19 specifically for the concurrent rendering improvements — the platform’s dashboard views load multiple independent data panels in parallel, and React 19’s Suspense boundaries with streaming allow the user to see available panels immediately rather than waiting for all panels to resolve before anything renders.

Data fetching: TanStack Query (formerly React Query) for all server state. The stale-while-revalidate pattern is central to the platform’s “freshness” promise — users see the last computed score immediately while a background refetch validates whether a newer score is available.

Charts and visualisation: Recharts for the platform’s custom charts (trend lines, score distributions, module breakdowns). Recharts gave us enough control over the visual language to match Novem’s design system without the overhead of building chart primitives from scratch.

Embedded analytics: Apache Superset for the portfolio-level reporting dashboards. More on this decision below.

Geospatial maps: Leaflet with custom tile layers for the geographic asset view. Assets are plotted with their current risk zone colour, and the map updates reactively when scoring runs.

Backend: Express and Node.js, with PostgreSQL as the primary data store. The choice of Node.js was deliberate — the backend’s primary job is orchestrating data flows between the scoring engine, the predictive module outputs, and the database, rather than heavy computation. Node.js handles that workload well.

Infrastructure: Containerised with Docker, deployed on client-managed infrastructure (Novem’s clients have strict data residency requirements that preclude public cloud deployment).

---

The Apache Superset Decision

One of the more interesting technical decisions in this project was where to draw the line between custom charts and embedded analytics.

Our initial instinct was to build all visualisations in Recharts. Custom charts integrate cleanly with the application’s design system, require no additional infrastructure, and give us complete control over behaviour. For the predictive module dashboards and the asset-level risk breakdowns, this was the right call — these views are tightly coupled to the application’s domain model and interact with application state in ways that would be awkward to manage through an embedded analytics layer.

For portfolio-level reporting, the calculation changed. Portfolio reports require ad-hoc filtering across arbitrary combinations of asset classes, geographies, time ranges, and risk zones. Building a general-purpose report builder from scratch is a multi-month engineering effort that would have consumed half the project timeline. Novem’s clients already had expectations about what analytics interfaces looked like because they had used Superset or Tableau in previous tooling.

We chose to embed Apache Superset for portfolio reporting. The integration approach:

1. Superset runs as a sidecar service, with its own PostgreSQL instance maintaining dashboard definitions and user sessions.
2. Novem’s primary database is added as a Superset data source with read-only credentials.
3. Row-level security rules in Superset enforce tenant isolation — each embed token carries the tenant_id as a filter that Superset applies before executing any query.
4. The main application generates embed tokens via Superset’s Guest Token API. Tokens are short-lived (15 minutes), scoped to a specific dashboard, and carry the requesting user’s tenant context.
5. The frontend renders the embedded dashboard in an iframe with the token as a URL parameter.

The result: Novem’s team can build and modify portfolio dashboards in Superset without requiring application deployments, while data isolation is enforced at the query layer independently of the application.

The lesson here is not “always use Superset” — it is that the decision between custom charts and embedded analytics should be driven by query complexity and expected iteration rate, not by a preference for clean integration. When the query requirements are complex and the report schemas will change frequently, embedded analytics tooling earns its complexity cost.

---

Project Phases and Timeline

Phase	Duration	Key Deliverables
Discovery	2 weeks	Requirements documentation, data model design, API contracts, scoring engine specification, Superset integration architecture
Core Platform	8 weeks	Authentication + RBAC, tenant data model, scoring engine, asset management views, map interface, admin configuration panel
Predictive Modules	4 weeks	All 5 predictive module UIs, module score integration into composite scoring, trend visualisation, alert system
Integrations	2 weeks	Apache Superset embedding, external data source connectors, client data migration, UAT and hardening

Total: 16 weeks (4 months)

The 8-week Core Platform phase was deliberately front-loaded with the hardest architectural work. The scoring engine and multi-tenant data model were designed and reviewed in week one, before any feature development began. This meant that when the Predictive Modules phase started in week eleven, the team was writing feature code against a stable foundation rather than discovering data model problems mid-feature.

---

RBAC and Audit Logging

Novem’s platform operates across three distinct user classes with meaningfully different access requirements:

Platform Administrators — Novem staff who configure tenant settings, manage client onboarding, and access cross-tenant reporting. Full access to all tenant configurations but no access to client operational data.

Client Administrators — Senior users within a client organisation who manage their own tenant configuration (scoring weights, zone thresholds, user management) and have full access to their organisation’s risk data.

Facility Managers — Operational users within a client organisation. View access to risk scores and predictive module outputs. No access to configuration. Cannot see data outside their assigned facility portfolio.

RBAC is implemented as a combination of role checks at the route level (Express middleware) and permission checks at the service layer. The service layer checks are the authoritative ones — a route-level check is a performance optimisation (reject obviously unauthorised requests early) but not a security boundary.

Every data access event is logged with: timestamp, user ID, tenant ID, action type, resource type and ID, and the resulting response code. Logs are append-only and stored separately from the primary database, with a retention policy set by the client. For Novem, the retention requirement is seven years — a function of the regulatory environment their clients operate in.

---

Results

The platform launched to Novem’s first three client organisations at the end of month four. Key outcomes:

Consolidated tooling. The platform replaced five separate vendor dashboards that Novem’s clients had been maintaining. The risk intelligence that previously required navigation across multiple tools is now accessible from a single interface.

Configurable per-client scoring. Each of the initial three clients configured their own scoring parameters during onboarding. Client one weighted Arc Flash at 45% (electrical utility). Client two weighted Wildfire at 50% (wildland-adjacent industrial). Client three used the default equal-weight distribution. All three configurations run on the same codebase — no client-specific deployments.

Freshness visibility. Users can now see, for every risk score, when the score was last computed and whether the underlying inputs have changed since. The stale-data problem that characterised the spreadsheet process is eliminated by design.

4-month delivery on a 4-month brief. The project came in on schedule because the Discovery phase produced a scope document that both parties had signed off on before development began. Scope changes during development — which had derailed previous vendor engagements Novem had experienced — were eliminated because there was no ambiguity about what was in scope.

---

Key Lessons

Configurable scoring beats hardcoded thresholds every time. We have now built three scoring engines. In each case, the client’s definition of “acceptable risk” diverged from their initial brief once they saw real data in the system. A configurable engine absorbs those changes as a configuration update. A hardcoded engine requires a developer and a deployment. For enterprise clients with procurement processes, the latter is a relationship problem, not just an engineering inconvenience.

Embedded analytics earns its cost at a specific complexity threshold. The crossover point is roughly: if you need ad-hoc filtering across more than three independent dimensions and the report schemas are likely to change without application deployments, embedded analytics is cheaper than building a custom report builder. Below that threshold, custom charts are cleaner.

Multi-tenant data isolation needs to be built first, not retrofitted. We designed the tenant isolation model in week one of the Core Platform phase and reviewed it before any tables were created. The cost of retrofitting tenant isolation into an existing schema is roughly equivalent to rebuilding the data layer from scratch. Building it correctly at the start is not over-engineering — it is the cheapest way to build it.

---

This project is documented as a case study on the Novem Digital Risk Platform page. If you are evaluating options for an enterprise risk platform or a similarly complex data-intensive application, see our enterprise web applications service page for an overview of how we approach these engagements.