Atmora Tech

Engineering

Systems that survive
the next reorganisation

Enterprise software is judged on what it costs to change in year six, not on how it looks at launch. We build for multi-entity structures, role hierarchies that match an actual org chart, and audit trails an external reviewer can follow without your help.

Overview

Platforms for organisations with multiple entities, real auditors and a ten-year horizon.

The hard part of enterprise software is rarely the feature list. It is that eleven business units want the same screen to behave eleven ways, three of them sit in regulated markets, and the group finance close has to reconcile across all of them. We design for that on day one because retrofitting it is the expensive path.

In practice that means an explicit tenancy model, permissions expressed as policy rather than conditionals scattered through controllers, and every state change written to an append-only log with actor, reason and prior value. Reporting reads from a separate model so a heavy quarter-end query cannot slow down order entry.

We also plan around the integrations you cannot decommission. SAP, Oracle EBS, an AS/400 that three departments still depend on: each one gets a versioned contract and contract tests, so an upstream field change fails a pipeline on a Tuesday morning instead of breaking a month-end close on a Sunday night.

9 entities
onboarded onto one platform in the first 14 months
2.3 days
cut from group month-end close after the reporting split
99.96%
measured availability across the last four quarters

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Multi-entity and multi-tenant architecture

    Legal entities, subsidiaries and joint ventures modelled as first-class objects with their own calendars, currencies and approval thresholds, so onboarding an acquisition is configuration rather than a code fork.

  • Identity, roles and delegated administration

    SAML and OIDC federation against Entra ID or Okta, attribute-based policies evaluated in one place, and delegated administration so a regional manager can grant access without raising a ticket with central IT.

  • Audit, compliance and evidence

    Append-only event logs carrying actor, reason and prior value, plus export packs shaped around the questions auditors actually ask under SOX, GDPR and sector regulators rather than a generic activity feed.

  • Workflow and approval engines

    Configurable approval matrices with delegation, out-of-office routing, monetary thresholds and escalation timers, versioned so a chain approved in March can be reconstructed exactly during a November audit.

  • Reporting and finance-close support

    A read model kept separate from the transactional store, period locking, restatement handling and reconciliation reports that tie back to the general ledger line by line instead of in aggregate.

  • Legacy integration and phased retirement

    Versioned contracts and anti-corruption layers around SAP, Oracle EBS and mainframe interfaces, so you retire one legacy module at a time rather than scheduling a single high-risk weekend cutover.

Deliverables

What you get

  • Tenancy, permission and audit model documented and implemented
  • Configurable approval matrices with full version history
  • Single sign-on federated against your existing identity provider
  • Separated reporting model with period locking and restatement
  • Integration contracts, contract tests and anti-corruption layers
  • Capacity model plus a disaster-recovery drill that has been executed

Stack

What we build it with

  • Java 21
  • Spring Boot
  • TypeScript
  • PostgreSQL
  • Oracle Database
  • Apache Kafka
  • Keycloak
  • Camunda
  • Kubernetes
  • Terraform
  • dbt
  • Grafana

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Operating-model review

    We map entities, roles, approval thresholds and reporting obligations before a schema is drawn, because those constraints determine the shape of everything built above them.

  2. Reference architecture

    A written architecture with the trade-offs named: what is centralised, what each entity may configure for itself, and what stays deliberately manual in the first release.

  3. Core platform build

    Identity, tenancy, audit and workflow ship first as a working skeleton, so every business module afterwards inherits them instead of reimplementing them slightly differently.

  4. Module rollout by entity

    One business unit goes live at a time. Each rollout produces a configuration playbook that makes the next unit faster to onboard and less contested internally.

  5. Run and evolve

    Quarterly architecture reviews, dependency upgrades on a published schedule, and a deprecation calendar so nothing reaches end of life without a plan already attached.

When this is the wrong engagement

If you run a single legal entity on one general ledger with fewer than roughly two hundred users, this level of platform machinery is overhead you will pay for and never actually use.

FAQ

Questions we get asked

How is this different from configuring a large ERP?

An ERP is the right answer for ledgers, payroll and procurement, and we will say so when it is. Enterprise builds earn their place around the ERP: the operational processes it models badly, the reporting it cannot produce, and customer-facing systems you would rather not run inside a licensed suite.

Can you deliver without disrupting the current system?

Yes, by strangling it rather than replacing it. New capability sits behind a routing layer that sends specific processes to the new platform while everything else keeps hitting the incumbent. Traffic moves in slices you can reverse in minutes if a reconciliation looks wrong.

What does long-term ownership look like?

We assume you will run it. Deliverables include a capacity model, an upgrade calendar for every dependency, disaster-recovery drills that have actually been executed under observation, and runbooks for the eight or nine incidents that generate most out-of-hours calls.

How do you handle regulated data across jurisdictions?

Data residency is a deployment decision, not an application one. Regional stacks hold their own data stores, and the control plane carries only identifiers and configuration. Cross-border reporting works on aggregates computed inside each region and shipped as figures, never as records.

Related

More in Engineering

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project