March 7, 2019
Why Standard Change Management Solutions are Not Suited for Salesforce?

Still Using Salesforce Jenkins, et al? Time to Reconsider.

Many large enterprises have standards and tools for the release and change management processes. For example, banks typically have a central, dedicated release team, which is responsible for deploying to production systems. They use a standard set of tools and processes to deploy these changes to the production organization. This central team has expertise on a standard set of tools, which are used across all different banking applications.

When the IT organizations of these large enterprises look at Salesforce, they often wonder why a separate solution for deployments to Salesforce is needed. There is a natural tendency to use the same set of tools for managing and deploying to the Salesforce application, including leveraging the standard, in-house version control systems such as GIT and SVN.

Enterprise Application Systems such as Oracle and SAP have their own purpose-built custom Change Management solutions. These applications are typically self-hosted, on-premises applications which would, seemingly, make it easy for them to use these off-the-shelf tools. Yet, it is rare to find an ERP customer who uses off-the-shelf deployment tools such as Jenkins, Cumulus CI and TeamCity for deploying code on these applications — even though the foundation of these applications is built on standard technologies such as Java. So, if the standard off-the-shelf tools have not worked for these enterprise applications, why do Salesforce customers spend their time in evaluating off-the-shelf standard tools and solutions for Salesforce? It is time to reconsider.

That using these standard tools methodology is sub-optimal for Salesforce customers is not a secret. Flosum’s Application Lifecycle Management (ALM) products provide the much-needed solution for IT organizations developing on the cloud-based Salesforce platform.

Consider one of the niche financial banks using Salesforce. Having used GIT as a central repository, hiring full-time experts to synchronize code between the GIT repository and the Salesforce organizations, they gave up after 6 months on the GIT architecture and found themselves looking for alternatives. They found a perfect solution in Flosum with its simplicity! Consider numerous other customers who are using Cumulus CI, Jenkins, and TeamCity, and have come to the realization that an alternative is needed for them to manage their Salesforce deployments simply and comprehensively.

Why Standard Change Management Solutions are Not Suited for Salesforce?

Here are reasons why a standard change management solution is not suited for Salesforce.

1. Extracting changes is a challenge: Salesforce has 120+ metadata types. A standard tool which is not a purpose-built adapter for Salesforce cannot retrieve all the different metadata components. Flosum uses over half a dozen different techniques and algorithms to retrieve all the changes in a Salesforce organization metadata types. Flosum worked with CSA group to inherently solve the problems with deploying profiles. Flosum’s tool removed the need to create multiple sets of changesets, saving the developers time and improving efficiency For example, each of the below uses a different technique to retrieve components:

  • Standard versus custom fields
  • Components within a folder such as email templates, reports, dashboards
  • Sharing rules

It is important to note that not only different algorithms are used, but also the sequencing and nature of calls vary between various scenarios. Most horizontal standard tools from the market cannot retrieve most of the components.

2. Inconsistent Metadata types: Salesforce is continuously making their platform more robust and standard. As an example, if you want to update profiles, the API can be used to enable the profile settings; however, if you want to disable the settings, there is no API that allows you do so.

3. Constant changes in the Platform: Salesforce has been consistently adding new metadata types as they introduce new platform capabilities. There are many nuances which come with the newly introduced metadata types. For example, the recently introduced process builder component cannot be deployed until it is deactivated in the target organization.

4. Design of metadata types is complex: In a standard application platform, the artifacts of an application are very clearly defined. For example, in the Java platform, the classes are mutually exclusive from each other. This makes it really easy to version control the different components and isolate the changes made to different components.

However, Salesforce metadata types have a lot of overlap, duplication, and redundancy within the metadata components. For example, one of the most commonly used metadata types is the custom object. The subcomponents of that object are fields, layouts, buttons, etc. These subcomponents can also be deployed separately in the same release. This creates confusion as to which component caused what change in the organization.

5. Collaborative development is not efficient: IT teams build applications for Sales users to capture leads, convert leads to opportunities, create quotes and orders. Sales managers have their own forecasting and sales management application. Similarly, service agents have another single, well-integrated application for the request-to-resolution process. Similarly, why shouldn’t IT developers and admins have a single, well-integrated application for capturing requirements, managing environments, migrating data, and promoting code across orgs?
From an economic point of view, it is more expensive and harder to implement a solution using standard, but disjointed, tools for collaboration. Provisioning an application for developers yields a higher output for business, and the cost in making developers productive is easily justifiable.

