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. Let see how Salesforce is multi-cloud so needs an enterprise-wide perspective.
There are 3 factors that are driving the need for more complete, accurate, and reliable change intelligence
1. 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, 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.
2. 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.
3. LCNC (Low-Code/No-Code)
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 then it can be vizualized. 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.cloud dependency tree where you can see the potential downstream impact of the change of a metadata. It starts with a metadata dictionary generated and kept up to date for each app in the IT landscape. This metadata dictionary has all the metadata or configuration items for that app. The app could be Saleforce core, Salesforce external app (Slack, Tableau), a cloud app (ServiceNow, WordDay.Celonis) or custom apps inside the organizations IT estate (on-prem or cloud).
The relationships between any item in any metadata dictionary can be mapped. Many of these can be mapped automatically by parsing the metadata. Other need to be generated or manually entered,. BTW To date Elements.cloud has mapped 15 BILLION metadata items.
Once those dependency relationships are mapped, Elements.cloud can visualize them in these compelling Dependency Trees. As you can see in the image there are relationships inside the Salesforce core platform and Salesforce cloud apps and 3rd party apps. You can see the impact of change. You can estimate the time to implement change. You can allocate teh correct DevOps resources.
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 importantly links to any other metadata item in any other metada dictionary. With ths architecture, there is no limit. Anyone can build a connector to sync an app into a metadatata dictionary. Every app. Every dependency.
“From day1, Elements.cloud, because it is built on AWS, was able to support the other aspects of change – requirements capture, process mapping, ERD, users stories – for any app implementation. But the multi-cloud dependency trees is what has connected everything together and made it a game change.
“I’ve been drawing this multi-cloud vision on whiteboards in boardrooms for the last 2-3 years. I am so excited that it is now a reality”, said Ian Gotts, Founder & CEO of Elements.cloud
Open architecture: Partner Opportunity
Salesforce Customer 360 vision and growth has 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 it also allows partners in other ecosystems to start engaging the areas of the business in their clients who are using Salesforce. So they can broaden their practice. For example, Oracle ERP experts can expand their practice into Salesforce CPQ or Sales.
But there is also an opportunity to build an annunity revenue stream by building connectors for the apps where you have deep expertise. The Elements.cloud 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 competitive advantage to win work.
