Governance Model

Governance determines how decisions get made, who makes them, and how changes flow through the organization. In CTA scenarios, weak governance is a common underlying cause of failed implementations. The review board expects a CTA to design governance structures that balance control with agility — too much governance stalls delivery, too little creates chaos.

Architecture Review Board (ARB)

The ARB is the governing body that ensures architectural decisions align with organizational standards, long-term strategy, and technical best practices.

ARB Structure

Role	Responsibility	Typical Participant
Chair	Facilitates meetings, ensures decisions are documented	Enterprise Architect or CTA
Voting Members	Evaluate proposals, make decisions	Technical Architects, Lead Developers
Subject Matter Experts	Provide domain-specific input when needed	Security, Integration, Data specialists
Requestors	Present proposals for review	Project teams, feature owners
Executive Sponsor	Breaks ties, provides strategic alignment	VP of Engineering or CTO

ARB Meeting Cadence

Meeting Type	Frequency	Purpose
Regular Review	Bi-weekly or monthly	Review pending architectural proposals
Emergency Review	Ad hoc	Critical issues requiring immediate architectural decisions
Quarterly Strategy	Quarterly	Review architectural roadmap, standards updates
Annual Review	Annually	Technology radar update, standards refresh

What Goes Through the ARB

New integration patterns or middleware selection
AppExchange package adoption (using the vendor evaluation scorecard)
Data model changes affecting more than one application area
New technology adoption (LWC components, OmniStudio, Agentforce)
Cross-cloud or multi-org architectural decisions
Changes to the org’s security model
Significant automation changes (new triggers, complex flows)

ARB Review Process Flow

flowchart TD
    A([Architecture Change<br/>Requested]) --> B{Does it match<br/>existing patterns?}
    B -->|Yes| C[Use Existing Pattern<br/>No ARB Needed]
    B -->|No| D[Submit ARB<br/>Proposal]

    D --> E[Proposal Document<br/>Problem + Options +<br/>Recommendation]
    E --> F[Schedule ARB<br/>Review Session]
    F --> G[Present to<br/>ARB Members]
    G --> H{ARB Decision}

    H -->|Approved| I[Document as ADR<br/>Update Standards]
    H -->|Approved with<br/>Conditions| J[Address Conditions<br/>Resubmit if Major]
    H -->|Rejected| K[Revise Proposal<br/>or Use Alternative]
    H -->|Deferred| L[Gather More Info<br/>Reschedule Review]

    I --> M([Proceed with<br/>Implementation])
    J --> M
    K --> D
    L --> E

    style A fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style M fill:#2d6a4f,stroke:#1b4332,color:#fff
    style K fill:#e76f51,stroke:#c45a3f,color:#fff
    style I fill:#2d6a4f,stroke:#1b4332,color:#fff

Lightweight ARB

Not every decision needs a formal ARB session. Establish clear criteria for what qualifies as an ARB-level decision (new patterns, cross-domain impact, vendor selection) versus what can be decided by the tech lead within existing standards. Over-governing slows delivery; under-governing causes drift.

What Does NOT Need ARB Approval

Bug fixes within existing architecture
Configuration changes within established patterns
Minor field additions to existing objects
Report and dashboard creation
Standard Flow modifications within the one-automation-per-object pattern

Change Advisory Board (CAB)

The CAB focuses on change management — reviewing and approving changes before they are deployed to production.

CAB vs ARB

Aspect	ARB	CAB
Focus	Design decisions	Deployment decisions
When	Before building	Before deploying
Question	”Is this the right solution?"	"Is this safe to deploy?”
Outcome	Architecture approval	Change approval
Participants	Architects, tech leads	Release managers, QA, ops

Change Classification

Change Type	Risk Level	Approval Process	Example
Standard	Low	Pre-approved, no CAB review	Field label change, report creation
Normal	Medium	CAB review required	New automation, integration change
Emergency	High/Critical	Expedited approval (post-implementation review)	Production bug fix, security patch
Major	High	Full CAB + ARB review	New cloud implementation, data migration

