Let’s end the Salesforce change paralysis – The new stack

0

Rami Tamir

Rami Tamir is co-founder and CEO of Salto.io. An entrepreneur with 25 years of experience managing multidisciplinary software development, Rami is a serial founder who has sold startups to Cisco, Oracle and Red Hat for over $700 million. Rami’s latest project, Salto.io, founded in 2019, brings concepts and methodologies from software development and DevOps – the use of structured language, version control and automation – into the business operations environment. Today, in addition to being the CEO of Salto.io, Rami makes angel investments in early-stage tech startup companies, but also sits on several boards of these companies. Rami holds a BSEE/CS in Electrical Engineering from Technion and an MBA from Northwestern University and Tel Aviv University.

In their current iterations, business applications like Salesforce or NetSuite are fragile systems.

One reason is that they are, by and large, being developed by product designers with go-to-market concerns. They want to make the interface as simple as possible to attract more users. As my co-founder Gil Hoffer discovered, that was great – now everyone actually uses them. But all that UI simplicity comes at the expense of manageability.

Almost all business applications lack the business risk mitigation capabilities you would expect from systems that can inadvertently overwrite customer records, trigger invoices, email prospects, and cause major revenue-disrupting events. That risk plus somewhat restrictive no-code controls means admin teams have to go very slowly because nobody knows what might break.

I’ve seen firsthand how that can cripple a revenue operation. Requests are secured, making the company less competitive overall.

There are a few specific reasons for this, as I’ll explore — and a few specific fixes. It all starts with considering all of your business applications as a unified “product” – not standalone systems – and being able to analyze the impact on all of them. I use Salesforce as an excellent example of a well-built business application that can still benefit from this approach.

Salesforce – important and fragile

Let’s talk about Salesforce. Of course, changes in Salesforce are destructive. That means if someone updates a field or changes a workflow, deleting data or metadata in the process, there’s no easy “undo” button, let alone a selective “undo” button. These systems are largely designed for users to work quickly, rather than for administrators to work carefully.

Or consider the task of rolling back a major update. Your team can use a backup system—and go through the painful process of restoring to a version from a known time—but it’s complex and it’s all or nothing. You can’t just undo some of the changes. So it’s anything but streamlined. And even if you come back successfully, you still have to figure out what was wrong with the change. There’s a reason software developers have different tools for saving source repositories and backup/reset.

All of this makes business application teams reluctant to make changes unless absolutely necessary, hence the paralysis.

Recently, business application vendors have attempted to address these shortcomings by introducing advanced developer modes. Third-party DevOps for BizOps tools have also been developed to address some of these needs. DevOps is certainly the right direction, and these tools will help. But they don’t relieve paralysis.

That’s because each of these dev modes or tools application specific, while the average company has Over 800 business applications, many of which have Salesforce read/write permissions. If you want to DevOps your BizOps and strengthen your Salesforce configuration management, you need to address the entire go-to-market application cluster.

Otherwise, you still have no way of knowing if a change in Salesforce will break something elsewhere. Could it irrevocably overwrite customer records in ERP and disrupt those billing cycles? Could it invalidate a “throttling” rule in the marketing automation system and email clients? Could it change a shortlist that causes all leads to be misdirected for months? And what about all the apps that can read and write metadata in Salesforce?

Because of this, to end Salesforce change paralysis, you can’t just deal with Salesforce—you have to deal with the ecosystem. Hence the need cross-application DevOps.

Cross-application DevOps requires a universal configuration language

Every business application today is a schematic island. You cannot copy patterns or processes between them, creating silos and preventing you from practicing true DevOps. A sample Salesforce environment remains in that one environment. Therefore system administrators need a universal language for business applications.

If we had a universal language, business systems like Salesforce and NetSuite would be mutually intelligible. We could have an application-agnostic view that would allow us to both scan, compare environments, track changes, and really anticipate impact.

With an application-agnostic view, you can consolidate configuration and metadata from multiple business applications into one place. There you can version, collaborate on changes, debug, document, test, push changes to production — aka true DevOps — and make Salesforce less vulnerable.

Now, it’s difficult to understand a software application vendor creating this solution. It must come from a third party. And it needs to build on or replace existing configuration schemes like XML, which for all its flaws is a start in the right direction. Because only when the entire business application cluster uses the same syntax can we finally alleviate the paralysis of Salesforce impact analysis.

Make Salesforce (and others) less fragile

Far too many Salesforce admins are reluctant to make changes today. They can have a dozen years of experience and still not know what impact a change will have because the tools to let them know aren’t native to Salesforce. These systems are somewhat fragile in this regard.

But the answer isn’t just applying DevOps, it’s applying it to your entire business application stack. I believe this requires a universal language for business applications. I would like to hear your thoughts.

feature image over Pixabay.

Share.

Comments are closed.