Enterprise Architecture Design Principle: Resolving the Tension Between Centralized Corporate Data and Customized Local Company Profiles¶

2026-07-18

Intent¶

We are designing a highly customized Odoo 18 platform that supports multiple legal companies operating within a single Odoo instance. The objective is not simply to configure Odoo's native multi-company features, but to establish a long-term enterprise architecture that balances two competing requirements:

Corporate Standardization
Local Company Autonomy

The architecture must preserve a single corporate source of truth while allowing each company sufficient flexibility to operate independently without fragmenting corporate data. This design principle should become a reusable foundation across the entire platform rather than being limited to Products.

Background¶

Traditional ERP systems, including Odoo, often force an undesirable binary decision:

Duplicate master data for every company, or
Share one global record with insufficient local customization.

Neither approach scales.

Duplicating master records inevitably leads to:

Inconsistent engineering definitions
Duplicate maintenance
Diverging Bills of Materials
Broken reporting
API ambiguity
Synchronization problems
Increasing technical debt

Conversely, a fully centralized model prevents local companies from adapting products, terminology, workflows, commercial practices, regulatory content, marketing language, and customer-facing presentation to their local markets.

Our architecture must resolve this tension without sacrificing either corporate consistency or local flexibility.

Architectural Principle¶

Every enterprise object should be separated into two conceptual layers.

Layer 1 — Corporate Object¶

A Corporate Object represents the identity of the object itself.

It answers the question:

"What is this thing?"

Examples include:

Product
Customer
Supplier
Asset
Service Template
Warranty Template
Fleet
Location
Document Template

A Corporate Object should possess the following characteristics:

Globally unique identity
Stable and immutable identifier
Corporate source of truth
Engineering ownership
Cross-company reporting identity
Primary API identity
Long lifecycle

Corporate Objects should almost never be duplicated merely because different companies require different business behavior.

Layer 2 — Contextual Association (Edge Object)¶

An Edge Object represents the relationship between a Corporate Object and another organizational context.

It answers the question:

"How does Company X use this object?"

Examples include:

Company ↔ Product
Company ↔ Customer
Company ↔ Supplier
Company ↔ Service
SA ↔ Customer
SA ↔ Fleet
Channel ↔ Product
Country ↔ Regulatory Approval
Region ↔ Warranty Policy

The Edge Object contains information that belongs to the relationship rather than to the Corporate Object itself.

The Architectural Tension¶

The central architectural challenge is balancing:

Centralized Corporate Data

with

Customized Local Company Profiles

Neither extreme is acceptable.

Excessive Centralization¶

If everything is centralized:

Local companies lose flexibility
Marketing becomes constrained
Local terminology cannot be customized
Regulatory requirements become difficult to satisfy
Sales organizations become less effective
Customer experience deteriorates

Excessive Decentralization¶

If every company duplicates master data:

Engineering diverges
BOMs drift apart
Product identities become fragmented
Reporting loses meaning
APIs become unreliable
Data synchronization becomes a permanent maintenance burden

The architecture should therefore preserve exactly one corporate identity while allowing unlimited contextual customization.

Product as the Primary Example¶

A Product provides an excellent illustration of this architectural principle.

A Global Product should exist exactly once.

It should contain information such as:

Global Product ID
Global Part Number
Engineering Name
Technical Specifications
Engineering Drawings
Bill of Materials
Product Family
Tracking Method
Serial Number Policy
Warranty Compatibility
ABS Compatibility
Lifecycle Status

For example:

Product ID:
PRD-00001842

Part Number:
BAT-LFP-7250

Engineering Name:
72V 50Ah LFP Battery Pack

This object should never be duplicated merely because different companies wish to describe or market it differently.

Instead, each company should have its own Company Product Profile, implemented as an association (edge) object.

For example:

OVES Kenya

Local Product Name
English Description
Swahili Description
Marketing Description
Local Product Category
Regulatory Notes
Sales Enabled

OVES Togo

French Product Name
French Description
Packaging Description
Local Regulatory Text
Commercial Category

OVES Philippines

Local Commercial Name
Subscription Marketing Description
Rental Policy
Website Description

All three company profiles point to the same global Product:

BAT-LFP-7250

No duplicate products exist.

Only multiple contextual company profiles.

Important Principle¶

A Company Product Profile is not another Product.

It should not own:

Inventory
Stock
Serial Numbers
Bills of Materials
Procurement History
Manufacturing History
Product Identity

Instead, it simply describes one company's relationship with the Corporate Product.

All transactional documents continue to reference the single Global Product.

Generalization¶

This principle should become a reusable enterprise modeling pattern throughout the platform.

Rather than asking:

"Should this object be duplicated?"

the design process should instead ask:

"Is this actually another Corporate Object, or merely another relationship with the same Corporate Object?"

Whenever the latter is true, an explicit Association (Edge) Object should be created instead of duplicating the Corporate Object.

Design Pattern¶

This architectural pattern can be summarized as:

Central Object + Contextual Edge

where:

Corporate Objects represent enterprise truth.
Edge Objects represent company-, SA-, channel-, region-, country-, or role-specific behavior.

This pattern should become the preferred modeling approach across the entire OVES ecosystem.

Benefits¶

Adopting this architecture should:

Minimize duplicated master data
Preserve a single corporate source of truth
Maximize local autonomy
Improve API consistency
Improve reporting accuracy
Simplify AI reasoning
Reduce long-term maintenance
Support future expansion into new countries, companies, channels, and business models without redesigning the data model

General Applicability¶

Although Product is the primary example, this architectural pattern should be evaluated for all enterprise master data, including:

Products
Customers
Suppliers
Assets
Fleets
Service Templates
Warranty Templates
Pricing Policies
Sales Channels
Locations
Documents
Regulatory Approvals
Subscription Templates
ABS Services

The objective is to establish a consistent modeling philosophy across the entire platform rather than solving each module independently.

Questions for Architectural Analysis¶

For every major master-data domain, evaluate the following questions:

Which fields belong to the immutable Corporate Object?
Which fields belong to the Contextual Association (Edge Object)?
What is the ownership and lifecycle of each?
Should transactional records reference only the Corporate Object, or both the Corporate Object and the Edge Object?
What naming conventions and database schema best support this pattern while remaining upgrade-friendly with Odoo 18?
Which requirements can leverage native Odoo multi-company capabilities, and where is a custom association model justified?
Can the "Central Object + Contextual Edge" pattern become the standard enterprise modeling approach across the entire OVES platform, ensuring architectural consistency for future modules such as ABS, Fleet, CRM, Service, Warranty, Channel Management, and AI Agent integration?