Case study
Center of Excellence: 15 Business Units, One Architecture
Centralized governance architecture scaling from siloed implementations to unified strategy
The problem
TotalEnergies ran four independently procured Salesforce orgs across business units, with conflicting data models, no group-level reporting, and zero knowledge sharing. The estate carried 400+ Apex classes, 1,200+ custom fields, and 200+ active flows with significant duplication. Five more business units were arriving in 18 months, ready to replicate the fragmentation pattern at scale.
What I did
A Center of Excellence was designed around three pillars: governance (Architecture Review Board, version control, mandatory peer review), architecture rationalisation (shared component library, canonical Account model, master data management), and enablement (200+ consultants trained, internal certification track). Five new BUs onboarded inside the framework over 12 months.
At a glance
- Client
- TotalEnergies
- Sector
- Energy
- Engagement
- 12 months
- My role
- Lead Solution Architect and CoE Architect
- Salesforce clouds
- Sales Cloud · Service Cloud · Marketing Cloud · Experience Cloud
- Outcome
- 15 business units unified
Before / After
- Four Salesforce orgs procured and maintained independently, no group-level reporting.
- 400+ Apex classes, 1,200+ custom fields, 200+ flows with significant duplication.
- Two orgs sharing 60 percent of components but with separate, divergent code bases.
- Configuration changes made directly in production in two orgs; one org not backed up in 18 months.
- 8M+ records modelled inconsistently across the estate, no master data management.
- 15 business units under one governance framework with a live architecture diagram.
- Shared Apex library and LWC components removed roughly 60,000 lines of duplicated code.
- Multi-org architecture with shared metadata deployed as managed packages.
- Mandatory version control, peer review, 80 percent test coverage, Sandbox to UAT to Production promotion.
- Canonical Account model, master data management strategy across the 8M+ records.
Situation
TotalEnergies had adopted Salesforce across multiple business units over the course of five years. B2B energy sales in Europe ran on Sales Cloud. Lubricants used a separate Salesforce org for distributor management. Renewable energy had built its own implementation. Corporate services ran yet another. Each business unit had procured, built, and maintained its Salesforce implementation independently, with separate contracts, separate administrators, and separate architectural decisions.
The result was a Salesforce estate with four distinct orgs, conflicting data models, zero knowledge sharing between teams, and no ability to report at the group level on Salesforce-related metrics. A question as simple as “how many Salesforce users does TotalEnergies have globally?” could not be answered without manually aggregating data from four separate systems.
The strategic challenge was compounded by a planned expansion. TotalEnergies was adding five new business units to Salesforce over the following 18 months. Without intervention, the fragmented architecture would scale with each addition: more silos, more technical debt, more governance gaps. Business unit heads had no visibility into what other units had built. Teams were solving the same architectural problems independently and billing the same integration work multiple times.
Leadership decided to establish a Salesforce Center of Excellence to govern the existing estate, rationalise where possible, and create a governance framework that would ensure new implementations met a common standard.
Challenge
A technical assessment of all four existing orgs revealed the scope of the problem. The four implementations had accumulated 400+ active Apex classes, 1,200+ custom fields, and more than 200 active flows, with significant duplication across orgs. Two orgs had been built by the same SI and shared 60 percent of their technical components, yet maintained separate code bases that had diverged over three years of parallel maintenance.
Data governance was absent. No naming conventions were enforced, no field-level documentation standards, no test coverage requirements, and no deployment process. Configuration changes were made directly in production in two of the four orgs. One org had not been backed up in 18 months.
The 8M+ customer and partner records across the estate were modelled inconsistently. A “distributor” in the lubricants org was an Account; in the renewables org, it was a custom object. There was no master data management strategy, no deduplication process, and no single source of truth for any entity type.
For the data foundation required to support future Agentforce and Data Cloud deployment, a stated priority on TotalEnergies’ Salesforce roadmap, this architecture was inadequate. Intelligent cross-business-unit automation cannot run on four fragmented data models.
What I told the CIO during the assessment readoutFive more business units arrive in 18 months. Either we build the framework now and onboard them inside it, or we are still cleaning this up in three years.
Action
The Center of Excellence was designed around three pillars: governance, architecture rationalisation, and enablement. Each pillar had to land before the five new business units arrived, or the framework would be a document, not a control.
Governance
Architecture Review Board with IT, business unit, and CoE representation. All architectural decisions above a defined complexity threshold required ARB sign-off, with an expedited path for urgent requests. Mandatory version control (Salesforce CLI + Git), peer review for Apex and Flow, 80 percent test coverage, Sandbox to UAT to Production promotion. The two orgs making production changes directly were placed on a process remediation plan.
Architecture rationalisation
Shared component library deployed as managed packages: common Apex utilities, shared LWCs, standardised integration patterns. The two orgs sharing 60 percent of components merged their shared layer rather than the orgs themselves. Canonical Account model with record types for business-unit-specific entity needs; custom-object count dropped 40 percent. Master data management strategy applied to the 8M+ records.
Enablement and onboarding
Five new business units onboarded over 12 months. Each onboarding followed a structured process: architecture assessment of existing systems, mapping to the canonical model, implementation against defined standards, handoff to administrators trained in CoE governance. Internal certification track for all 200+ consultants across SI partners.
Architecture documentation was created for every component of the estate: data dictionary, integration catalog, technical debt register, and a live architecture diagram updated with each significant change. For the first time, TotalEnergies had a complete view of its Salesforce estate, owned by a function with the authority to keep it current.
Result
TotalEnergies consolidated 15 business units under a unified Salesforce governance framework, with 8M+ records governed under consistent data-quality standards for the first time. The fragmented, independently maintained estate became a managed, documented, and continuously monitored platform.
Development efficiency improved materially. Shared components reduced duplication: the common Apex library and shared Lightning Web Components removed approximately 60,000 lines of duplicated code across the estate. New implementation projects for incoming business units deployed 40 percent faster on the standardised templates compared to ad-hoc builds.
The architecture rationalisation also prepared the estate for the next layer. With a canonical data model, consistent governance processes, and a clean master data foundation, TotalEnergies’ Salesforce environment is positioned for Data Cloud across business units, enabling cross-BU customer analytics, unified partner data, and Agentforce deployment on a foundation that can support enterprise-scale AI.
The CoE model itself became a reference architecture inside TotalEnergies’ broader digital transformation programme, with the governance framework and enablement approach applied to other enterprise platforms.
Reflection
This pattern works when an organisation has three or more business units on the same Salesforce platform, when growth is imminent, and when leadership accepts that the framework has to land before the next onboarding ships. It is the right call when AI or Data Cloud sits on the roadmap and the data foundation needs to be group-wide rather than per-BU.
It works less well when there is only one business unit live and no near-term expansion. The framework still helps, but the overhead of an ARB and a shared component library is hard to justify before the second business unit is on the way.
Worth doing earlier: the canonical Account model and the data dictionary. Both are cheap to establish when one or two business units are live and increasingly expensive as the estate grows.
Technologies used: Salesforce Sales Cloud (multi-org), Salesforce CLI, Git (version control), Managed Packages, Lightning Web Components, Apex, custom metadata types, Salesforce DX deployment pipeline
Glossary
- Center of Excellence (CoE)
- A central function that sets architectural standards, governs decision-making across multiple business units, and enables consultants and admins to deliver to a common bar. Owns the data dictionary, integration catalog, and technical debt register for the platform.
- Architecture Review Board (ARB)
- A cross-functional governance body with IT, business unit, and CoE representation. Reviews architectural decisions above a defined complexity threshold. Holds the authority to approve, reject, or defer designs against the canonical standards.
- Shared component library
- A versioned repository of Apex utilities, Lightning Web Components, and integration patterns published as managed packages to all consuming orgs. Eliminates code duplication and creates a single point of upgrade.
- Master data management
- The strategy for keeping shared entities (Customer, Account, Partner, Product) consistent across orgs and business units. Includes deduplication rules, named data stewards, and a data-quality scoring model measuring completeness, accuracy, and freshness.
Frequently asked
- A full merge of four diverged orgs would have been high risk and high disruption, especially with five more business units arriving in 18 months. The multi-org architecture kept the orgs separate but unified the components: shared Apex utilities, shared Lightning Web Components, and standardised integration patterns published to a shared repository and deployed as managed packages. The orgs remain operationally independent. The architecture is governed centrally.
- Two design choices. A defined complexity threshold means only architectural decisions above a certain scope reach the ARB. Routine changes flow through the standard lifecycle (version control, peer review, change set promotion) without escalation. And an expedited review path handles urgent requests inside 48 hours. The ARB does not approve every flow or field; it governs the architecture, not the day-to-day delivery.
- Distributor, corporate customer, government body, retail consumer, B2B wholesale account: each business unit has legitimate but different entity needs. The canonical model uses record types and custom metadata for business-unit-specific configurations, sitting on top of one shared Account schema. The common fields are governed centrally; business-unit-specific extensions stay with the BU. This dropped the custom-object count by 40 percent across the estate.
- Most consultants knew Salesforce. What they did not know was the TotalEnergies standards: canonical Account model, naming conventions, integration patterns, deployment process, and the ARB submission path. Standard operating procedures covered every working practice from field naming to change control. An internal certification track ensured anyone working on TotalEnergies orgs could demonstrate compliance, regardless of which SI partner they worked for.
- Enterprise-scale AI cannot run on four fragmented data models. The canonical Account model, the master data management strategy, the consistent governance processes, and the data-quality scoring model together create the foundation Data Cloud needs to ingest across business units. Agentforce deployments downstream can then reference unified customer and partner records, with the same governance the rest of the estate runs on.
Book the call
We'll know in 30 minutes
whether I can help.
No slides. No pitch deck. Bring the architecture diagram or describe the problem in your own words. I'll tell you whether I'm the right fit and what the next step costs — before you've finished your coffee.
- Replies within 24 hours, always
- If I'm not the right fit, I'll point you at someone who is
- No follow-up emails unless you ask