Elements multi-cloud dependencies

Salesforce is not an island. Elements multi-cloud dependencies.

The need for enterprise-wide, not just Salesforce, change intelligence is becoming obvious. Change intelligence is the aggregation of all documentation that supports the implementation change cycle for apps and processes. It allows collaboration across different stakeholders and enables them to make risk-based decisions when making changes.

There are 3 factors that are driving the need for more complete, accurate, and reliable change intelligence:

Firstly, scope and scale. Salesforce and the Customer360 vision is becoming a reality in organization after organization. Multiple Salesforce clouds are being implemented in organizations to deliver Customer360; Lightning, Marketing, Tableau, Slack, and Mulesoft. The power of the platform is that it can support every area of an organization and enable it to transform; sales, service, HR, operations, compliance etc. It also means that Salesforce is integrated into other strategic apps in the IT landscape. Ownership of Salesforce is now being transferred to the IT department which works in partnership with the business. 

The second aspect is pace. The business is demanding more rapid changes to Salesforce, as it holds the customer-facing data, to stay relevant and competitive. There is a knock effect through the integrations with other apps. This is posing a huge challenge when systems are poorly documented and understood. The options are currently “run fast and break stuff” which loses the trust of the business or “go slow and get it right” and also lose the trust of the business.

Finally, there is the rise of LCNC (Low-Code/No-Code) which seems to put the power into the hands of citizen developers that work for the business. The business can use this approach to bypass the IT department if they are failing to deliver the results at the speed the business demands. This is forcing IT to enable the business by providing “guardrails” that empower citizen development at the same time as providing IT governance. This is a delicate balancing act.

There is a way to reconcile all 3 of these factors, but it means taking a wider enterprise-wide perspective of change intelligence rather than the narrow Salesforce core platform-specific view.

The 3 C’s: Content, Connections, Context

Content: You need all, not just some, of the configuration metadata to be able to provide impact, dependency, and change analysis. Only then can you make informed decisions. This means everything related to the core Salesforce platform, customizations, and Managed Packages, but also where they are integrated into 3rd party enterprise on-premise and SaaS apps – either directly or via integrations apps like MuleSoft. 

Connection: Documentation – such as requirements, user stories, process maps, and Salesforce Architect Diagrams, specs, images and links – whatever format, and where ever it’s stored, needs to be connected. Connecting documentation takes a fraction of the time compared with the time it took to create it in the first place. Content can be automatically analyzed and connected, or easily imported and connected. Providing access to the most up-to-date content saves hours of frustration and wasted time amongst development teams. If you have time to Tweet about it, you have time to connect it.

Context: By analyzing the connected content in context means you can uncover insights that save costly rework and release roll-backs. It enables you to clearly see the areas of risk amongst a sea of configurations. This early analysis is core to the “Shift Left” concept – “the earlier you find issues, the quicker and cheaper they are to resolve”.  The pace of change, the scale and complexity of Salesforce implementations, and the number of integrations mean that this analysis now, realistically, can only be done automatically.

Collaboration: the Missing “C”: What the 3 Cs enable is better Collaboration. As Salesforce implementations now require input from multiple people/teams (business analysts, admins, architects, developers, and consultants), it is important that everyone has access to the right information (3 Cs). To emphasize, that means this is stored centrally, not siloed, and that everyone is looking at the same information. 

Architected with no limits

If you consider the implementation change cycle, the business analysis documentation – requirements, process maps, architecture diagrams, ERD, user stories – are not app-specific. However, there needs to be a metadata dictionary for each app so that the dependencies between metadata items can be mapped and the business analysis documentation can be linked to any metadata item. 

Once you have the links they can be visualized. And suddenly it is not data but real intelligence. With that intelligence, you can start making risk-based decisions when planning changes. Below is an Elements dependency tree where you can see the potential downstream impact of the change of metadata. As you can see in the image there are relationships between Salesforce cloud apps and 3rd party apps.  

Clearly, every organization has a different IT landscape with a combination of cloud, on-prem, and custom apps. By design, the Elements architecture enables any app to be sync’d into a metadata dictionary. Each metadata dictionary item can have business documentation and important links to any other metadata item in any other metadata dictionary. With this architecture, there is no limit. Anyone can build a connector to sync an app into a metadatata dictionary. Every app. Every dependency.

Partner Opportunity

Salesforce Customer 360 vision and growth have created a huge market opportunity. The Elements architecture creates an enormous partner opportunity. 

Partners involved in Salesforce implementations can now expand the scope of any engagement to a wider enterprise digital transformation perspective. This will engage the CIO rather than just the Salesforce platform owner. This provides an ability to grow the scale of any engagement, but also the opportunity to move from delivery to strategic advice. 

But there is also an opportunity to build an annuity revenue stream by building connectors for the apps where you have deep expertise. The Elements connector architecture is open. We are publishing the code in GitHub for the existing connectors that we have built. These are patterns so that any connector can be built to any app. That connector can be monetized. Or it can be used as a competitive advantage to win work.