9 Principles for Salesforce Application Architecture
Download as PPTX, PDF1 like1,190 views
The document outlines nine application architecture principles for the Salesforce Lightning platform, emphasizing the importance of licensing, internal architecture, data modeling, and security. It advocates for using Salesforce's built-in capabilities, and suggests a nuanced approach to configuration and code utilization while promoting thoughtful use of AppExchange products. Additionally, it recommends regular updates to incorporate new features and to document governance processes to ensure clarity and adaptability in architectural decisions.
9 Principles for Salesforce Application Architecture
- 1. 9 Application Architecture Principles for the Salesforce Lightning platform Dreamforce, 2019 Steven Herod
- 2. Steven Herod Managing Director Certified Technical Architect @sherod
- 3. Where these principles fit in relative to others The 9 Principles Summary Agenda
- 4. What are principles? A fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning.
- 5. Relative to other principles Apex and Specific Tech Salesforce Application Architecture Enterprise IT Principles YOU ARE HERE Principles
- 6. Principle 1: Licensing leads the way Impact on Solutioning Understand the licensing which has been purchased, this drives the Macro and Micro choices in the architecture. Identify the shortcomings in the licensing to understand solution risks and trade offs and to clearly articulate them to stakeholders. Solutions options to incorrect licensing can run from sub- optimal to fatally flawed. Commercial solutions to licensing issues are preferable over any technical solution. Everything that is delivered is shaped positively or negatively by the customers licensed product set. 6
- 7. Put another way… Bad Licensing Building lots of compensation More complex answer 7
- 8. Principle 2: Internal Architecture is essential Impact on Solutioning The structure of an org should be broken down into separate sub-systems with clear functional responsibilities. This separation should flow into the structure of the design and solution and then the structure of the team. Fundamental to this is explicit definition of responsibilities with an sub-system and interactions between sub-systems. Every implementation should have an explicit application structure to its components with boundaries. 8
- 9. For example… 9 Community Blogs Collaboration Product Management Registration Gamification Notifications
- 10. Principle 3: Start with the Data Model Impact on Solutioning Data model design is a trade off between Declarative Functions, Security and Integration. Where trade-offs have been made, they must be documented. Create and maintain a data dictionary and up to date ERD. Have specific processes in place for managing identifying ‘hot objects’ (Shared objects/High Data volume objects/Objects approaching limits/Objects with significant automation/trigger activity.) The data model will enable or constrain all security, declarative, reporting and API/Integration solutions.
- 11. Principle 4: Security from the Beginning Impact on Solutioning Start with a default view of Private as it is easier to open up than close down. When solving for Security issues, aim to reduce the number of rules defined, relying on a natural flow: Role Hierarchy then Groups Sharing Rules then Apex Managed Sharing Programmatic enforcement or override of the security model should not occur. Avoid manual sharing The security model cannot be ‘added in’ later, you should start with it in mind.
- 12. Principle 5: Start with, and use the Product Impact on Solutioning Salesforce offers an extremely rapid development using its natural feature set and ways of working. Many, if not most, user requirements have a ‘standard’ way to address the concern. User Stories or Requirements should be played back or demonstrated using these capabilities before development activities are considered, or consider such extensions in later phases when the need is proven. What can be used as delivered by Salesforce, should be used.
- 13. Principle 6: Configure, Extend, Enhance but rarely Replace Impact on Solutioning Many conversations about Salesforce are driven into a dichotomy of Configuration vs Customization. That proposes an 'either/or' way of looking at solutions, and it is usually used associated with "right" and "wrong". We suggest a more nuanced way of thinking about things, using the acronym CEER If you were to take a list of User Stories or Requirements, and for each of those items, mark them as Configure, Extend, Enhance, Replace, then you would build a profile of the nature of your Salesforce implementation and this will help expectations be met. Avoid the ‘Configuration vs Customisation’ false dichotomy
- 14. Principle 7: Code is not to be feared Impact on Solutioning Avoid ideological driven rules on code vs config and setting fixed percentages of functions delivered by code. Consider using the 'CEER' framework to reframe the conversation. Recognise that quality code can dramatically improve a complex declarative solution. In particular, you will need to use code to bridge complexities in Data Model, to improve or tailor the User Interface and to scale Process Automation, in particular in relation to large data volume, or per-transaction performance. Code is a part of the solution, a necessary requirement for performance or simplicity.
- 15. Principle 8: Use the AppExchange with care Impact on Solutioning Care should be taken to make sure AppExchange products are cleanly integrated using the vendor’s public interfaces. Extension via ‘interception’ (Apex Triggers) and creativity is fragile and should be avoided at all costs. Keep in mind that limits are shared between your extensions and AppExchange products, this must be considered when planning solutions. The AppExchange is powerful, but it should be used thoughtfully.
- 16. Principle 9: Adopt new features, retire old ones Impact on Solutioning Avoid adopting Pilot or Beta features outside of POC and experimentation work as they are generally not functionally ready for complex use. Move to replace depreciated features with their newer alternatives as soon as you can as reliance on them tends to cause accumulated legacy. Up to 5-10% percent of your ongoing operational effort could be focused on uplift To stay ready, keep an eye on the seasonal releases and know when to move.
- 17. Summary Decide and document your principles • Via your governance processes Distribute and explain your principles • To those beyond the team who decided them Debate the impact of decisions against them • Only simple problems have unambiguous answers. Document your decisions • Referencing the principles for later discussion. Revisit your principles when foundations change
Editor's Notes
- #7: Explanation Salesforce licensing establishes the broad boundaries of the achievable Application Architecture.. Choosing correct license is the key decision to be taken for designing any solution in salesforce. It’s essential that the high level capabilities required of the solution fit well with the licensing acquired as it drives solution to use of more native features, more secure and performant solution and lower code. When a sub-optimal license is chosen, solutions can be deeply compromised. This manifests itself in two ways: An overly optimistic selection of a ‘Limited Use’ license where the actual need exceeds the expectation of ‘limited use’ A conscious choice to avoid a license set to ‘build out’ the capability in custom development. Licensing work arounds manifest themselves as: Excessive code, as standard functionality is replaced with custom functionality. Excessive consumption of limits, as available functions are ‘overloaded’ with additional responsibilites. Compromised security, as security model features which are not available, are worked around (Communities)
- #9: Explanation In most occurrences, a Salesforce solution is deployed to a single production instance or ‘org’. Whilst progress has been made with modular packaging, Salesforce lacks native support for namespaces or modularisation to enforce the separation of concerns between sub-systems. Thus, whilst the solution may logically be considered to have separate sub-systems when described conceptually, its runtime implementation can often lack a recognisable structure within metadata and code. As a result Application Architects must impose structure using design and convention with particular attention at understanding the points at which sub-systems interact. Specifically: Ensure your solution has an identifiable structure with clearly defined responsibilities which build a coherent picture. Ensure this structure is reflected in documentation, sub-system naming conventions and a clear understanding of boundaries and interactions between sub-systems. Recognise that design can emerge, and that refactoring will be a natural part of the design process, albeit one which can often be difficult to justify in cost/time constrained situations.
- #11: Explanation Good outcomes and bad outcomes start with the logical data model for a system and the physical representation within a Salesforce Org. This physical data model in Salesforce will either enable declarative features e.g Cases or require custom development e.g. Role. In design you must strike a balance between pragmatism and idealism. In general, adapt more general logical/objects models must be tailored to the specific capabilities and constraints of Salesforce. Specifically: An emphasis on Parent/Child relationships. A smaller number of ‘wider’ objects (More denormalization) Use of Record Types to provide polymorphism within an object. Use of Picklists for Enumerations rather than lookup tables. Careful use of Many-to-Many relationship which impact declarative UI capabilities Avoid all forms of duplication, in either objects or fields, except where explicitly chosen to mitigate performance issues. Use Master-Detail relationships only when specific requirements drive the need and data volumes/locking concerns are mitigated. Governance of this data model and its measured change is key to success. These issues is not a technical problem, but organisational.
- #12: Explanation Security has fundamental impact on the behaviour of the system and the security model should be well understood with choices explicitly made and documented. Poorly understood security models result in potential disclosure of sensitive information, missing functions/fields or performance issues. At its core, the Security model fundamentals starts with the Licensing. Once this is understood the Profile/Permission Set model is the next major area. Use Profiles sparingly, and only for the functionality which is required (i.e. 1 per licnese type). Favour Permission Sets for their abilities to support Packaging and Deployment and for their ability to be layered. Structure Permission Sets by functional capability and not be Job Role. Prefer Private or Public Read Only sharing models over Public Read/Write. Remember the Role Heirarchy and Organisational Wide Defaults are only applicable to Private/Public Read Only and extremely difficult to reverse apply to an existing system. The Role Heirarchy should reflect the data access model and not the companies organisation model. Recall that recalculating of Sharing, as occurring during mass data changes, ownership changes or role changes is a time consuming
- #13: Explanation Salesforce is both a Product which provides solutions and a Platform on which solutions can be built. In both cases its out of the box capabilities provide the basis of any solution. Whilst the conscious choice to replace functionality can be valid, it should be secondary to knowing of and using Standard functionality. Check release notes and use product specialists to understand system capabilities and verify them using short proof of concepts. Remember that standard Salesforce objects such as Account, Lead, Contact, Opportunity, Case have special behaviours which cannot be replicated in Custom objects. These objects are also most commonly relied on by AppExchange products for extension or integration. When extending these objects or integrating with Standard objects, take special care to ensure you are preserving capability. In general, avoid repurposing Standard Objects for ‘other means’ (For instance, making the Case object a ‘Work Order’), as more general use of them in subsequent phases will be difficult. Custom Objects have little to no cost but avoid excessive numbers by making use of record types to collapse many similar objects to a single Custom Object. Avoid using this approach to collapse significantly different objects. Use the demand to reduce customisation to drive conversation and solutions back to standard functionality and consider alternatives only if the integrity of outcome is at risk.
- #14: CEER Configure The functionality is supported using ‘no logic’ setup of Salesforce, such as default lead owner, page layouts, field level security, lighting apps. Extend Logic processing functionality, such as Process builder, Workflow rules, Lightning Components and Apex Code Enhance The introduction of managed packages and third-party solutions to add net new functionality. Such as Conga, CloudSense, Vlocity, Replace The wilful replacement of any out of the box functionality with development work. Such as: Building your own workflow processing engine, Page Layout editor, UI Framework, Security Model implementation. Replace is the category of change that should be avoided unless it is acknowledged as a Replacement and formally accepted as a design choice. For example: Most Configure/Some Extend Standard Salesforce implementation using Sales or Service Cloud. Some Configure, Most Extend Integration with external systems, migration of internal Applications into Salesforce. Most Enhance, Some Configure and Extend Deployment of a Managed Package which is providing most of what the client wanted to do. Some Enhance but much Extend A poorly fitting Managed Package, do you have the right product? Much Replace Has the client understood the platform?
- #15: Explanation Many customers object to code on principle, shaped by experiences on traditional ERP platforms where code means lock-in or by overly optimistic marketing from Salesforce. The reality is that developing extensions to Salesforce in code (Apex/Visualforce/Lightning) does not have the same impact, in particular, it does not prohibit upgrades of the core functionality. Seek the simplest solution for a problem, that is consistent with the patterns already established, and in line with the non-functional requirements (volume, performance) and based on your available skillsets, not on the expectation that ‘clicks’ are easier than code.
- #16: Explanation AppExchange products enhance Salesforce’s capabilities by adding either specific point functionality (such as document generation or e-signature) or by tailoring Salesforce to domain-specific needs (Such as Insurance Claim system). AppExchange products can be simple and low impact or have a significant footprint across an entire solution. Understand that different, complex, managed packages often have conflicting points of view on data model usage (For instance, on how Account/Contact is used) and can duplicate functional areas (i.e. UI frameworks or Business Process Management/Workflow capabilities). It's essential you verify that products can co-exist both logically (they use standard Salesforce features the same way) and physically (they do not, collectively, consume all available capacity.
- #17: Explanation Salesforce is one of the few platforms that automatically improves in capability 3 times a year. This means that a continued eye must be kept on taking advantage of new capabilities and opportunities. New features may render previous Extensions/Configuration no longer necessary, meaning that bespoke work can be removed and replaced with out of the box features. In limited cases, some features may become retired/depreciated.