So your company is working to improve its development pipeline. There’s a big project to work on your DevOps processes and toolset, and maybe even changes to the way your development is being managed. However, if you’re a developer these changes could be the least of your problems.
Let’s face it, code isn’t always perfect. Long-running codebases tend to grow organically. So, how are you going to get things organized and under control to make your transition easier? This is an especially difficult challenge when the improvements include a move to Salesforce DX from standard Apex.
It’s easy to add features when all of your code resides inside a single codebase. Things get much trickier when your code is split into several DX packages. How do you properly separate your code? How does your code communicate across package boundaries?
Your best option is something that Object-Oriented Programmers have been using for many, many years; Design Patterns. You’ve probably heard of them before, and there’s a reason for that. Once you get the hang of them, they make programming easier. They change the way you approach solutions and simplify conversations between developers during planning and strategy sessions.
Design Patterns also help you structure your code and communicate between layers, or packages, in a much more efficient and manageable way. That communication is very important as you transition to DX because of the ever-growing need to follow Separation of Concerns as you adopt more, and more of a true DX strategy.
As your code splits into packages, you’ll find that without proper separation of concerns your team(s) will be crossing package boundaries more than you anticipated. This can cause more work in adding features to, and maintaining, your applications. This would not help your company’s improvement efforts at all.
The solution is to start thinking of the code behind your applications in terms of modules of specific functionality, or blocks of code that serve a very specific and focused purpose. As you approach your code in this fashion, you will likely hit the inevitable question, ‘How do I get these packages to share resources and talk to one another cleanly?’
That is where Design Patterns can help. You can start by isolating the functions of your code into their logical components. Meaning:
- Pulling all of your SOQL into sObject-specific Selectors.
- Pulling all business and execution logic OUT of your Triggers, and into sObject specific Domains and Services
- Pulling business logic and execution OUT of your Controllers, and into Services, Strategies, Providers, and more.
- Build Factories so that your components and packages can request instances of Selectors, Domains, Services, etc rather than tightly binding to one another.
- Creating Facade classes as the interface between your custom code and 3rd party managed packages or external APIs.
- Selecting an owning Package for each sObject & Field.
Whether accomplished through the use of third-party, open-source offerings such as the FFLIB and Force-DI suites or built in-house following the guidance of the Gang of 4, Martin Fowler, or Andrew Fawcett you can simplify your future code maintenance and your transition by learning and mastering Design Patterns.
The process of cleaning up, or refactoring portions of, your codebase to fit proven Design Patterns often leads teams toward identifying their modules, or packages. This effort also reveals dependencies between these modules and packages and helps to identify which package should own which metadata across your org.
For example, as you go through the process of building Selectors and moving SOQL statements into them you’ll be able to clearly identify all of the functional pieces of code across your org that need access to certain sObjects. However, some of that code might logically belong to different packages. Further, only one of those packages would own the original Selector for a given SObject.
Let’s say your company manages inventory, sales, and shipping all through Salesforce. Those three logical systems are all likely to utilize shared data. However, not all of them need the same data: Sales is likely to need data from the Inventory system; Shipping is likely to need some data from Inventory and some data from Sales; Inventory could use sales forecasts for placing orders for additional inventory and data from Shipping to reduce inventory available to be sold once product ships.
All of this points to a dependency chain where Sales would depend upon Inventory, and Shipping would depend upon both Sales and Inventory. Both Sales and Shipping should be able to extend or inject functionality on top of what Inventory is providing them. Inventory package would then be isolated in its code and focus, and not carry around the weight of Sales and Shipping custom objects, fields, and code.
Fields added to a sObject for the benefit of Sales should be owned by the Sales package. Fields added for the benefit of Shipping would be owned by the Shipping package. The motivation behind this is that you wouldn’t necessarily want the Shipping team’s developers crossing over into the Inventory and Sales packages to adjust things. That could lead to code collisions, and a much more difficult time maintaining the system over the long haul.
All of this layering, dependency management, and separation of concerns is easier with properly implemented Design Patterns. The end goal is to isolate your codebase into a state where it is easy to identify where changes and features belong, and easy for teams to work in isolation with less worry about code collisions and deployment issues. It may seem like more work to get your code to that point, and it likely is. The pay-off is substantial, though, and very much worth the effort.
We read an article recently, which you can read by How the CIO lost control: Why cloud computing and millennials have got tech bosses running scared, that really caught our attention. It calls into question the relevance of the CIO (Chief Information Officer) and IT departments as a whole, citing this stat:
- Value Opportunity #1: Put your data to work today.
To expedite the initial implementation process, we like to start with what you have: data.
Your business is continuously collecting data, but many companies are not able to use it and gain value from it because
- the data hasn’t been customized for their specific team needs, and
- the data isn’t easily accessible in one location.
When set-up correctly, Salesforce helps organize and provide you the ability to see all your important data points in one location, so that your business can make smarter, data-based decisions.
When it comes to data, different groups within an organization need to know different information. It doesn’t help anyone if everyone has the same generic dashboard.
Within Salesforce, executives, department heads, and sales leaders can determine what information they need to see, and perhaps more importantly, what information they do not need to see on a regular basis. Each group can customize their own dashboards and reports based on their specific needs.
Real-time dashboards allow you to view the most important daily data points to make decisions quickly, without delay. Reports allow you to then identify trends over time. Additionally, anomaly triggers identify potential issues before they become a problem.
Potential threats that shine the light on potential problems, as well as key factors that have led to success, can be highlighted in reports and dashboards. This allows teams to focus on what matters most to them, and not be distracted by information that matters to another department.
Once organized, it’s important that everyone can both 1. easily access the information that’s important to them, and 2. Understand, through analytics, how to turn this data into useful information.
“Most problems don’t require more data. They require more insight, more innovation, and better eyes.”
– Seth Godin
This is where the right Salesforce partner comes in. Their role is not simply technical implementation. The partner you need is one that helps you identify how to structure your current data, eliminate bad data, and ensure Salesforce is configured in a way that your team understands and finds useful.
The best partners don’t simply turn Salesforce on for you. The best partners help you understand how to best use the tool to reach your goals, then make sure you’re experiencing the value each and every day.
- Value Opportunity #2: Build a roadmap to stay on schedule.
Are you trying to do too much at once, and feeling bogged down? Before taking any steps toward implementation, it’s important to create a roadmap of your priorities to ensure a systematic approach.
You’ve read the articles and probably watched a few videos about the various Salesforce products available to you.
You’re thinking, “wow if we start using all of these new products, we could solve our problems in an instant.”
However, our experience suggests just the opposite to be true. Many of the tools and capabilities build upon one another, as with the common analogy: crawl before you walk, before you run, before you ride a bike, and so on.
But starting out with too much on your plate can overwhelm the team configuring the platform, as well as the users of the platform.
Think of your initial implementation of Salesforce as a roadmap, not a set of blueprints. Be ready to adapt and make changes when necessary.
- Start small;
- customize Salesforce to your business processes; then
- get your employees using and having success with the platform.
Once you have some momentum, it becomes a lot easier to add additional Salesforce products, services, and features to build upon these small wins. Bottom line: it’s easy to become enamored with all the features. Resist the urge to solve problems you don’t have.
- Value Opportunity #3: Show everyone how Salesforce benefits them.
Do all stakeholders see the value of Salesforce for themselves? Many user adoption issues arise when one group thrusts Salesforce upon another without first clarifying how it helps the other group.
Leadership: Team leaders often fall in love with the idea of real-time dashboards, instant reporting, and process automation. And for good reason – these are fantastic capabilities to have at your disposal.
What’s important to recognize, though, is that leadership’s visibility depends on the rest of their team engaging with the platform.
The perspective that isn’t always presented is how Salesforce is actually a great benefit to the team members themselves, providing better record keeping, the elimination of mundane admin work, and removing the constant time spent generating reports for leadership.
Sales: Sales teams tend to balk at having to enter their data into a system that everyone can see. They’re wondering why, after all these years of success with their own system of spreadsheets, address books, and their memory, must they give up their contacts with no additional benefit to them.
Their initial fear is that Salesforce is going to distract them from doing what they do best: selling. The reality is that Salesforce allows them to cut out all kinds of other distractions they currently have.
Centralized customer information means sales reps don’t have to spend time educating other teams about next steps that involve more colleagues.
Instant reporting means sales reps don’t have to interrupt their day to generate status reports for company leadership.
Real-time dashboards mean sales reps can more readily see which campaigns and activities are working best, and which aren’t.
Automation means your sales reps can spend less time remembering simple tasks, or triggering more personalized responses to customers at scale.
All this adds up to more time spent actually selling. Customers get what they want faster than before, requiring less time and resources from your team, which allows your whole company to scale faster than before.
IT: Your tech team is going to help maintain and build upon your Salesforce progress. Everyone’s life becomes simpler when IT is kept in-the-know when new Salesforce applications and features are added to the platform. They can ensure that all current systems are properly synced with Salesforce so that information can flow across platforms.
Ultimately, IT will be able to more easily and quickly address any key issues with functionality if they understand how teams are using the platform and what they want to get out of it.