Considerations When Architecting A Solution

Salesforce Solutions

When architecting a solution one needs to be sensitive to develop something manageable and sustainable while leveraging the appropriate technology for the task. Salesforce continues to push the envelope at a fast pace delivering platform enhancements to leverage for solutions. Therein lies a challenge, how does one keep up with platform updates and how does one determine which technology is best to implement to solve the problem at hand?

With regards to keeping up with platform updates, make sure your team is tasked with keeping up to date on enhancements. I stress the word ‘team’. Always bring the team into this activity because a holistic viewpoint will be represented when discussing how Salesforce enhancements mesh with the organizations roadmap. Some good resources to leverage in this activity are:

Idea Exchange: If you are having issues / desire a certain platform enhancement this can be a good indicator as to if your need will be delivered as an enhancement to the platform. Knowing this can provide guidance in how to proceed with a solution.

Release Notes: Review these with the team – gather team inputs – ensure the team is on the same page as far as new functionality and how it maps to your Salesforce org.

When it comes to determining the best technology to support a solution there are two thresholds that should weighed: Organization and Technical.

Organization Thresholds: How is the organization positioned for the solution? Factors to consider:

Team talent: Does the organization have the talent base to implement and support the solution? If not, should it?
Time to market: How long will it take to implement the solution? Will the timeline negatively impact the business?
Corporate policies: A few examples: Are there corporate requirements surrounding security that could impact the solution? Will there be issues if data in the Salesforce org ‘leaves’ the org for processing via an app?
Concept of future business needs: Understood, no one can tell the future. That said, try to have a concept of what business needs / requests may be coming down the pipe. Having this understanding can help you not box yourself into a corner architecturally.

Technical Thresholds: What limits / challenges does the supporting technology bring to bear?

Some factors are:

Governor limits: Take into consideration if platform limits will hamper the solution.
Salesforce suggested direction with technology: The platform is always evolving. Be aware of how platform evolution impacts current and future design.
Is the technology ‘too new’: Are you aware of downstream side effects or GAPS in the technology as they apply to the process it supports? Has the technology been proven elsewhere in a similar situation to yours? When considering technical thresholds mapping out the plus / minus between design options can prove helpful. For example, the following table depicts a comparison between deciding if Process Builder should take the place of a trigger / APEX class when updating related records:

We are visual beings. Seeing elements mapped out in this fashion can make decisions easier as well as provide documentation for the final solution.

Remember, moving forward thoughtfully can save you headaches down the road.

Written by Kevin Johnson, Lead Architect/Sr. CRM Advisor

With more than twenty years of experience Kevin is highly skilled in enterprise software implementations, system integrations, identification of business requirements, team leadership, and project management. As a Lead Architect and Sr. CRM Advisor at Demand Chain, Kevin is responsible for all aspects of new and existing client engagements including pre-sales engineering, strategy creation, requirement gathering, process engineering, system design and integration, testing, data migration, training and go-live support.