Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

"How do I Architect?" - Quick Introduction to Architecture for Salesforce Admins


Published on

A quick Introduction to Architecture for Salesforce Admins.

Presented to the San Antonio Salesforce User Group April 2014.

Published in: Technology, News & Politics

"How do I Architect?" - Quick Introduction to Architecture for Salesforce Admins

  1. 1. How do I architect? Thinking about your Salesforce org from an Architectural perspective
  2. 2. About Me I work for Cloud Sherpas as a Technical Director (APJ). @sherod on Twitter
  3. 3. Topics • What is good architecture? • The building blocks • Understanding your business • Your IT Architecture • A suitable Data Model • Dealing with developers • User Stories • Mockups • ‘Anti-patterns’ • Architectural fundamentalism • Enterprise mentality! • ‘You aren’t going to need it’ • ‘Don’t repeat yourself’
  4. 4. “Software architecture are those decisions which are hard to change” - Martin Fowler
  5. 5. A Good Architecture • Should tell a story where all the pieces fit together. • Some pieces may be easily swappable with no effect. • Some pieces may change the shape of the puzzle
  6. 6. What is „Architecture‟ • Architecture is not one size fits all, there are consistent broad practices but there is no 'right’ solution just solutions which are more or less appropriate depending on: • Your organisation’s capabilities • Your organisation’s drivers and motivations • Good Architecture is not everything! • Only solving the Right Problems with Good Architecture and Quality Execution = Great outcome
  7. 7. Forces at work • Creating an Architecture will often involve making trade offs between different elements • Understanding the key constraints/drivers will inform your decision making. • E.g. • “We only expect 50 of these to occur in the first year” • Perhaps no automation? • “This product is experimental, we want test the market” • Fast delivery, will probably be discarded? • “We’re going to have 80% growth in this in the next 3 months • Time to Automate!
  8. 8. Assessing a solutions • You will likely come up with multiple solutions • For each solution: • Is it a complete solution? • Does it fulfil the requirement? • Is it achievable given our internal constraints? (Time, money, skills) • Is it achievable given any technology constraints? • Does it add to our capability or restrict us in the future? • Does it reduce or increase our risks?
  9. 9. Impact Analysis • You have to weigh the ‘cost’ of a particular solution on benefit gained • For instance: Salesforce limits are like money in the bank. • Is it appropriate to ‘spend’ 100 custom fields on an object for an oddball requirement? • Would 50 lines of Apex stop you from consuming all the workflow rules on an object? • Does one solution offer a greater benefit for a lesser ‘cost’. • Costs are likely to be weighted, that is, using all of an unextendable limit is a greater cost than one that can be extended.
  10. 10. Governance! • Central review and oversight to weave the growth of the org into a coherent story • Decides what the system will and won’t be responsible and the compromises that are made to achieve a business goal • This concept has various names: • An ‘Architect’ or ‘A Product Owner’ or a ‘Champion’ or a ‘Governance Board’ or a ‘Business Owner’ • And various mechanisms • Change Requests, Cases, ‘Sprints’, etc, etc.
  11. 11. Your IT Architecture • Understanding the role of Salesforce inside your organisation • Understanding the role and responsibility of other systems • How they interact • System’s of Record / Sources of Truth
  12. 12. Conceptual View Shows how the functional responsibilities are split across different systems and which systems are linked with each other. This is your ’30,000 foot view’
  13. 13. Logical View Shows the specific IT systems and the data flows between each system. This is your ‘2000 foot view’. (The Street Level view would include which servers things run on and so forth)
  14. 14. Your Data Model
  15. 15. The role of the Data Model • Good outcomes and bad outcomes start with the Data Model • Starts as abstract concept and becomes more specific • Conceptual > Logical > Physical • Your Physical Data Model in Salesforce directly influences what is possible with Declarative Features vs what requires Custom Development, you must strike a balance between pragmatism and idealism
  16. 16. Layers of data model • What are the key entities make up the solution and how do they related to one another?Conceptual • What is the cardinality of the relationships (e.g. 1 to many)Logical • Object names, Field names, exact data types (date/numeric), Sizes (255 Chars)Physical
  17. 17. Conceptual Account Opportunity Contact
  18. 18. Physical
  19. 19. Data model concepts • Modifying your data model later can have a significant impact on your solution. • With Salesforce the more flexible your data model the more code you need to write. • Many to Many relationships = Custom UI to be used efficiently. • What concepts is your data model capable of representing? • Zero to Many • Account Hierarchy • One to Many • Account + Contacts • Many to Many • Campaigns
  20. 20. Custom vs Standard Objects? • Start with • Understanding the Salesforce Standard Objects and fields and their ‘Special Features’ • If it walks like a duck and talks like a duck, its probably a Duck. • If it’s called a Duck but it walks like a chicken and talks like a chicken, its probably a Chicken. • ‘We need to keep quotes, but we won’t be using Opportunities, or Products or be sending Quote’s out of Salesforce’ • It’s probably not the Quote object • ‘We need to track Jobs, with email interactions and pass it back and forth between people ’ • I think you mean ‘Case’.
  21. 21. „Developers! Developers! Developers!‟ -Steve Balmer I.e. What not to do
  22. 22. Dealing with Developers • Developers are people too. • Helping them understand why you need something goes a long way to improving outcomes. • Your business, your motivations, your needs, your concerns • Listening helps • Developers may find logical flaws in your approach or flag risks • Computers don’t handle concepts like ‘sometimes’ and ‘maybe’ which people are fond of. • Judging a developers progress • “Show me” • Walkthroughs, demos, iterative release. (Agile)
  23. 23. Good Practices • Naming conventions will help you organise your org • What you name something can live with you forever • Remember to add Descriptions everywhere it is possible in order to to self document your org
  24. 24. The User Story • Are a good way of expressing a requirement in a way that provides context and justification: • Usually in a standard form: • ‘As a <Job Role> I want to <some business process> so that I can <achieve some outcome>’ • E.g. • “As a Manager I want to be able to approve or deny an expense claim so that I can enforce the companies standards for acceptable expenses”
  25. 25. Mockups/Storyboard • Illustrate a flow • Allow people to visualise the end to end process • My Favorite tool: • Balsamic Mockups
  26. 26. „Anti-Patterns‟ I.e. What not to do
  27. 27. “Cargo cult programming” • Cargo cult programming can also refer to the results of applying a design pattern or coding style blindly without understanding the reasons behind that design principle. Examples are adding unnecessary comments to self-explanatory code, adding deletion code for objects that garbage collection would have collected automatically with no problem, and creating factory objects to build simple objects. It often happens when programmers are inexperienced with the programming language, or simply overzealous. • Wikipedia
  28. 28. Architectural Fundamentalism • “A idealist is one who, on learning a rose smells better than a cabbage, concludes it will make a better soup” • E.g. • “We don’t use Flow” • “All <problem > must be solved with <xx>, no exceptions” • When you decree your standard tool is a hammer, you better hope you only need to hit nails. • Taking the long way around to solve a problem is not better.
  29. 29. Complexity = Enterprise = „Grown up” • The more moving parts you have, the more things that can break. • Adding complexity increases fragility • KISS principle: Keep It Simple Stupid
  30. 30. “YAGNI: You aren‟t going to need it” • Do Think/Plan ahead • ‘Roadmap’ • ‘Strategy’ • ‘Mission statement’ • ‘Architectural principles’ • Don’t build it until you need it. • An actual need > than an imagined need. • Although you need to do a risk assessment on ignoring a need
  31. 31. “Stay DRY (Don‟t repeat yourself)” • Single sources of truth • At the Macro Level • Duplicate Systems (Salesforce AND Zoho) • At the Org level • Duplicate managed packages (Docusign AND Echosign) • Duplicate fields • Duplicate objects • Duplicate code. • A good architecture avoids duplication at all levels.