Force.com is changing the way software is written and deployed. Companies are realizing the enormous advantages of deploying business applications in very short timeframes without having to invest in hardware, software, and IT infrastructure – let alone the number of people it can take to maintain on-premise solutions. Thanks to salesforce.com, building and deploying a SaaS application has never been easier.
However, to realize the ROI, it is essential to understand the SaaS model and the technologies behind it. Force.com is a paradigm shift and, as such, requires a different way of architecting, designing and building your application, to experience success. You must understand these differences upfront and avoid the pitfalls. Here are the top 10 architecture mistakes to avoid during critical stages of initial decision-making, designing and developing your application.
Mistake #1 – Not leveraging the automatically generated screens to reduce development time
Visualforce allows you to design any conceivable user interface. Most designers tend to create complicated screens by replicating the look and feel of an existing application or idea. Custom screens have their advantages but can be time consuming and expensive to develop as opposed to using the screens that are automatically generated by the Force.com platform. For example, if you create a persisted object on Force.com, screens will automatically be created for all CRUD operations. Be sure to understand the trade-offs, based on the capabilities and workflows pre-built into the Force.com platform before making the choice to go custom.
Mistake #2 - Writing Custom Code instead of using Force.com configuration
Apex is a very powerful feature of Force.com. It provides the ability to write custom code for any kind of automation and functionality desired. However, like any other language, custom code will increase your total development/testing costs and timeframes. Spend some time in understanding declarative Force.com services such as alerts, workflows, validations and formula fields that can provide you with powerful alternatives to custom code. It will save you precious hours and dollars.
Mistake #3 – Jumping into development before building a Force.com prototype
The cost and timeline of building your app can vary drastically, based on design decisions and trade-offs. Force.com makes it easy to prototype key concepts of your offering within days. Building a prototype will help you get user feedback quickly on functionality and UI, and form the basis for design – more importantly it will help you size the development effort. Many consultancies offer free Free Force.com prototypes for large custom applications.
Mistake #4 – Using relational database design techniques in your Force.com app
Force.com provides the ease and flexibility to create custom objects and relationships. Most designers make the mistake of defining the data model like a relational database, assuming information can be stored or retrieved through the relationships. In addition, not defining reporting requirements upfront can dramatically impact the way table relationships (Master-Detail vs. Lookups) are structured and de-normalized. The wrong Force.com database design impacts user experience (too many clicks), analytics (inability to generate appropriate reports) and performance (response times).
Mistake #5 – Not knowing how to structure for code reuse
You can utilize Visualforce (and its controllers) or Apex triggers (in addition to the older S-Controls) for writing custom code, depending on your need. Visualforce provides the powerful ability to design complex UIs leveraging custom controllers which can be reused in other Visualforce pages, including Visualforce components that can be reused. However, there are quite a few situations where Apex triggers may be the way to go. For instance, a piece of custom code that needs to be executed from multiple places in the app, may be better suited for a trigger as opposed to a controller, where the code may need to be replicated. Various other factors will determine how your code must be designed and written – understand them upfront to avoid redesign.
Mistake #6 – Creating a design without defining your security needs
Force.com provides a robust security model and the security settings can be manipulated through the configuration screens for most simple applications. For more complex needs, the base security model can be manipulated using other mechanisms. For instance, there may be a need for security settings of an object to automatically impact the security settings of other related objects – such a need would not be met through the base model. Any custom manipulation of the security model needs to be identified upfront and incorporated into the app design. Otherwise it will lead to code rewriting and retesting.
Mistake #7 – Leaving maintenance and enhancements for others to worry about
Force.com enables short development cycles. Most designers do not anticipate issues with application maintenance or functionality enhancements when they are in design or development stages. However, you may later find that your system design does not allow for enhancements – it may also make maintenance requests hard to fulfill. For instance, as more and more data gets populated into the system, you may start running into governor limits, requiring you to completely re-write a program. There are several design principles that can be incorporated to help you avoid re-designing the system later, such as thinking about governor limits up front and using the correct looping constructs. Experienced developers and consultants can be a boon.
Mistake #8 – Relying on traditional methodologies to develop your app
Most traditional development tools/methodologies, waterfall or iterative, are skewed towards activities that are either accomplished differently or are redundant in the Force.com world. Pre-built components enable prototyping, designing, developing and testing to be done in very rapid cycles in Force.com, where development staff plays multiple roles. Your existing methodologies/tools may still work for you – however, they may increase your time and cost.
Mistake #9 – Not paying attention to code optimization
Efficient use of system resources is very important in Force.com. Budget time upfront for optimizing code after development, since it will be needed even with the most robust design, due to runtime issues. For instance, the total number of SOQL queries may exceed the allowable limit if there are multiple triggers written on an object. Lack of attention to code optimization may impact performance, prevent future enhancements or sometimes lead to a complete rewrite.
Mistake #10 – Using the traditional testing methods
Testing is done differently on Force.com. Typically, the test environment isn’t a separate one, and you absolutely have to write tests for code to be pushed into production. However, an application can be tested in a much shorter timeframe in the Force.com world since much of the built-in functionality doesn't need testing. Don't spend time writing tests that cover standard components - rather write tests that cover your own code instead. There are several techniques to reduce testing time such as automating test scripts or conducting development and testing in parallel.
Force.com is a comprehensive platform and, as such, provides various options and trade-offs. Like any good architect, your first critical task must be to understand your business constraints and needs. Mapping the Force.com capabilities to your business framework will be the key to success in the cloud.
Ketan Khandkar is a Principal at Navatar Group and an expert in business solutions built on Cloud Computing. He has developed SaaS product strategies for several ISVs and has authored some of the most successful SaaS methodologies and models designed to maximize technology adoption.