Recently, our Salesforce team set out to create an integration accelerator between Salesforce and Segment, a 3rd-party Customer Data Platform (CDP). Our goal for this accelerator was to create a comprehensive, flexible and easy-to-use solution. On the development side, we wanted to modularize our solution and maintain a high degree of code reuse which led our engineering conversation to the Apex Enterprise Patterns framework. This open source framework introduces programmatic design patterns like separation of concerns and also provides a mocking framework for more robust unit testing. The Enterprise Patterns seemed like a great fit at first, but questions arose as we began to discuss the topic of distribution.
For our accelerator to be successful, we knew it needed to “fit nicely” within the many different types of Salesforce orgs and Segment use-cases of potential clients. We wanted this accelerator to be something that could easily be installed, regardless of org type, development model, business process, etc. To make use of the Enterprise Patterns, which are mainly Apex classes, the corresponding Salesforce metadata must exist within an org. So our question became, how do we develop and distribute a solution that uses the Enterprise Patterns so that it can easily and practically be installed into any org?
We considered the possibility that we could be installing into an org that may not already be using the Enterprise Patterns. Would it be necessary for us to introduce these patterns into this type of org? Could this create more maintenance and perhaps confusion for a client’s development team if these patterns were unfamiliar? These questions led us to the idea of creating a lightweight version of the patterns and only delivering the ones we planned to use. In exploring this option we quickly realized the strongly coupled interdependencies that exist under the hood of these Enterprise Patterns that make it impractical, if not impossible, to cherry-pick and create a lightweight version.
On the flip-side, we discussed the possibility that some orgs may already be making use of the Enterprise Patterns. In this case, would we still include the patterns as a part of our delivery? What if an org had customized their implementation of these patterns and their functionality varied from what our accelerator was expecting? In response to these questions, we contemplated the idea of namespacing our entire solution, including the Enterprise Patterns. The thought being to remove the risk of relying on any current implementation of these patterns in an org that varied from our own. This seemed like a good option until we started to think about the volume of metadata this could present. If we delivered namespaced Enterprise Patterns into an org that already was using Enterprise Patterns then we would likely be creating a high level of redundancy and adding unnecessarily to the Apex size limitations for that org.
You may be wondering why we didn’t use a Second Generation Managed Package to be distributed in the Salesforce AppExchange. Among other benefits, some notable advantages to this distribution model would have included easy download and install into any org, lessened concern of Apex Governor limitations like Apex size and namespacing to avoid any potential conflicts. However, the trade off to these benefits is a rigid solution whose metadata cannot be changed in an installed org. Therefore our decision to forgo using a Managed Package came back to our vision for this accelerator. At WillowTree, we take a lot of pride in partnering with our clients by getting to know them and making the best decisions for their business. For that reason, we wanted to make sure we allowed ourselves plenty of room to collaborate and tailor any implementation specifically to our client’s needs when applicable. Delivering a one-size-fits-all solution via a Managed Package does not allow for any further customization in installed orgs and thus, simply did not allow us the flexibility we desired.
In the end, we ultimately decided to create our solution independent of the Enterprise Patterns. We still believe there is tremendous value in utilizing these patterns. Their use of design patterns like separation of concerns and a mocking framework are greatly beneficial to many large scale applications. However, it was the flexible distribution of a solution that utilizes these patterns that presented a challenge to us and was ultimately the reason we decided to forgo the use of these patterns in our accelerator. By going this route, we have been able to build a lightweight, comprehensive and flexible solution that allows for easy installation and set up of an integration between Salesforce and Segment.
Hopefully you have enjoyed the insight into our experience and considerations around using the Apex Enterprise Patterns framework. We’d love to connect with you about whether Apex Enterprise Patterns make sense for your Salesforce environment.
If you are trying to connect your Salesforce org to an external CDP, let’s connect!
