The Stratum Framework: A Four-Layer Architecture for Odoo Implementations

Each layer has a defined scope. Nothing crosses layer boundaries. The result is an implementation that can be upgraded, replicated, and handed over without archaeology.

L4

Client Configuration

Company settings, pricing rules, user permissions, email templates

L3

Implementation Module

Business-specific workflows, custom views, client reports

L2

Base Architecture Module

Custom models, security groups, ACLs, API abstraction, automations

L1

Odoo Core Platform

Standard Odoo modules: Sales, Purchase, Helpdesk, Inventory etc.

Built for Long-term Scalability

Most Odoo implementations are built as a single monolithic block. Configuration, business logic, custom models, and Odoo core are all mixed together. This works until it does not. The first major version upgrade, a new consultant taking over, or a second environment being provisioned exposes the problem. Everything breaks because nothing was separated.

The Stratum Framework solves this by enforcing a strict four-layer separation from the first commit. Each layer has a defined scope. Nothing crosses layer boundaries. The result is an implementation that can be upgraded, replicated, and handed over without archaeology.

L1

Odoo Core (Foundation)

Standard Odoo modules are never modified directly. No monkey-patching, no core hacks. This layer is preserved exactly as Odoo ships it, which means upgrades apply cleanly every time.

  • Core module integrity
  • Formal release tracking
L2

Base Architecture

Custom models, security groups, access control lists, API abstraction layers, and automation rules live here. Version-controlled, reusable across engagements, never modified directly in production.

  • Standardised API patterns
  • Cross-client reusability
L3

Implementation Module

Business-specific workflows, client-facing views, custom reports, and process automation live here. This layer is isolated per engagement. Upgrading L1 or changing L2 does not break L3.

  • Custom business logic
  • Client-party integration
L4

Client Configuration

Company settings, pricing rules, user permissions, email templates, and lookup data. This layer changes without code. A configuration error does not require a developer to fix.

  • UI/UX personalisation
  • Dynamic workflow rules

Deployment

Every Stratum engagement is deployed through a Git-controlled pipeline: Development to Staging to Production. A new environment is provisioned by deploying the version-controlled modules. No database dump. No environment drift.

See how the Stratum Framework applies to your project

Start with a Feasibility Assessment. You get a written review, a module recommendation, and an architecture roadmap, all within 2 to 5 working days.