Salesforce Technical Architect Best Practices (Part 1) : Building Center of Excellence

Having gone multiple channels and adoption of Salesforce in wide domains. I started pointing down the common  features and practices that are applicable to any organization who have invested million in adopting Salesforce.com Platform. Again, this is very broad topic to discuss, but with my experience in dealing with multiple Architects, CIO's and sessions. I developed few practices and conclusion that is channelized through this series of post, I am writing series of post, which cover wide aspects of Salesforce ranging from building the team, organization and roadmap for implementation. I'll cover best practices, strategies on multiple aspects that an Architect have to think through while carving this platform for any organization.>

Thinking like an architect or CIO is dramatically different than a Lead Developer/Senior Developer, as you grow as an Architect one have to think wide aspects of technology, this is more like building your own startup. Architect become guide and key advisor, he have to be a visionary and should stay on top of latest and greatest of the standards, frameworks, libraries and platform.

Below are the few areas that an Architect have to think, which a lead/senior developer might have not to think through are

platform adoption, scalability, building support, releases management,platform integration practices, code versioning, architectural design standardization, language design pattern, technology stack, best practices in Salesforce, UI/UX, code reuse, modularization of components , SSO/SAML linkage, security standards,licensing, documents management and more

In these series, ill cover majority of those aspects listed above, but from 1000 feet above. As we know, every company differs in their model, standards, practices. For example in my current role, I work with a Health Care company approved by FDA, the legal regularity practices block us to deploy code in production instance, until we go-live due to FDA validated system. Clearly, blocking a  soft deployment of code/package in production instance, creates a huge pain for us. Creating new sandbox become nightmare, application lifecycle, package deployment and management become huge pain. So these are set of complexity that architect have prepare him/her self with Salesforce Cloud model which is not very matured in many capacities.

Center of Excellence

________________________________________________________________________________

Building a strong governance model for Success

In here, I cover these areas that are to be considered in building Center of Excellence or Salesforce Experts Team that handles release, support and cleanup of applications as it grows.

• Internal Support Process (Tiers of Support)

• Salesforce Product Support

• Building Salesforce Release Management for new features rollout

• Release Planning

• Building Sandbox Landscape Management Process

• Salesforce Licence Count Managment

• Data and File Storage Management

• Reports and Dashboard 

Define Salesforce Tiers of Support 

________________________________________________________________________________

Define level of support 

Build a process for Internal users to log a ticket, when they encounter any issues. You can use any ticketing system, that your company is using for Application Lifecycle Management.

Build Process for Users to log tickets when they encounter any issues 

• Identify the System that will track tickets 

• Train Users as part of Go Live how to leverage this system for logging tickets

Build Tiered Support Process and Escalations

• Tier 1 – Regional SME  Support (feature enable/profile, security model support)

• Tier 2 –  IT BA Support

• Tier 3 – IT Developer Support 

Issues vs. New Feature request

Create a Process to feed new feature request from Issues logged by users. 

Salesforce Product Support

________________________________________________________________________________

Identify, what your internal team can support, and how to handle the support you need to escalate to Salesforce as a product bug or enhancement. 

Have Tier 3 Identify if the issue is related to any feature that Salesforce Platform related and not to the customization built by your company

• Your company System Admin to Log case with Salesforce

• Salesforce Support will address these issues

• Salesforce Support Notifications

• Ensure you Administrators have setup their Notification preferences for Salesforce Product Notifications

• Approved Support Contacts Resources can contact Salesforce Support team

• Ensure you are notifying Salesforce Support about any changes in your approved Support Contact Resources

Salesforce Release Management

________________________________________________________________________________

Planning Release in Cycles with Salesforce Quarterly Releases 

Salesforce Release Management, is fairly the most complex system that I came across, if you come from Java/Rails background this is not fairly similar to that and as streamlined. Key reason behind is, that your code compiles on cloud, which in turn leverage have high probability of some or other resource may step up on each other code. Also, sandboxes have 'no-connected' code/config transport mechanism as matured (change set are not scalable) for big landscape, like SAP and Oracle have. Clearly Release Management becomes critical and complex, when you also deal with Github/BitBucket and have continues deployment (which include continues integration, continues testing) plugged in.

