The year was 2015 and my feature team was forced to learn Salesforce. I know that sounds extreme, but that was the reality for the six core members of our team who were required to adopt the force.com platform as a part of a corporate objective.
Other than an introductory session from Salesforce during the 2008 Gartner Application Architecture and Design conference, I really had no depth of knowledge for a CRM product which promised a "No Software" implementation. However, I did receive a pretty nice T-shirt for attending the session.
A Fast Journey
The goal of the 2015 initiative was two-fold:
- get the team up to speed with the Salesforce ecosystem
- convert an existing CRM solution to Salesforce
The six-person team consisted of four full-stack developers and two quality assurance team members. Prior to this assignment, our project sprints had been focused on using leading-edge, open-source frameworks and technologies. As one might expect, getting to know Salesforce in the pre-lightning era seemed like it might be a step back because we all felt like we were working on an assignment that lived within a closed-source proprietary system, or what is often referred to as a "walled garden".
Walled Garden: a software system wherein the carrier or service provider has control over applications, content, and media, and restricts convenient access to non-approved applicants or content. This is in contrast to an open platform, wherein consumers generally have unrestricted access to applications and content.
When talking about the project, at the time, my biggest hesitations with the Salesforce solution were the following:
- non-standard options for client customization
- inability to work in a git-based workflow
- inefficient request/response pattern for client/server communication
- inability to end-to-end (E2E) test Salesforce customer solutions
Our implementation went live in November 2015. In fact, the project was considered the most-successful software implementation for my employer – which was delivered without any delays or compromise in functionality.
Since it has been five years, I thought it would be appropriate to see how Salesforce has changed. After all, five years is considered an eternity in software design and architecture.
A New and Open Course
When I speak with team members in the Salesforce/MuleSoft practice at CleanSlate Technology Group, they only nod in agreement when I recall the project which consumed about 50% of my employment in 2015. In every case, these technologists are eager to point out just how far Salesforce has evolved from being a walled garden. One key indicator to determine this is to check for the presence of open-source projects. Without much effort, I was able to locate the official Salesforce page on GitHub:
At the time this article was drafted, there were 211 repositories which I had access to view using my GitHub account.
The next step is to understand how many of these repositories make the Salesforce experience more open sourced and break down the walls of a closed-source ecosystem. Sorting the repositories by the highest star rating to the lowest star rating, I found some very exciting and active projects—some of which publicly expose functionality internal to the Salesforce CRM solution.
Client Improvements
One of the biggest challenges of the Classic version of Salesforce was the lack of a rich-text client which could be extended. During my 2015 project, I remember our team included a compressed archive of JavaScript libraries to provide a user experience which was more in line with customer expectations.
The Lightning upgrade with Salesforce introduced the Lightning Component Framework (LCF) and a model which is called "Aura." The LCF upgrade solved a number of challenges, but still maintained some degree of proprietary design – until the following open-source projects were initiated:
- lwc: contains the source code for the Lightning Web Components Engine and Compiler
- design-system-react: React-based implementation of the Salesforce Lightning Design System
- base-components-recipes: provide the source code for the base components of the Salesforce Component library
Open sourcing the code related to the client-side of Salesforce communicates a zero-transparency message and allows those working in the Salesforce ecosystem to gain a better understanding of the underlying code driving the client experience. Additionally, feature teams interested in leveraging React no longer have to dive deep into the Aura model.
But Wait ... There's More
By open sourcing the repositories noted above, the following challenges from my 2015 implementation are no longer an issue:
- non-standard options for client customization
- inefficient request/response pattern for client/server communication
The two remaining issues have also been addressed:
- inability to work in a git-based workflow is met with Salesforce DX
- inability to end-to-end (E2E) test Salesforce customer solutions is now possible with TestimSalesforce DX
Salesforce DX provides an integrated, end-to-end lifecycle designed for high-performance agile development. The lifecycle is open and flexible, facilitating integration with common and preferred tooling for building applications. By contrast, I have published the following articles on DZone in 2017 to demonstrate the steps required to automate the build process with Salesforce:
Continuous Integration With SalesforceConfiguring Stash/Git for Salesforce With the Force IDE For EclipseDeploying Salesforce Using Bamboo
The Salesforce DX product eliminates a majority of the manually driven tasks, while introducing automation to create Scratch orgs which can be used to validate git-based updates. Once validated the Salesforce updates can be migrated using standardized deployment solutions.
E2E Testing Using Testim
While use of Selenium is possible with Salesforce for end-to-end tests, the Testim product has gained approval by the Salesforce QA engineering team from an E2E perspective:
Use of the Testim product enables the confident execution of complex E2E tests, replacing the requirement of manually-executed tasks. With a stable E2E solution, QA engineers can finally embrace exploratory testing to potentially uncover bugs from alternate flows which had not been fully validated due to time and resources.
Feature teams working on Salesforce-related functionality can add Testim to their development lifecycle toolset to perform the same degree of E2E testing prior to releasing new features and functionality.
Conclusion
At the end of 2015, the Salesforce ecosystem was a walled garden. While my feature team was successful at deploying a solution that end users loved and appreciated, the feeling of deploying a "closed" solution was bittersweet from a technology point-of-view.
The current state of Salesforce reflects a great advancement from an open source perspective. In fact, a great deal of time and dedication has been allocated to support and maintain the client-related repositories noted above. Furthermore, the Salesforce DX product allows feature teams to adopt git-based workflows as a part of their development lifecycles. From an end-to-end perspective, the use of Testim handles the complexities related to complex and long-running scenarios which should be validated before the functionality is made available for customers.
Salesforce provides a summary of additional open-source projects that can be tracked at the Salesforce Open Source site:
This site provides another view into the mindset of the Salesforce engineering team, offering open-source contributions to concepts which do not map to CRM-related opportunities to solve. Some interesting items to consider are noted below:
- AI Economist: a flexible, modular, and composable framework to model socio-economic behaviors and dynamics with both agents and governments
- Akita: state Management Tailored-Made for JS Applications
- TransmogrifAI: AutoML library written in Scala that runs on top of Apache Spark
- Policy Sentry: IAM Least Privilege Policy Generator.
Clearly, Salesforce is no longer a walled garden.
Have a really great day!