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

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

description

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

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

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

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

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

About MeI work for Cloud Sherpas as a Technical Director (APJ).

@sherod on Twitter

http://limitexception.com

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

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’

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

“Software architecture are those decisions which are hard to change”

- Martin Fowler

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

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

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

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

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

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!

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

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?

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

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.

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

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.

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

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

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

Conceptual ViewShows how the functional responsibilities are split across different systems and which systems are linked with each other.

This is your ’30,000 foot view’

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

Logical ViewShows 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)

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

Your Data Model

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

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

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

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

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

Conceptual

Account

Opportunity

Contact

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

Physical

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

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

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

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

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

‘Developers! Developers! Developers!’

-Steve Balmer

I.e. What not to do

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

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)

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

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

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

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”

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

Mockups/Storyboard

• Illustrate a flow• Allow people to visualise the end to end process• My Favorite tool:• Balsamic Mockups

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

‘Anti-Patterns’I.e. What not to do

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

“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

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

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.

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

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

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

“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

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

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