Below are few practices you have think about 

Track Request

• Track new Feature request and bubble them to your releases 

• Build a process to gather feedback from users on existing features and new features

• Track the Feedbacks and have conversions around the Feature requests

• Promote the feature that is liked by most of the users as product functionality 

Building Timeline for Release

• Build timeline based Release Management Process for new Features

• Build a release management process that helps rollout new features 

• Release Configuration based features in a Minor release

• Release Development or Integration related features in Major release

• Alternate Major and Minor Release 

• Do not have release the month Salesforce Product does its Releases

Salesforce Release Planning

________________________________________________________________________________

Production Support 

Immediate Release to support Production Instance

• Development and QA Environment to support

• Only for Hot Fix/Patch for Production Issues

You have plan your releases alternative, primarily you can categorize them in Major and Minor Release

Major Release (3 Month)

• Long release cycle and dependencies to other application. 

• Integration/middleware development

• High impact on Change management, UAT and Training

Minor Release (1 Month)

• Salesforce Configuration based changes 

• Small impact to users and does not need training

Sandbox Refresh and Naming Conventions

________________________________________________________________________________

Appropriately Name your Sandboxes

• Name Production Support Sandboxes with Prod or P in the name (Example SFPD1 and SFPQA1) 

• Alternate SFPD1 and SFPD2 for odd and even release environments. 

Release Sandbox

• Name Major/Minor Release with Odd or Even Number appropriately
• Having Release numbers help identify product Feature enhancements and track them easily in your PMO Application  
• Refresh Sandboxes often
• Refresh Sandbox before each release start from Production 
• Leverage Additional Sandbox to alternate Releases while keeping prior Release Sandbox environment

Managing Salesforce License Counter for Users

________________________________________________________________________________

Plan your license, api user, deployment users. Consume license carefully, always keep buffer of extra licenses, make use of chatter user license when needed.

• Monitor Usage of different types of License 

• Build Reports to identify usage of Licenses 

• Ensure you have sufficient Licenses for key Application users

• Integration Users

• Administrators

• Deployment Users

• Data Migration User

• Always have extra Licenses available to manage Organizational Growth

• Leverage additional License Types for building custom applications

• Chatter Only and Platform Licenses give you flexibility to expand your Salesforce footprint in your Organization 

Salesforce Data and File Storage Management

________________________________________________________________________________

hen needed. Plan storage scheme for data and files storage.

•  Build Strategy for monitoring Storage Volumes for Data 

•  Identify the Objects for Data Retention and Arch rivals 

•  Master Data should reside in Salesforce 

•  Transactional Data to be Archived frequently to Data Warehouse 

•  Work with Enterprise Warehouse and Business to identify the Data Retention policy 

•  Create Data Archival Process and Interface 

File Storage Management 

•  Build Strategy for monitoring Storage Volumes for Files

• Files to be Archived frequently to Data Warehouse or SharePoint 

• Work with SharePoint/Enterprise Warehouse and Business to identify the File   Retention policy 
• Create File Archival Process and Interface

Reports and Dashboards Cleanup

________________________________________________________________________________

Report and Dashboard rollout and cleanup

Enterprise level Reports and Dashboards

• Create Reports and Dashboards for Global Enterprise Rollout 
• Naming convention standards for Reports and Dashboards
• Create Folders and access to users
• Review Report usage and enhance reports frequently
• Train user not to modify Enterprise reports instead create custom reports in their personal Folders

Cleanup of Reports and Dashboards 

• Create a process to identify reports and Dashboards which are not used
• Build a process to clean reports those are no longer used
• Notify users before cleanup process starts 
• Publish a list of reports being cleaned up
• Perform Cleanup Frequently

Stay in tune for continuation of series and chain of topics in upcoming posts.