Join us and learn about it. The governance dilemma for Salesforce projects makes Salesforce special compared to other platforms. Why have many Salesforce projects struggled with quality despite governance? The CTA’s role in defining and implementing a Salesforce governance model and Governance at scale.
Throughout my career, I have seen many examples of how software governance, or lack of it can negatively impact a project’s success.
The impact can range from poor user adoption to sub-optimal solution performance. This could lead to more unfortunate events like data leaks or complete meltdowns.
Examples of less Governance model in Salesforce
- You might have heard clients complaining about ending up with 80% of their functionalities custom-developed instead of the promised 20%.
- Occasionally, that leads to a hyper allergy to anything related to custom-developed features. Even when unavoidable, complicated feature request processes might be introduced to deter teams from custom-developed solutions.
- You might have encountered a situation where your team proudly developed the same feature twice. Or thrice. Or build something that was rendered obsolete in the next Salesforce release.
- Or you might have had the experience of inheriting an under-performing solution that has no available documentation anywhere that can describe how they were developed (or even why)
- Governor limits anyone?
- Have you heard this statement before? We cannot introduce any new features because every time we introduce and test a thing, something else falls apart.
Market confusion
For years, Salesforce has promoted the concept of a Center of Excellence (CoE) as part of the overall governance body. However, different interpretations can lead to different implementations and expectations.
- The terms used can vary. Some companies call it the “Center of Excellence,” “C4E”, “Center of Expertise,” or “Network of Experts.”
- “Design Authority“ or “Platform Authority“ are also sometimes used. This creates more confusion.
- This is common, particularly when uncertain about the entity’s purpose. Is it there to drive transformation, or is it a best practice center?
- The CoE is not a new term. It can be mistakenly associated with legacy thinking and a slow business and technical change pace. This could lead to using other terms such as “Network of Excellence,” “Center of Innovation,” … etc.
- The different interpretations can lead to different implementations and expectations. Which would usually lead to frustration when their targets are not met
Introducing a process to validate the design of key user stories should not be underestimated. This is actually where most things can go wrong.
Difference between a Salesforce CoE and a Design Authority(DA)
What does a Design Authority look like
For a Design authority to be effective, it requires;
- Executive sponsorship
- Both technical and business expertise
- Members are to be held accountable for their respective organizations.
- Credibility and influence within the enterprise
An illustrative structure of a Design Authority
What does the Design Authority do at the different touchpoints?
The Design Authority’s expected responsibilities
What it does
- Meet with a regular cadence (e.g., weekly)
- Single point of contact to have the full overview of all application changes
- Advise on and review solution blueprints / high-level designs and provide appropriate feedback to improve designs if necessary.
- Sanity check of effort as needed for more complex designs
- Establish targets for re-use of components and design patterns
- Support resolution of architectural issues raised by implementation projects
What it does NOT do
- Provide a guarantee that what was designed is what gets delivered
- Re-write solutions or design specifications
- Review every single line of a document for spelling or grammar corrections
- Perform detailed reviews on all code written
- Estimation oversight of all work entering the pipe
Design Authority Benefits
Let see the benefits of DA in the Governance model in Salesforce.
- A good level of standardization in the design process. If you work for an enterprise with multiple external consultancies, you will notice that they usually follow different approaches. Focused more on delivering a particular project rather than the overall vision of the more extensive program. This is particularly relevant considering the high level of attrition in the Salesforce market. A Design Authority could look across the design work, make sensible join-up suggestions, and/or recommend a consistent design process/taxonomy.
- The DA provides a community/forum that enables team alignment on a deeper level. The people who know exactly how each part of the solution works will be sitting around the same table. Sharing thoughts, challenging each other, and reaching up to conclusions without the need for further alignments. This is a much deeper level of team alignment than what you could ever get in activities such as release/PI planning.
- It provides a perfect process to continuously develop, monitor, and track the design of the overall solution throughout the project. Not just in a short blueprinting/design/pre-game phase, which could eventually run out of date and fail to respond to context changes. An effective Design Authority could keep tabs on progress and intervene as needed.
- The DA activities eventually create a very valuable artifact. The design decision log. Which contains all the “why” and “how” relevant to all key decisions taken in this project and who participated in them.
- A perfect ground to develop talents. Allowing them to get involved in creating, challenging, and defending a solution. This is a daily practice for what architects are expected to do as CTAs. All parties would learn more by engaging in these activities.
The best way to prepare for the CTA review board is by practicing a mini-review board every week. The DA is a win-win process for everyone. The enterprise (who gets a better quality deliverable), the delivery team (by avoiding challenges and issues while delivering the project), and potential CTAs (as they practice a part of the CTA review board in their day-to-day job)
How to implement a Design Authority (DA)?
- Start with an executive sponsor or champion. A structure such as the DA needs a senior executive sponsor who can support the DA members and coach them on how to be effective within the enterprise.
- Ensure that all stakeholders are aligned with the definition of an “effective DA”
- Create and document the process. The DA should have a level of formalism, and you should have materials that can explain to people new to the DA how it works and how they can engage with it successfully.
- Start small (e.g., an “Acorn”). Then, allow the entity to grow and mature with time (e.g., an Oak Tree). Evolve the DA as it gains credibility and influence. During the evolution, keep updating and adjusting the process and rules.
- Avoid the negative assumption that the DA would turn into a bottleneck. People think they will get hundreds of user stories to review and approve weekly. On one side, this is very exaggerated. On the other, you can always control the criteria defining what is a DA-relevant user story.
- Socialize the concept that these invested hours will prevent many more wasted hours spent on fixing things that could have been spotted initially.
- Keep the number of participants in the core team small (workable number). But ensure you can extend the team whenever needed to cover complex and broader organizational challenges.
Summary
Thanks, Tameem Bahri, for a great session on the “Governance model in Salesforce” in Apex hours.
