Does your Salesforce environment have integrations with other systems in your organization? Do you use custom VisualForce Pages or Lightning Components? How much Apex are you using in Triggers and Classes? Do you have multiple development teams? An Architecture Review Board (ARB) is a great way to ensure that the customizations in your Salesforce organization deliver valued functionality, while ensuring these customizations do not conflict with business vision or technical strategy set for your organization. An ARB is also a central meeting point for disparate workstreams to align on direction, collaborate, and ensure there are not conflicting or overlapping features. Without an ARB, it can be challenging to ensure utilization of common design patterns and development standards, and you are likely to accumulate technical debt. In short, an ARB can be an effective way to give visibility to features being implemented in your organization.
However, an ARB in practice can be difficult to execute. Here are several common issues I have seen:
- ARB becomes a “rubber stamp” approval due to backlog of items.
- ARB becomes contentious because IT and the business have conflicting goals.
- ARB review backlog means recommendations made are too late in the development cycle to be implemented. An increase in technical debt usually follows (and is rarely repaid).
- Enforcement issues — development teams realize the ARB does not know there is an item to review unless they bring it up.
Below are a few items that an ARB can implement to overcome the challenges above:
An ARB needs to define and publish guiding principles and development standards to help development teams understand what types of things require and do not require ARB approval. This differs by organization, and should be continually reviewed to adapt to the changing needs of the organization. For instance, an ARB might initially require all non-Standard UI (VF/Lightning Components) be brought for review. That same org building a new “pixel perfect” community might update standards to allow any Community UI using SLDS, Bootstrap, and Slickgrid. It is common that an ARB is interested in reviewing integrations, anything that will touch an object with large data volumes, any fragile/complex/legacy code, and any mission critical business processes.
An ARB should also strive to automate the extraction of items that need to be reviewed (e.g., VF Pages, Apex Classes, Apex Triggers, Validation Rules). Source control is a good place to identify new/changed files. I have also used the Salesforce tooling and metadata API to extract new and changed items via UPSERT into a Metadata Artifact custom object. However, the number of items in this extract is likely too large to review individually. I created an Artifact Group custom object for this purpose. Your ARB review will focus on Artifact Groups, so you can talk about a customization that might have 4 VF Pages, 14 Apex Classes, and 2 Triggers in one shot. To further minimize the items for review, the Artifact Group can implement an “Ignore Until” approval date. Once set, your process that UPSERTS changes to Metadata Artifacts can ignore items that are approved and within the “Ignore Until” date. Other items are flagged for review by the ARB. (We’ll discuss how to “build a customization watchdog to guard your Salesforce Org” in an upcoming post.)
An ARB should include a minimum number of people that have the authority to make decisions. Members of Business and IT should be represented, as it is difficult to make a decision on a customization without assessing impact to the business. If you find ARB membership exceeds 6-8 people, consider whether you can create separate review boards (regional or by business unit) to review items that do not impact other regions/units and an overarching ARB to handle the interconnects. The different ARBs should meet regularly to determine guiding principles and development standards for reviews going forward.
It is important for specific decisions made by an ARB to be translated into guiding principles, so that development teams in the future understand what types of things will and will not be approved by the ARB. It is also paramount for the ARB to not set unwanted precedent. If the ARB needs to make a concession to allow a critical feature, the context/reasons for the exception must be communicated, along with any conditions set for the approval. For instance, if a point-to-point integration is approved now because there is no middleware available, this should be approved as “technical debt” that will need to be modified once the organization completes the middleware evaluation and procurement cycle.
In summary, an effective ARB:
- Publishes and regularly modifies guiding principles and development standards for development teams to reference.
- Uses automation to ensure the ARB process is not subverted.
- Groups and filters items to ensure the volume of items to review is not overwhelming.
- Is minimally staffed with appropriate members in the business and IT.
Good luck with your ARB, and stay tuned for more on this topic coming soon!