A quick Introduction to Architecture for Salesforce Admins. Presented to the San Antonio Salesforce User Group April 2014.

1. How do I architect?
Thinking about your Salesforce org from an Architectural perspective

2. About Me
I work for Cloud Sherpas as a
Technical Director (APJ).
@sherod on Twitter
http://limitexception.com

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. “Software architecture are those
decisions which are hard to
change”
- Martin Fowler

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. 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. 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. 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. 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. 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. 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. 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. 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. Your Data Model

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. 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. Conceptual
Account
Opportunity
Contact

18. Physical

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. 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. „Developers! Developers!
Developers!‟
-Steve Balmer
I.e. What not to do

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. 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. 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. Mockups/Storyboard
• Illustrate a flow
• Allow people to visualise the end to end process
• My Favorite tool:
• Balsamic Mockups

26. „Anti-Patterns‟
I.e. What not to do

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. 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. 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. “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. “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.