10 Common Mistakes by Salesforce Architects | Techila
single,single-post,postid-2619,single-format-standard,ajax_updown_fade,page_not_loaded,,qode_grid_1300,footer_responsive_adv,hide_top_bar_on_mobile_header,qode-content-sidebar-responsive,qode-theme-ver-9.4.2,bridge,wpb-js-composer js-comp-ver-4.12,vc_responsive

10 Common Mistakes by Salesforce Architects


10 Common Mistakes by Salesforce Architects

A Technical Architect would have broad knowledge across multiple development platforms, with the ability to assess the architectural environment and business requirements to design secure, high-performing technical solutions on the Force.com platform. An architect would communicate technical solutions to business stakeholders and provide a delivery framework that ensures quality and success.

Do not make wrong choices that can increase scope, timeline and cost.

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.

Create the right design for your app, if you want to avoid rebuilding it.

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.

Building in the cloud will be different – prepare for the change.

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.




“Know more about Salesforce Consulting at Techila”

Author: techila

No Comments

Post A Comment