They Call It Enterprise For A Reason English

945 views
880 views

Published on

Salesforce.com Dreamforce 2010 Developer Track Presentation: alesforce and Force.com have a great reputation: easy to configure, fast to develop with, and marketed with an "anyone can do it" paradigm—all true. But just because something is easy and fast doesn\'t mean it should be treated in a cavalier manner. In other words, just because you can put 500 validation rules on an object doesn\'t mean you should. This session will focus on bringing best practices for enterprise systems to bear when developing on the Force.com platform. Join us to learn about using a standards-based approach to coding, data modeling, and architecting as well as separation of concerns, test-driven development, and more.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
945
On SlideShare
0
From Embeds
0
Number of Embeds
38
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

They Call It Enterprise For A Reason English

  1. 1. They Call it "Enterprise" for a Reason<br />Developer<br />Don Robins<br />Outformations, Inc.<br />www.outformations.com<br />
  2. 2. Safe Harbor<br />Safe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.<br />The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of intellectual property and other litigation, risks associated with possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year ended January 31, 2010. This documents and others are available on the SEC Filings section of the Investor Information section of our Web site. <br />Any unreleased services or features referenced in this or other press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.<br />1<br />
  3. 3. How Big Is The Enterprise<br />2<br />
  4. 4. Which One?<br />3<br />Image credit –www.cygnus-x1.net : Monte R. Johnjulio<br />
  5. 5. How Big Is Big?<br />How Many of You Have…<br />Total # of Users > 100, >500, >1k<br />Total# of Integration Points > 1, >5, >10<br />Other Benchmarks…<br />Total # of Standard + Custom Objects<br />Total # Custom Workflows<br />Total # of Triggers, Classes, VF Pages<br />Total # Records<br />4<br />
  6. 6. How Big Is Big?<br />How Many of You Have…<br />Followed in someone’s footsteps who is not available anymore? <br />Been baffled by something you found in your org?<br />Broken existing functionality when trying make a change?<br />5<br />
  7. 7. Large scale Salesforce.com and Force.com implementations require a different approach:<br />You need to think differently <br />Why and How to think differently<br />We need to amend the Marketing Message: <br />“…it’s so easy!”<br />Objective: Share My Perspective<br />6<br />Image credit – Apple, Inc.<br />
  8. 8. Objective: Take Away(s) For You<br />Perspective: (What)<br />Size : Complexity : Dependency : Risk<br />Understanding: (Why)<br />You need tomanage complexity<br />Ideas: (How)<br />Change your approach<br />Managing expectations differently<br />Adopt new standards, practices and methods<br />7<br />
  9. 9. Who Am I?<br />Co-Owner & Principal Consultant of Outformations, Inc.<br />25+ years experience <br />Chief Architect, Development Team Mentor and Trainer<br />Certified Salesforce Developer & Certified Agile Scrum Master<br />What Do We Do<br />Custom Software Solutions <br />Agile Business Consulting<br />Developer mentoring and training<br />Clients of all sizes, shapes and industries<br />We love moving customers into the cloud w/ Force.com<br />8<br />
  10. 10. What Does 'Enterprise' mean?<br />Many Objects:<br />users, features, screens, reports<br />Many Complexities:<br />security, business rules, workflow, reporting, output<br />Many International Issues: <br />multiple locales, currency, time-zone issues<br />Many Integration Points:<br />other cloud systems, ERP databases, etc.<br />And of course - oodles and oodles of data<br />9<br />Image credit – Wenger<br />
  11. 11. “Salesforce Development Is SO Easy!”<br />Salesforce.com marketing message:<br />'easy' to configure<br />'rapid' to develop with<br />'anyone can do it' <br />‘No Software’<br />It’s all true - that's why we love it<br />BUT – we must Amendthe Marketing Message:<br />Applies to Salesforce<br />Does NOT apply to complex systems<br />10<br />Image credit – Quantum360.co.uk<br />
  12. 12. What’s The Problem With Big?<br />Big things tend to get Complex<br />Complexity grows in an arbitrary manner<br />Growing Complexities create Dependencies<br />Gets harder to track everything<br />System elements typically become more coupled<br />Changes have unintended impact <br />Technical debt can grow <br />You will have to pay: <br />How? When? At What Cost? You can't know!<br />11<br />Image credit – OpenORB.sourceforge.net<br />
  13. 13. What is Technical Debt?<br />‘...eventual consequences of slapdash software architecture and hasty software development.’<br />12<br />Image credit – my.digitalface.ca<br />
  14. 14. Arbitrary Changes = Technical Debt <br />13<br />Image credit – my.digitalface.ca<br />
  15. 15. Technical Debt Scenario<br />Someone needs and requests a ‘simple’ change<br />You 'solve' the problem with a quick solution as expected<br />The solution adds another moving interconnected part<br />This happens again and again and again over time…<br />APEX logic may become redundant<br />You plan to ‘fix’ or ‘improve’ it later, but ‘later’ never comes!<br />Complexity grows introducing unforeseen dependencies<br />Changes introduce unintended impact<br />Tests start failing when you go to promote new code<br />Deployment and implementation changes become impeded<br />Eventually your system implodes (‘forecloses’) on itself…<br />14<br />Image credit – my.digitalface.ca<br />
  16. 16. Technical Debt Examples<br />“We just need one more <fill in the blank><br />‘just one more validation rule…’<br />‘just one more field’<br />Changing Picklist values w/o verifying dependencies<br />Making arbitrary APEX Changes<br />Adding new triggers<br />Bloating your classes <br />Adding new (and potentially) redundant logic<br />There will be implications! – So what do you do?<br />15<br />Image credit – my.digitalface.ca<br />
  17. 17. Adopt Development Best Practices<br />Accept Salesforce.com as Enterprise class product<br />Supports complex systems; your system will get complex!<br />Set expectations accordingly for everyone<br />A cavalier approach will have implications<br />Learn Enterprise software development practices<br />Supports development of complex applications<br />Been around for years and have evolved over time<br />Allow scalability and management of growing complexity<br />Perfectly applicable to Salesforce <br />Applies to BOTH Configuration and Coding<br />16<br />Image credit – consulting-plus.com-au<br />
  18. 18. Adopt Development Standards<br />Set your standards – any good set of standards will do<br />All team members should follow them when: <br />Designing<br />Data modeling<br />Configuring<br />Coding<br />Enforce with all users allowed to configure!<br />Make the risks visible and set expectations for ALL!<br />Easier to accept when we know their purpose<br />17<br />Image credit – consulting-plus.com-au<br />
  19. 19. Adopt Naming Conventions <br />Establish naming patterns in Declarative Programming<br />THINK when naming custom object and fields<br />Caption vs. Fieldname<br />User vs. Programmer<br />Same for Programming Components<br />Use naming patterns for collections of related classes<br />Organize Triggers, Classes, Pages, Components by name<br />Name test classes after the class that they test<br />ex. MyPageController and MyPageController_Test<br />Keeps them together and searchable <br />18<br />Image credit – www.squidtank.com<br />
  20. 20. Reduce Complexity Where You Can<br />Just because you can…doesn’t mean you should: <br />DON‘T add hundreds of fields on an object<br />DON‘T have dozens of validation rules on an object<br />As you decrease…<br /> Fields, Rules, Complexity<br />You may increase…<br />Performance, Usability, Maintainability<br />Understand that complexities need to be managed<br />19<br />Image credit – www.emergebuzz.com<br />
  21. 21. Analyze Potential Dependencies<br />Think before you click!<br />Do analyze and vet change requests with your users<br />Don't arbitrarily accept change requests<br />Make sure there is clear business value<br />Do user reviews showing available options<br />Share understanding about dependencies and risk<br />Provide alternate options and build prototypes <br />Don’t give in to the argument: <br />‘But it should be so easy to do…it’s Salesforce!”<br />Don’t ‘code’ when you can ‘click’…<br />20<br />Image credit – planebuzz.com<br />
  22. 22. Leave a Trail (Declarative)<br />Capture and Communicate<br />Keep complexities and dependencies visible! <br />Leverage documenting meta fields<br />Fill in Description and Help on ALLobjects<br />Validation Rules, Approvals and Workflow, etc. <br />Be explicit<br />Don’t be overly verbose<br />21<br />Image credit – www.legaljuice.com<br />
  23. 23. Leave a Trail (APEX)<br />Comments in APEX code inform at a glance BUT:<br />Use comments with care<br />Misleading if outdated<br />Don't say ‘what’ or ‘how’… <br />Say ‘why’<br />APEX code limit<br />22<br />Image credit – www.legaljuice.com<br />
  24. 24. Leave a Trail (APEX)<br />Use consistent naming conventions and patterns<br />Methods, properties and variables should self document<br />Name properties for what they contain or represent<br />Names CAN be long<br />23<br />Image credit – www.legaljuice.com<br />
  25. 25. Adopt an Architectural Approach<br />Use Design Principals to help Manage Complexity:<br />Separation of Concerns (SoC)<br />Single Responsibility Principal (SRP)<br />Don’t Repeat Yourself (DRY) <br />Use Good Coding Practices for Maintainability<br />Self Documenting Code<br />Avoid String Literals (use constants and enums – not picklists)<br />Regularly Refactor your methods and classes<br />Keepclasses and methods light weight <br />Code for ‘understandability’ not ‘terseness’<br />24<br />Image credit – consulting-plus.com-au<br />
  26. 26. Adopt an Architectural Approach<br />Leverage Enterprise Coding Patterns<br />Designed to manage complexity<br />Provide consistent frameworks to 'know' where things go<br />And where to find them later when needed<br />Adopt a Modular Approach(APEX)<br />Promote reusability : reduce redundant code<br />Data Access Services: encapsulate SOQL and DML logic<br />Domain Managers: encapsulate domain logic<br />Utility Libraries: reusable functions<br />Service Libraries: reusable services<br />25<br />Image credit – consulting-plus.com-au<br />
  27. 27. Example: Separation of Concerns<br />SoC is NOT just Model/View/Controller (MVC)<br />Over arching architectural approach<br />Create modular code components<br />Decouple your logic whenever and wherever possible<br />Push business logic beneath triggers and controllers<br />Treat APEX like a first class OOP language<br />Build test classes for each modular APEX class <br />Makes everything more testable<br />26<br />Image credit – blogofpaul.merecomplexities.com<br />
  28. 28. Trigger<br />Rules<br />Helper Logic <br />SOQL<br />DML<br />Typical Architecture<br />VisualForce Views<br />Controller<br />Actions<br />Navigation<br />Rules<br />Helper Logic<br />SOQL<br />DML<br />Trigger<br />Tests <br />Controller<br />Tests <br />27<br />
  29. 29. Modular Architecture<br />VisualForce Views<br />Trigger <br />Trigger<br />Tests <br />Controller<br />Controller<br />Tests <br />Service<br />Service<br />Tests <br />Manager<br />Tests <br />Manager<br />Repository<br />Repository<br />Tests <br />Utility<br />Utility<br />Tests <br />28<br />Image credit – outformations.com<br />
  30. 30. (Really) Test Your Code<br />TRUTH or DARE: How many of you:<br />Write your tests AFTER you've written your APEX classes?<br />Have failed a deployment because of unexpected lack of coverage?<br />Maintain only ONE test class for MANY APEX classes or triggers?<br />29<br />Image credit – consulting-plus.com-au<br />
  31. 31. (Really) Test Your Code<br />Many developers write their tests AFTER THE FACT<br /><ul><li>WRONG APPROACH:</li></ul>To get the coverage when needed to deploy<br />Write your tests AS you write your code<br /><ul><li>RIGHT APPROACH:</li></ul>Use tests to develop your logic<br />Use tests to prove your logic actually works<br />Grow your test coverage with your codebase<br />Run ALL your tests regularly <br />TESTING IS NOT JUST FOR PROMOTING CODE!<br />30<br />Image credit – www.anug.dk<br />
  32. 32. Code With Intent<br />What is Test Driven Development (TDD)?<br />Writing your tests as you code HELPS you develop your logic<br />Leverage the concept of ‘emergent design’<br />TDD approach can help you 'code with intent' <br />You must think about what you’re coding<br />Prevent wasted effort and code bloat<br />Robust set of tests for regression testing<br />Provides security (and peace of mind) with change<br />Our applications will need to be managed for many years<br />Writing Code = 20% vs. Maintaining Code = 80% <br />31<br />Image credit – consulting-plus.com-au<br />
  33. 33. Adopt Agile Project Management<br />Develop and maintain a Product Backlog<br />Highest priority/value items<br />Work in short iterations (sprint)<br />Tight feedback loop<br />Commit to only what your team can complete<br />Realistic and sustainable pace<br />The team touches base daily with project owner<br />Visibility of progress and impediments<br />Perform Demo and Retrospective at end<br />Do it again… get better…get faster…get predictable<br />32<br />Image credit – consulting-plus.com-au<br />
  34. 34. Benefit From an Agile Approach<br />Promotes the delivery of Business Value<br />Forces prioritization from the business perspective<br />Maintains visibility and raises impediments daily<br />Identifies where the real problems are (often not the tech)<br />Improves team performance and delivery<br />The team gets better and faster – more predictable<br />Insures rapid user feedback of whether you’re on track<br />Helps manage ever-present changes<br />Reduces un-necessary features + less waste = less cost<br />Change is a ‘Given’ - don't fight it; embrace it.<br />33<br />Image credit – consulting-plus.com-au<br />
  35. 35. In Summary<br />Manage the expectations of your users and managers<br />Let them know what they're really dealing with<br />Learn to manage and leverage the platform<br />Don’t let it manage you<br />Adopt an Enterprise approach for an Enterprise platform<br />It’s built for scalability - that's why you use it<br />They call it Enterprise because it IS<br />Treat it as such<br />34<br />Image credit – www.infovark.com<br />
  36. 36. Take a Minute<br />Please fill out the session survey. <br />It helps us learn about how to improve this information.<br />35<br />Image credit – www.eizie.com<br />
  37. 37. Questions? <br />Stay after<br />Talk at lunch<br />Find me on Chatter (or LinkedIn)<br />Email me at dbr@outformations.com<br />My website http://www.outformations.com<br />I will post follow-up links and info in Chatter<br />Post your questions on the Chatter Feed<br />36<br />Image credit – www.clipartof.com<br />
  38. 38. Don Robins<br />Outformations, Inc.<br />www.outformations.com<br />

×