Change Management Flow

Every change to a Salesforce org — whether code, configuration, or data — follows a lifecycle from request to verification. This flow integrates the ARB and CAB roles.

flowchart TD
    A([Change Request<br/>Submitted]) --> B{Classify Change}

    B -->|Standard| C[Pre-Approved<br/>No CAB Review]
    B -->|Normal| D[CAB Review<br/>Required]
    B -->|Emergency| E[Expedited Approval<br/>CAB Chair Only]
    B -->|Major| F[Full ARB +<br/>CAB Review]

    C --> G[Assign to<br/>Developer/Admin]
    D --> H{CAB Approves?}
    E --> I[Implement Fix<br/>Post-Implementation<br/>Review Required]
    F --> J{ARB Approves<br/>Architecture?}

    J -->|Yes| H
    J -->|No| K[Revise Architecture<br/>Resubmit]
    H -->|Yes| G
    H -->|No| L[Return to<br/>Requestor]

    G --> M[Build & Test in<br/>Dev Environment]
    I --> M
    M --> N[Deploy to SIT<br/>Run Integration Tests]
    N --> O[Deploy to UAT<br/>Business Validation]
    O --> P{UAT Sign-Off?}

    P -->|Yes| Q[Deploy to Staging<br/>Smoke Tests]
    P -->|No| R[Fix Defects<br/>Retest]
    R --> M

    Q --> S[Deploy to<br/>Production]
    S --> T[Post-Deployment<br/>Verification]
    T --> U([Change Closed<br/>Logged in Register])

    style A fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style U fill:#2d6a4f,stroke:#1b4332,color:#fff
    style E fill:#e76f51,stroke:#c45a3f,color:#fff
    style K fill:#e76f51,stroke:#c45a3f,color:#fff
    style L fill:#e76f51,stroke:#c45a3f,color:#fff

Emergency Changes

Emergency changes bypass the standard CAB review process but are not exempt from governance. Every emergency change must have a post-implementation review within 48 hours. If emergencies become frequent, it signals a systemic problem with testing, architecture, or release planning that the CTA must address.

RACI Matrix

A RACI matrix clarifies who does what for key governance activities.

Salesforce Governance RACI

Activity	CTA/EA	Dev Lead	Admin Lead	PM	Business Owner
Architecture decisions	A, R	C	C	I	I
Code standards	A	R	I	I	-
Declarative standards	A	C	R	I	-
Change requests	C	R	R	A	R
Production deployments	C	R	R	A	I
Incident management	C	R	R	I	I
Vendor evaluation	A, R	C	C	C	R
Data governance	C	C	C	I	A, R
User provisioning	I	I	R	I	A
Release planning	C	R	R	A	C

R = Responsible (does the work), A = Accountable (final decision), C = Consulted, I = Informed

CTA Exam Signal

Including a RACI matrix (even a simplified one) in your CTA presentation shows the review board that you think about organizational structure, not just technology. This is a distinguishing factor between a Technical Architect and a Chief Technical Architect.

Salesforce Center of Excellence (CoE) Model

A CoE is the organizational structure that governs Salesforce across the enterprise.

CoE Models

flowchart TD
    subgraph Centralized["Centralized CoE"]
        direction TB
        C1[Central SF Team]
        C2[All Projects]
        C3[All Admins]
        C4[All Developers]
        C1 --> C2
        C1 --> C3
        C1 --> C4
    end

    subgraph Federated["Federated CoE"]
        direction TB
        F1[Central Standards Team]
        F2[BU 1 SF Team]
        F3[BU 2 SF Team]
        F4[BU 3 SF Team]
        F1 --> F2
        F1 --> F3
        F1 --> F4
    end

    subgraph Hybrid["Hybrid CoE"]
        direction TB
        H1[Central Architecture + Standards]
        H2[Central Shared Services]
        H3[BU 1 Delivery Team]
        H4[BU 2 Delivery Team]
        H1 --> H2
        H1 --> H3
        H1 --> H4
        H2 --> H3
        H2 --> H4
    end