6. Governance failures abound: During a typical deployment, most developers and admins face a number of varied potential issues even for a well-tested release. During the deployment, typically there are a lot of issues that need manual resolution such as issues with apex code, test classes, code coverage, amongst others.

Field data from actual customers finds that developers sometimes take extreme measures at the final stages of deployment to push their code into production. These measures typically lead to governance failures. For example, developers disable certain functionality, remove certain artifacts, make application code changes without sufficient testing directly in production!

7. Compliance mandates are in violation: Most customers spend a lot of time in evaluating the Salesforce platform from a compliance perspective. It is not uncommon that lawyers from both parties get involved to ensure that the platform meets the regulatory requirements for each operating region as well as complies with industry laws. An off-the-shelf cloud solution which is hosted on Amazon would automatically violate the compliance requirements that the customer is expected to meet.

Also, if one observes the trends of the Salesforce platform, the thin line between the metadata and data is blurring. There is a lot of overlap between the various categories. Much of the application setup data is now shipped as configurations (using Custom Metadata types). This means that customers will now be storing not just their code but also their data on those uncertified cloud systems where these off-the-shelf tools are hosted.

8. Profile Deployments are a manually intensive and security nightmare: Most of the customers deploy the profile and permission sets manually. This is because almost every component in the Salesforce system has a reference to the profile setting. Customers have to manage millions of different custom settings which is really hard to manage manually. It is almost impossible for any developer to make a change in the developer organization and move it successfully all the way to the production organization. This manual intervention by a developer can easily compromise security and access by either reducing the access or, even worse, silently giving more access than needed.

Flosum automates this via intelligent profile deployments. Profile deployments are as simple as deploying any other components and is a huge added value for customers.

9. Deployments are a laborious and multi-step operation: Customers cannot deploy all the metadata types in one shot. They cannot merge code changes from various developers together into one deployment unit. They cannot use the same deployment units to deploy across multiple orgs across the delivery chain.

Using manifest-driven deployments, Flosum allows you to quickly generate deployment plans. For instance, Flosum partnered Australian Post, to reduce the deployment time. Flosum implemented their component packaging system and reduced packing time from 20-30 hours to 6 hours. The deployment plan can be created automatically from various developer activities to generate application-centric, manifest-driven deployment. The manifest can be created collaboratively by various developers from various different sources. This leads to reusable and repeatable processes to simplify and streamline application releases.

10. Ease-of-use is nonexistent when using off-the-shelf tools: Sadly, the developers and admins suffer the most when using a heterogeneous set of existing standard tools. A large number of the more complex deployment tasks have to be either scripted or done manually.

Flosum eliminates the need for scripting and allows you to visually create your deployment processes.  All the complex deployment tasks that are very hard to automate can be accomplished at the click of a button.

11. Business effectiveness suffers: With multiple tools in play, the impact to business is real and more prone to happening. Most large, enterprise systems are global in nature and need to keep the systems up and avoid disruption. Longer maintenance windows leads to loss in revenue, lower CSAT scores, and taking a hit on business.

12. Extensibility is nonexistent: Customers get what the standard tools provide and no more. There is no luxury to extend the Salesforce platform benefits to do tasks as simple as customizing the user-experience or easily generating reports that are meaningful for the developers and admins.

13. Training is needed to learn yet another platform(s): The greater the number of tools in the off-the-shelf solution, that much more training needs to be provided to the developers and admins to understand the nuances of each tool.

A solution built 100% natively on Salesforce aids in the intuitive use of the solution. Flosum has ensured that its architecture is built completely on Salesforce’s force.com platform.

14. Security vulnerabilities is a risk: Keeping pace with new security vulnerabilities is a risk that customers have to contend with the larger number of the off-the-shelf tools. On the other hand, a solution built fully on the Salesforce platform benefits from the security rigor that the trusted Salesforce platform is well-known for.

Conclusion

There is a common saying in the financial world: “Do the math and the math will tell you what to do!” Do a numbers evaluation on the value delivered between the standard tools versus Flosum. Let the math dictate the solution that you should use.

Flosum is a purpose-built solution to solve Salesforce-specific deployment challenges. While it may look tempting to use existing tools like Salesforce Jenkins GitHub, the operating cost of using those tools is incredibly higher compared to using a solution designed to solve Salesforce challenges. Flosum is continuously pushing the boundaries to help customers lower the total cost of ownership (TCO) for their Salesforce solution.

Next Steps