The Salesforce Platform Governance Method is designed to help organizations meet their strategic and tactical goals for utilizing the Salesforce platform.
The Salesforce Platform Governance Method can support the full spectrum of development activity on the Salesforce platform and is suitable for everything from the needs of your company’s development on the platform through to the needs of a service integrator (SI) that has large teams of developers.
The Salesforce Platform Governance Method provides an organization assurance that all development activity taking place on the Salesforce platform is done in a consistent manner and to a consistent set of standards. This is not to say every developer will produce exactly the same solution given a common set of requirements. It does, however, mean that there is consistency in the structure and usage of the platform so that the same “rules” apply to anyone using the platform to deliver business value.
This goal is important because over time, without a clear set of standards, developers will just follow their own rules. The more developers that create applications that way, the higher the degree of technical debt that will build up, to the point where an application may be deployed and no one really has a clear understanding of what it does and why.
One of the main reasons companies engage Salesforce’s advisory services, and specifically engage a program architect, is to unpick the mess they have allowed their Salesforce platform to become.
Overview
The Salesforce Platform Governance Method is split into two parts: the method, which utilizes nine phases to provide coverage to govern the Salesforce platform; and the resource base, which provides best practices and lessons learned so as to provide an initial set of standards to govern by.
The Method
The Salesforce Platform Governance Method Phases
Phase | Description |
|---|---|
A – Application Architecture | The objective of Phase A is to ensure that this evolution of the application has adhered to the technical standards and policies defined for the Salesforce platform. The areas that will be assessed are as follows: • General Architecture • Localization / Global Deployments • Workflow and Process • Formulas • Files and Social |
B – Data Architecture & Management | The objective of Phase B is to ensure that this evolution of the application has adhered to the technical standards and policies defined for the Salesforce platform. The following areas will be assessed during this phase: • Design and Optimization • Data Movement |
C – Identity & Access Management | The objective of Phase C is to ensure that this evolution of the application has adhered to the technical standards and policies defined for the Salesforce platform. The following areas will be assessed during this phase: • Single Sign-On • Identity Management |
D – Sharing & Visibility | The objective of Phase D is to ensure that this evolution of the application has adhered to the technical standards and policies defined for the Salesforce platform. The areas that will be assessed during this phase are as follows: • Declarative Sharing • Programmatic Sharing • Performance • Data Security |
E – Integration | The objective of Phase E is to ensure that this evolution of the application has adhered to the technical standards and policies defined for the Salesforce platform. The areas that will be assessed during this phase are as follows: • Technologies and Overall Integration Strategy • Integration Solution Tools • Security |
F – Apex, Visualforce & Lightning | The objective of Phase F is to ensure that this evolution of the application has adhered to the technical standards and policies defined for the Salesforce platform. The following areas will be assessed during this phase: • Design and Functionality • Performance and Scalability • Maintainability and Reuse |
G – Communities | The objective of Phase G is to ensure that this evolution of the application has adhered to the technical standards and policies defined for the Salesforce platform. The following areas will be assessed during this phase: • Design • Identity Management |
H – Mobile Solutions Architecture | The objective of Phase H is to ensure that this evolution of the application has adhered to the technical standards and policies defined for the Salesforce platform. The areas that will be assessed during this phase are as follows: • Mobile Strategy and Design • Mobile Security |
I – Development Lifecycle & Deployment | The objective of Phase I is to ensure that this evolution of the application has adhered to the technical standards and policies defined for the Salesforce platform. The following areas will be assessed during this phase: • Development Lifecycle • Deployment Techniques and Considerations |
These phases relate almost exactly to the path taken by a Salesforce certified technical architect (CTA), providing synergy between the educational path to understanding the Salesforce platform and the ability to govern it.
Phase structure
Phase Structure Definitions
Method Component | Description |
|---|---|
A – Objectives | A specific result that the phase aims to achieve. In general, objectives are more specific and easier to measure than goals. Objectives are basic tools that underlie all planning and strategic activities. |
B – Approach | A recommendation as to how the phase will be implemented and/or executed |
C – Inputs | The artifacts that must be available before the phase can commence. Artifacts are key inputs into the phase steps. |
D – Steps | The steps and sub-steps that should be completed for each phase to determine complete coverage of a project/product from a governance perspective |
E – Outputs | The artifacts that will be produced by the phase and created during the steps |
Although the phases clearly state what needs to be done to govern a solution on the Salesforce platform, it is the resource base that can be used as a starting point for the standards that governance should use to assess your projects’ applications.
The Resource Base
The resource base is a set of resources—best practices, tooling ideas, guidelines, templates, checklists, and other detailed documents—that support each of the Salesforce Platform Governance Method phases. These resources can be used as is, tailored, or replaced to meet your requirements. The resources will underpin the Salesforce Platform Governance Method; therefore, it is critical that they work within the phases and support the inputs and outputs as detailed in the method.
Key Points
It may be used in conjunction with the set of deliverables of another framework, where these have been deemed more appropriate for a specific organization.
Some of the phases may be deemed as not required—for example, the mobile solutions architecture phase—if no requirement exists within the organization.
The order of the phases is intentional, but not fixed. It may be that for certain organizations the order of the phases may change if early warnings are required for specific areas; for example, integration may be a key consideration that requires early assessment before any other phase is considered.
Basic Structure
Salesforce Platform Governance Method cycle
Although your organization is at liberty to adjust the phases, there is a logical order to them. Each phase takes a more comprehensive and deeper technical view of your project’s application.
Given that there is an order to the phases, it is envisaged that each phase provides the “gate” via which to proceed to the next phase. However, this should be a consideration during implementation of the Salesforce Platform Governance Method as you may prefer to assess the application in its entirety rather than phase by phase. The issue with not following the phased approach is that some phases may become unnecessary if an application fails prior phases (i.e., the phase will fail as a result of a prior failure).
Salesforce Platform Governance Method cycle, expanded
The phases of the cycle are described in detail within the subsequent chapters. Note that outputs are generated throughout the process of using the method, and that the output in an early phase may be modified in a later phase; for example, the Identity & Access Management phase may have a bearing on the Communities phase.
Method Adaption
The Salesforce Platform Governance Method is a generic method for governing development on the Salesforce platform, and is designed to deal with most application and organizational requirements that use the Salesforce platform to either develop applications from scratch or enhance existing configurations or SaaS solutions (such as simply adding fields to SalesCloud or ServiceCloud objects).
Architecture Governance
The method, whether adapted by your organization or used as documented here, is a key artifact to be managed in the same manner as any other architecture artifacts in the Enterprise Continuum. The Architecture Board should be satisfied that the method is being applied correctly across all phases and iterations of application development. Compliance with the method is fundamental to the governance of the architecture, ensuring that all considerations are made and all required deliverables are produced.
Process Management
The management of all architecture artifacts, governance, and related processes should be supported by a managed environment. Typically, this would be based on one or more repositories supporting versioned object and process control and status.
The tailored method should be managed as with any other architecture artifact. The method will no doubt undergo a number of changes as refinement of the phases occurs. Additionally, the resource base is a key area that requires the artifacts that are used to implement the method be managed so that they are kept in line with the method itself.
Beyond version control, process management extends to the implementation of the process to support the method. Ideally, this process will control the governance gates that at a minimum control whether an application or project has passed or failed its governance.
Scoping the Application Governance Cycle
There are many reasons to want to limit the scope of the Salesforce Application Governance Method, most of which come down to the availability of people, financing, and other resources. The scope chosen for the architecture activity is normally directly dependent on available resources, and the final analysis is usually a question of feasibility.
Although the method’s implementation is envisioned to be mainly software/tooling–driven with a goal of full automation, implementation of the full method may not be relevant if the organization has no appetite for such things, or if the amount of governance required is minimal based on simplistic applications.
Additionally, the target community should be considered when scoping the cycle. Citizen developers will more than likely develop less-sophisticated applications than a service integrator, whether due to level of expertise or to restrictions imposed on citizen developers.
Summary
The Salesforce Platform Governance Method defines a recommended sequence for the various phases and steps involved in governing the development of an application, but it cannot recommend a scope. This is determined by the organization or project.
Your governance team should review the method and determine what phases are relevant for your specific requirements and tailor it from there. It is, however, imagined that an organization of significant size wishing to encourage in-house development as well as large-scale project development undertaken by service integrators will almost certainly implement this method as-is, with a focus on tooling and processes.