Model	Strengths	Weaknesses	Best For
Centralized	Consistent standards, no duplication, strong governance	Bottleneck, slow response, disconnected from business	Small to medium orgs with one Salesforce instance
Federated	Business unit autonomy, fast delivery, local expertise	Inconsistent standards, duplication of effort, drift	Large enterprises with independent business units
Hybrid	Balanced control and agility, shared standards with local delivery	Complex to operate, requires strong leadership	Large enterprises needing consistency with business agility

CTA Recommendation Pattern

In most CTA scenarios, the Hybrid CoE is the right answer because it balances governance with delivery speed. Central team owns architecture, standards, and shared services. Business unit teams own delivery. The review board values this nuanced recommendation over a one-size-fits-all answer.

Governance Framework Overview

The governance framework is the structural backbone that connects strategic direction, architectural standards, change control, and operational delivery.

flowchart TD
    subgraph Strategic["Strategic Layer"]
        EXEC[Executive Sponsor<br/>Strategic Direction]
        COE[Center of Excellence<br/>Standards & Best Practices]
    end

    subgraph Architecture["Architecture Layer"]
        ARB_G[Architecture Review Board<br/>Design Decisions]
        ADR[Architecture Decision Records<br/>Decision Documentation]
        STANDARDS[Technical Standards<br/>Naming, Code, Security]
    end

    subgraph Change["Change Control Layer"]
        CAB_G[Change Advisory Board<br/>Deployment Approvals]
        CR[Change Register<br/>Tracking & Audit]
        RISK[Risk Register<br/>Risk Tracking]
    end

    subgraph Delivery["Delivery Layer"]
        TEAMS[Delivery Teams<br/>Build & Test]
        PIPELINE[CI/CD Pipeline<br/>Automated Checks]
        ENVS[Environment Strategy<br/>Dev to Prod]
    end

    EXEC --> COE
    COE --> ARB_G
    ARB_G --> ADR
    ARB_G --> STANDARDS
    COE --> CAB_G
    CAB_G --> CR
    CAB_G --> RISK
    STANDARDS --> TEAMS
    CAB_G --> PIPELINE
    PIPELINE --> ENVS

    style EXEC fill:#1a535c,stroke:#0d3b44,color:#fff
    style COE fill:#1a535c,stroke:#0d3b44,color:#fff
    style ARB_G fill:#2d6a4f,stroke:#1b4332,color:#fff
    style CAB_G fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style TEAMS fill:#f4a261,stroke:#d4823e,color:#000
    style PIPELINE fill:#f4a261,stroke:#d4823e,color:#000

Architecture Decision Records (ADRs)

ADRs document the rationale behind significant architectural decisions. They are lightweight but invaluable.

ADR Template

# ADR-{NUMBER}: {Title}

## Status
Proposed | Accepted | Deprecated | Superseded

## Context
What is the issue that we're seeing that is motivating this decision?

## Decision
What is the change that we're proposing and/or doing?

## Consequences
What becomes easier or more difficult to do because of this change?

## Alternatives Considered
What other options were evaluated and why were they rejected?

When to Write an ADR

Choosing between platform approaches (Flow vs Apex for a major automation)
Selecting an AppExchange package
Designing an integration pattern
Choosing a data model approach
Changing the development or deployment process
Adopting a new technology or tool

Standards and Policies

Technical Standards to Define

