--- schema_version: "1" id: fd936a35ce4a27b17ffd76bf7a6931d59c1e1b7123a814555857b62f82045a3c title: Cost Governance and Decision-Making - Patterns collection: architect version: current locale: en-us portal_url: https://docs.salesforce.com/architect/current/en-us/well-architected/guides/resource-and-cost-optimization-governance-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/well-architected/guide/resource-and-cost-optimization-governance-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 001d9233ebb2d65fe62aed28e04085ec5be16f3702507730faae00618e56bc5b products: - Well-Architected Framework - Architect Site Content Repo --- # Cost Governance and Decision-Making - Patterns Learn more about Well-Architected [Resource and Cost Optimization](/docs/architect/well-architected/guide/resource-and-cost-optimization.html) → [Cost Monitoring and Governance](/docs/architect/well-architected/guide/resource-and-cost-optimization.html#cost-monitoring-and-governance) ## Cost Monitoring and Visibility **Patterns** | Where to look | What good looks like | | --- | --- | | **Setup** → Company Settings → System Overview
**Reports & Dashboards** → Cost Utilization Folder | ✅ **Pattern**: Create executive dashboard showing $2.1M annual Salesforce investment distributed across 1,200 licenses (68% active weekly), 450 GB storage (72% capacity), and 15 sandboxes (11 actively used)
✅ Dashboard reveals $400K optimization opportunity in inactive licenses and unused sandboxes through operational metrics | | **Reports & Dashboards** → Investment Dashboard
**Setup** → Company Information | ✅ **Pattern**: Investment dashboards show spending by business unit or cost center, sandbox and environment costs by development team, add-on product costs with utilization metrics
✅ Project spending based on current growth trends enabling budget accountability and allocation discussions | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | **Accounting System** → Invoice Records Only | ⚠️ **Anti-Pattern**: Finance team has invoice visibility showing total spending but no operational metrics revealing utilization patterns or optimization opportunities
⚠️ Cannot identify inactive licenses, unused sandboxes, or capacity waste without operational dashboards | ## Budget Controls and Alert **Patterns** | Where to look | What good looks like | | --- | --- | | **Reports & Dashboards** → License Budget Alerts
**Setup** → License Allocations | ✅ **Pattern**: License budgets establish allocation targets by department with alerts when approaching capacity
✅ Prevent uncontrolled provisioning creating budget overruns discovered only at renewal time through proactive monitoring | | **Setup** → Storage Usage → Alert Rules
**Flow** → Storage Warning Automation | ✅ **Pattern**: Automated alert triggers at 70% storage utilization providing 4-month lead time to implement archival strategy before hitting limits
✅ Prevents emergency data deletion or expensive overage charges through proactive notification with adequate response time | | **System Overview** → API Usage Alerts
**Event Monitoring** → API Threshold Warnings | ✅ **Pattern**: API budgets track consumption against limits with alerts at example utilization thresholds such as 70% and 85%
✅ Enable proactive optimization rather than reactive emergency responses after limits cause integration failures or user disruption | | **Setup** → Sandbox Management → Budget Controls
**Flow** → Sandbox Request Approval | ✅ **Pattern**: Sandbox budgets control environment proliferation through allocation limits and approval processes for additional environments
✅ Prevent teams from creating unlimited temporary environments that transition to permanent status without justification | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | **No Budget Controls** → Uncontrolled Spending | ⚠️ **Anti-Pattern**: No license budgets or approval workflows allowing unlimited provisioning across departments without visibility to spending patterns
⚠️ Budget overruns discovered at renewal when aggregate spending exceeds planned investment by 30-40% due to uncontrolled growth | | **No Storage Alerts** → Reactive Overages | ⚠️ **Anti-Pattern**: Storage overage discovered during renewal negotiation requiring immediate purchase at premium pricing without time for archival evaluation
⚠️ Missing advance warning that would enable archival implementation before overages occur, resulting in 2-3x higher costs | ## Cost Allocation and Chargeback **Patterns** | Where to look | What good looks like | | --- | --- | | **Reports & Dashboards** → Showback Report
**Reports** → Cost by Business Unit | ✅ **Pattern**: Quarterly showback report shows Sales Cloud consuming 45% of license investment, Service Cloud 30%, and Operations 25%
✅ Enables executive discussion about whether investment distribution aligns with business value priorities and strategic focus areas | | **Financial System** → Chargeback Allocation
**Reports** → Department Cost Allocation | ✅ **Pattern**: Allocation rules distribute costs appropriately: license costs by user department assignment, sandbox costs by owning development team
✅ Integration costs allocated by business process consuming integration services, development costs by requesting project funding source | | **Reports & Dashboards** → Sandbox Cost Report
**Setup** → Sandbox Usage by Team | ✅ **Pattern**: Sandbox and environment costs allocated by owning development team creating direct accountability for environment management
✅ Teams see their sandbox investment enabling informed decisions about environment requests and lifecycle management | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | **IT Budget Only** → No Business Unit Visibility | ⚠️ **Anti-Pattern**: All Salesforce costs allocated to IT budget without business unit visibility
⚠️ Business stakeholders treat platform as "free" and make requests without cost awareness or investment prioritization discussions | | **No Usage Attribution** → Cannot Optimize | ⚠️ **Anti-Pattern**: Total spending visible but no attribution to business units, projects, or teams making optimization decisions impossible
⚠️ Cannot identify which investments deliver value and which consume budget without proportional returns | ## FinOps and Cost-Aware Culture **Patterns** | Where to look | What good looks like | | --- | --- | | **Collaboration** → FinOps Team
**Meetings** → Monthly Cost Review | ✅ **Pattern**: Cross-functional collaboration between finance, architecture, and business stakeholders ensures cost decisions consider business value alongside spending impact
✅ FinOps brings finance expertise to architecture discussions and technical understanding to budget planning creating balanced decisions | | **Calendar** → Optimization Reviews
**Process** → Regular Cadence | ✅ **Pattern**: Continuous optimization cadence with monthly anomaly review, quarterly utilization audit, and annual comprehensive TCO assessment
✅ Regular review cycles prevent cost drift and validate that spending growth corresponds to business value growth through systematic analysis | | **Tools** → License Cost Calculator
**Architecture** → TCO Models | ✅ **Pattern**: FinOps team provides architects with license cost calculator showing TCO implications of different license type selections
✅ Enables cost-aware design decisions during architecture phase rather than discovering costs after deployment when changes are expensive | | **Training** → Cost Awareness Program
**Documentation** → Cost Impact Guidelines | ✅ **Pattern**: Cost awareness education ensures teams understand how architectural decisions affect total cost of ownership
✅ Architects design better solutions balancing capability and investment; developers write more efficient automation respecting governor limits and API consumption | | **Automation** → Cost Monitoring Scripts
**Dashboards** → Auto-Generated Reports | ✅ **Pattern**: Automated monitoring of utilization, optimization opportunities, and spending reports reduces manual effort
✅ Scales with organizational complexity without linear headcount growth, enabling cost awareness across growing platform footprint | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | **Annual Only** → No Feedback Loop | ⚠️ **Anti-Pattern**: Cost visibility limited to annual renewal discussions providing no feedback loop
⚠️ Architecture teams cannot understand or optimize spending patterns during design phase when changes are least expensive | | **Siloed Decisions** → No Cross-Functional Input | ⚠️ **Anti-Pattern**: Architecture decisions made without finance input, budget decisions made without technical understanding
⚠️ Results in solutions that exceed budget without business justification or budget cuts that eliminate capabilities delivering critical value | | **No Cost Education** → Uninformed Decisions | ⚠️ **Anti-Pattern**: Teams make architectural decisions without understanding cost implications because no training or visibility exists
⚠️ Accumulates waste through thousands of micro-decisions that individually seem minor but compound to significant spending | ## Architecture Review Cost Integration **Patterns** | Where to look | What good looks like | | --- | --- | | **Documentation** → Architecture Decision Record
**Process** → ADR Template | ✅ **Pattern**: Architecture Decision Record for customer portal includes license analysis: 10,000 external users with Customer Community Plus licenses ($6 per user monthly = $720K annually)
✅ Compares versus custom web application with API integration ($250K initial + $50K annual maintenance), recommending custom application with 2-year payback | | **Governance** → Architecture Review Board
**Process** → Cost Review Criteria | ✅ **Pattern**: Architecture Review Board includes cost perspective alongside functional and non-functional requirements producing better-aligned investment decisions
✅ Cost is one input to architectural decisions ensuring organizations invest appropriately in capabilities that matter while avoiding waste | | **Documentation** → ADR Cost Section
**Templates** → TCO Projection | ✅ **Pattern**: Include cost impact assessment in Architecture Decision Records documenting major design choices
✅ Require TCO projection for solutions exceeding defined investment thresholds ($100K or organizational policy) with documented assumptions | | **Process** → License Impact Review
**Architecture** → Premium Feature Analysis | ✅ **Pattern**: Evaluate license implications during solution design determining whether design requires premium licenses or add-ons
✅ Assess integration cost implications before committing to patterns affecting API consumption or middleware licensing requirements | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | **No Cost Consideration** → Emergency Redesign | ⚠️ **Anti-Pattern**: Architecture designed without cost consideration, discovering at implementation planning that proposed approach requires $720K annual investment
⚠️ Causes emergency redesign under time pressure with inferior outcomes compared to cost-aware design from start | | **Post-Design Cost Discovery** → Wasted Effort | ⚠️ **Anti-Pattern**: Architecture complete before cost analysis revealing approach exceeds budget by 3x
⚠️ Wasted design effort and delayed delivery while team redesigns within budget constraints that were known from project start | ## Build vs Buy Decision Framework **Patterns** | Where to look | What good looks like | | --- | --- | | **AppExchange** → Solution Evaluation
**Analysis** → TCO Comparison | ✅ **Pattern**: Document generation solution evaluation: AppExchange option at $15 per user monthly ($18K annually for 100 users) versus custom development at $80K initial build + $15K annual maintenance
✅ AppExchange breaks even in 5 years with faster deployment and lower risk for commodity capability | | **AppExchange** → Strategic vs Commodity
**Architecture** → Capability Classification | ✅ **Pattern**: Commodity capabilities (document generation, e-signature, address enrichment) purchased from AppExchange where solutions are mature with strong reviews
✅ Proprietary pricing algorithm providing competitive advantage built custom with full control over roadmap and differentiation | | **Spreadsheet** → 3-5 Year TCO Model
**Analysis** → Cost Projection | ✅ **Pattern**: Build TCO models projecting 3-5 year total costs revealing complete investment picture beyond initial expenses
✅ AppExchange carries compounding annual subscription but includes maintenance; custom requires one-time development plus 15-20% annual maintenance | | **Integration Analysis** → Custom vs Platform
**TCO** → Integration Comparison | ✅ **Pattern**: Custom integration development: $150K initial build + $30K annual maintenance + team learning curve versus MuleSoft license: $75K annual + faster integration delivery
✅ MuleSoft provides reusable patterns across all integrations reducing per-integration cost as portfolio grows | | **Documentation** → Build vs Buy ADR
**Process** → Evaluation Framework | ✅ **Pattern**: Architecture Decision Record documents build vs buy evaluation with scoring matrix weighting strategic value, TCO, timeline, capability, and exit costs
✅ Creates audit trail for future reassessment when requirements evolve or vendor landscape changes | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | **Always Build** → Wasted Development | ⚠️ **Anti-Pattern**: Building custom document generation solution because "we have developers available" without modeling 5-year TCO
⚠️ AppExchange delivers better value for commodity capability; custom development wastes capacity on undifferentiated functionality | | **Always Buy** → Missing Differentiation | ⚠️ **Anti-Pattern**: Purchasing all capabilities from AppExchange including strategic differentiators because "faster to deploy"
⚠️ Competitors using same AppExchange solutions gain same capabilities eliminating competitive advantage from platform investment | | **Single Meeting Decision** → No Analysis | ⚠️ **Anti-Pattern**: Build vs buy decision made in single meeting based on initial cost comparison without systematic evaluation or documentation
⚠️ Missing strategic value assessment, TCO projection, timeline requirements, capability evaluation, and exit cost analysis | | **Incomplete Cost Model** → Hidden Costs | ⚠️ **Anti-Pattern**: Building custom integration because "we already have developers" without modeling 5-year maintenance burden
⚠️ Maintenance typically consumes 15-20% of initial development cost annually plus platform compatibility effort not visible in initial decision | ## Decision Framework Systematic Evaluation **Patterns** | Where to look | What good looks like | | --- | --- | | **Process** → Strategic Value Assessment
**Analysis** → Differentiation Matrix | ✅ **Pattern**: Systematize build vs buy decisions through consistent evaluation preventing ad-hoc decisions based on incomplete analysis
✅ Assess strategic value first: core competitive differentiators warrant custom investment; commodity capabilities favor purchasing proven solutions at lower total cost | | **AppExchange** → Solution Maturity Review
**Analysis** → Vendor Stability Check | ✅ **Pattern**: Evaluate available AppExchange options reviewing solution maturity, customer ratings, ISV stability, feature alignment, and pricing models
✅ Immature solutions with few customers carry higher risk; prioritize proven solutions with strong reviews and stable vendor financials | | **Spreadsheet** → Sensitivity Analysis
**TCO** → Assumption Documentation | ✅ **Pattern**: Model 3-5 year TCO for viable options including all cost categories: licenses/subscriptions, implementation effort, maintenance burden, enhancement development, platform compatibility
✅ Use spreadsheet enabling sensitivity analysis on assumptions showing how outcome changes if growth rates or utilization differs from projections | | **Timeline** → Market Timing Analysis
**Strategy** → Time-to-Value Assessment | ✅ **Pattern**: Assess timeline requirements showing custom development requires months to years depending on complexity while AppExchange deploys in weeks
✅ Market timing may drive buy decision despite higher long-term cost when competitive pressure or business opportunity requires immediate capability | | **Analysis** → Exit Cost Evaluation
**Risk** → Vendor Lock-In Assessment | ✅ **Pattern**: Evaluate exit costs and vendor concentration risk asking how difficult is switching if chosen option proves inadequate
✅ Consider vendor acquisition or discontinuation risk and solution portability if requirements change, preferring lower exit costs providing strategic flexibility | | **Capability** → Honest Assessment
**Team** → Maintenance Capacity Review | ✅ **Pattern**: Consider organizational capability honestly evaluating whether custom solutions can be maintained long-term
✅ Custom solutions require ongoing internal expertise for maintenance and evolution; organizations lacking this capability should purchase despite potentially higher cost | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | **No Framework** → Inconsistent Decisions | ⚠️ **Anti-Pattern**: Build vs buy decisions vary by project team preferences without consistent evaluation criteria
⚠️ Some teams always build, others always buy, creating architectural inconsistency and suboptimal total investment across platform | | **Build Everything** → Undifferentiated Effort | ⚠️ **Anti-Pattern**: Building everything custom because "we want control" without distinguishing between commodity capabilities and strategic differentiators
⚠️ Wastes development capacity on undifferentiated functionality that mature AppExchange solutions provide at lower total cost | | **Initial Cost Only** → Incomplete Analysis | ⚠️ **Anti-Pattern**: Decision based solely on initial cost comparison: "AppExchange is $20K, custom build is $15K, so we'll build"
⚠️ Missing 3-5 year TCO showing custom solution costs $15K initial + $3K annual maintenance while AppExchange includes all maintenance in subscription | | **Optimistic Capability** → Failed Maintenance | ⚠️ **Anti-Pattern**: Choosing custom development assuming team can maintain solution despite no current capacity or expertise
⚠️ Technical debt accumulates as maintenance is deferred; solution eventually becomes unmaintainable requiring expensive replacement |