No Software

No software is the marketing tagline that salesforce used to sell its flagship Salesforce Automation product and a bundle of other related products. Let’s understand where it all started. Initially, each organization had to manage its infrastructure, platform and application software on its own but that was in the 20th century, whose hangover lingered on into the 21st century for a few more years. Today in 2019, that’s passé; everything is available as a rental service. Most of the layers required to run your software shop are available as Infrastructure as a Service (IaaS), Platform as a Service (PaaS) that includes all features of IaaS and more, and Software as a Service (SaaS) that includes all features of PaaS and more. There may be a few overlaps in the bordering layers in how one architect looks at things than others but at a high level below is a conventionally acceptable classification.

Screen Shot 2019-04-23 at 8.05.06 PM

In most popular SaaS products, a lot of code comes in different categories of packets that can be arranged/configured to create a database layer, controller layer or UI layer. These packets can be dragged and dropped into the central template to create an enterprise application. Another name for these code packets came to be known as configurable items. To the administrator or configurator, the underlying code is hidden and the configurable items most often look like simple texts or flow diagrams.

Good. Hire admins; lay off all programmers.

Hmmm…. not there yet.

We don’t have any PaaS product that can achieve all the complex workflows of a big enterprise with their configuration tools alone. They do promise in their sales pitch that it can be done but the truth is that although we are headed in that direction, we are not there yet.

Let’s talk specifics now; let’s talk is an amazing company that provides a suite of cloud-based products. It provides both SaaS and PaaS solutions. Among its many products, the most popular ones are Sales Cloud and Service Cloud. The company has grown organically (better sales cloud features, better service cloud features, Shield Encryption, Lightning framework, Saleforce DX, etc..) and inorganically (acquisition of Steel Bricks turned into Marketing Cloud, Heroku, Mulesoft, Pardot, etc..).

The configuration tools do solve a vast array of business requirements. And the repo is highly maintainable. But when it comes to scalability for large enterprises in a multi-tenant environment, as most PaaS providers are, scalability becomes an issue. That and if the business workflows are too complex, you will need programmers. Luckily for us, salesforce has many different avenues for doing a mix and match of configuration and coding to achieve business needs.


Config and Coding – what’s the right ratio? 90-10 or 80-20?

A few of the key configuration features include Workflow Rules, Process Builders, Validation Rules, Lightning Flows, Email Alerts, Field Updates, Outbound messages, Roles, Profiles, Permission Sets, Identity Management, Lightning Components, Reports and Dashboards.

A few tools in the coding area include Apex classes, Apex Triggers, Visualforce pages, Aura Lightning Framework.

So, what’s the right mix? How much code is good?

Like all right answers, the answer here too is – IT DEPENDS. It depends upon –

  1. Complexity of the business requirement.
  2. Limitations of configuration features.
  3. Foundational architectural design that’s laid down by the Solution Architect of the organization keeping in mind the technical needs of future requirements.
  4. Availability of quality developers.

Let’s double click on #3. Why would a Solution Architect design a solution that would involve code, a solution that can be achieved by configuration features? It may be because of any one or more of the following reasons –

  1. She is dumb.
  2. Business has complex workflows that has many branches and certain branches run very deep.
  3. There is a need for custom APIs to meet inter-system connectivity requirements.
  4. Business is uncompromising in their demand for a UX Design with a Human-centered design approach.
  5. UI requires building a complex form with dynamic field rendering.
  6. She is passionate about microservice architecture and plans to bring it on her salesforce platform.
  7. She has foresight into future needs of her organization. She understands that even if the current business needs can be achieved by point and click configuration, this design is not scalable, or it will scale with very ugly workarounds (band-aid solutions).
  8. She wants to have greater control over sequence of execution of validation rules.
  9. She wants to have greater control on the sequence of execution of various tasks by moving the logic from multiple workflows and/or process builders to a trigger. Salesforce doesn’t guarantee the order of execution of workflow rules or process builders.
  10. She wants to have greater ability to debug issues. Fine grained debugging is at times not possible with a few of the configuration tools e.g. Process Builder.
  11. She is a rebel and does (code) exactly opposite (config) of what the non-tech leadership wants; the leadership’s only exposure to salesforce being Dreamforce events and demonstration of a very simplistic workflow done with point and click tools.

There are myriad of reasons that may force the architect to go towards a heavier coding approach.

What would I do?

As a Solution Architect of a large enterprise if mine is the strongest voice among all the stakeholders, I will go with a click-first approach. If configuration tools are not good enough, then go the coding route. But I would not be paranoid by the thought of coding in salesforce. If coding is the right approach, then coding it will be. It is certainly going to test my influencing skills with other stakeholders.

For large enterprises, one needs to have an eye on future landscapes – both functional and technical. It will be detrimental to any organization’s ROI on CRM investment to have a fixed mindset (only config or only code). With the aura framework and lightning web components, building reusable components will be key to most robust salesforce designs. So, some degree of coding is inevitable unless you are working with simpler business requirements.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s