Standard Area	What to Define	Example
Naming conventions	Objects, fields, classes, flows	`Account_Territory_Assignment_Flow`, `AccountService.cls`
Code standards	Apex style guide, LWC patterns	Apex Enterprise Patterns, ESLint config
Automation standards	One flow per object, error handling	Master flow pattern, fault path template
Integration standards	Named Credentials, error handling	Circuit breaker pattern, retry policy
Security standards	FLS/CRUD enforcement, sharing model	Always check CRUD in Apex, no `without sharing`
Data standards	Required fields, picklist values	Data dictionary, picklist governance
Testing standards	Coverage targets, assertion rules	85% coverage, meaningful assertions

Policy Examples

Deployment Policy:

All production deployments require successful UAT sign-off
Deployment windows: Tuesdays and Thursdays, 6 PM - 10 PM (off-peak)
Emergency deployments require CAB chair approval
All deployments must include a rollback plan

Data Policy:

No production data in development sandboxes without masking
PII fields must be encrypted in transit and at rest
Data retention policies must be documented per object
Bulk data operations require ARB notification

Compliance Considerations

Regulatory Frameworks

Framework	Key Requirements for Salesforce	Affected Industries
GDPR	Right to be forgotten, data portability, consent management	Any org with EU data subjects
HIPAA	PHI encryption, access controls, audit logging. Salesforce offers a Business Associate Agreement (BAA) for Shield and Health Cloud — required before storing PHI.	Healthcare, health insurance
SOX	Financial controls, audit trails, segregation of duties	Public companies
PCI-DSS	Cardholder data protection, access controls	Payment processing
CCPA	Consumer data rights, opt-out mechanisms. Implement via Privacy Center for opt-out/do-not-sell workflows, Data Subject Access Requests (DSARs) for consumer data requests, and automated data deletion workflows. Similar to GDPR but opt-out (not opt-in) model.	Any org with CA consumers
FedRAMP	Government cloud requirements	Government contractors

Compliance Implementation in Salesforce

Requirement	Salesforce Solution
Data encryption	Shield Platform Encryption
Audit logging	Shield Event Monitoring, Field Audit Trail
Access controls	Profiles, Permission Sets, sharing rules
Data retention	Archival strategy, Big Objects
Right to be forgotten	Data deletion processes, anonymization
Segregation of duties	Profile restrictions, approval processes
Compliance reporting	Event Monitoring, custom audit objects

Compliance is Non-Negotiable

In a CTA scenario, if the customer is in a regulated industry, compliance requirements override all other architectural preferences. Do not recommend a technically superior solution that violates compliance. Document compliance requirements as architectural constraints and design within them.

Data Governance

Data Governance Framework

Component	Description	Owner
Data Dictionary	Definitive list of all objects, fields, and their business meaning	Data Architect
Data Quality Rules	Validation rules, duplicate rules, data cleansing processes	Admin Lead
Data Ownership	Which business unit owns each data domain	Business Owners
Data Retention	How long data is kept and when it is archived or deleted	Compliance + Business
Data Access	Who can see, edit, and delete each data domain	Security Architect
Data Lineage	Where data comes from and where it flows	Integration Architect

Metadata Governance

Track all metadata changes in source control (not just code — Flows, objects, fields too)
Review metadata changes before deployment (declarative changes need review too)
Monitor metadata growth — track custom object count, field count, automation count
Clean up unused metadata regularly — inactive flows, unused fields, orphaned classes

CI/CD & Deployment — How governance gates integrate with deployment pipelines
Environment Strategy — Environment access governance
Risk Management — Governance as risk mitigation
Testing Strategy — Testing governance and quality gates
Decision Guides — Governance structure decision flowcharts
Security — Security governance and compliance
Best Practices — Solution architecture governance

Sources

Salesforce Architects: Governance Framework
Salesforce Well-Architected: Trusted Principle
TOGAF: Architecture Governance
Michael Keeling: Design It! — Architecture Decision Records
Salesforce Help: Shield Platform Encryption
Salesforce Help: Event Monitoring
Salesforce Help: Introduction to Governance Whitepaper
Salesforce Architects: Well-Architected — Intentional
CTA Study Groups: Community governance patterns for enterprise Salesforce