In our first installment, we covered "The power of the Salesforce platform" and the lack of governance contributing to technical debt. In this second installment, we will cover the topic of Salesforce’s Maturing and expanding cloud footprint in the enterprise, and it's contribution to accruing technical debt.
Since its founding in 1999, Salesforce has north of 150k customers, and some of its more mature Salesforce customer orgs - those that have not yet undergone rearchitecting, refactoring and prudent governance - are experiencing technical debt challenges, undermining performance, usability, and agility.
Salesforce's growing number of product clouds - including Sales Cloud, Marketing Cloud, Commerce Cloud, Service Cloud, Experience Cloud, Analytics Cloud, and its newest, Data Cloud - introduce both business value and, unless they are effectively managed, added complexity.
With increasingly complex multi-cloud, multi-platform, and multi-app enterprises, managing technical debt is crucial to balance the need for speed with the risk of automating the right things and ensuring optimal performance. Managing wall-to-wall business automation across multiple functions and platforms and deciding which tech stack and app to build on requires decisions based on where the best short, medium, and long-term business value is - and done so at a level above each dev team, which has its point of view. This process is where a well-conceived and managed Digital Operating Model (DOM) comes in, defining the governance structure design and which app or tech stack a given capability should reside.
One virtual organizational approach and construct for managing governance is implementing an Agile Product Board (APB), an organizational overlay to existing product teams. It brings together senior representatives from product management, dev management from multiple platforms, and product teams to review its portfolio. The APB decides where a given function should reside based on business and enterprise architecture considerations, handles cross-platform, app, and team decisions and escalations, and clears barriers to moving fast.
The evaluation criteria and the process for engaging should be established according to a RACI and reviewed and blessed by an Executive Stakeholder Steering Committee (ESSC) that includes business stakeholders, product, and IT leadership. This committee meets periodically to review progress, provide strategic input, and program and project sponsorship. These agile organizational constructus are part of the governance structure and process, and their design and execution are based on who makes which decisions and what criteria they consider.
Sidebar: “Laws without enforced consequences are merely suggestions.”
— Ron Brackin”
Comments