Buy vs. Build (the Salesforce edition)
The life of an IT manager is made of many decisions leading to long-term commitments:
- Choice of technology (.Net vs. Java).
- Choice of vendor (IBM vs. BMC).
- Choice of architecture (on-premise vs. cloud).
And then, there's the famous "Build vs. Buy" which is as much about computing as it is about business operations and risk management. In this post, I'm reviewing this IT classic in a Salesforce world...
Because it's now an old age question, the advantages of both buy and build are well known. So, I'm just listing them as reminders below.
- Fast implementation speed
All capabilities being pre-built, the implementation time is reduced to installation and configuration.
- Business process improvements
The software business logic is built around best practices.
- Benefits of scale savings
The cost of each line of code is shared between customers. The vendor can invest more in security and innovation.
The software has been tested by many users and customers before you.
Support is available from both the vendor and the community.
- Zero technical debt
The vendor's business model guarantees a high level of documentation and skills.
- Feature granularity
The solution can be tailor-made to exactly fit the current business process.
- Short terms costs savings
This is the easiest way to cut corners.
- Business advantage
Automates a company business process with a software which is not available off-the-shelf.
- Keep IT busy
The skills required to build are available and unused.
Although you can build on the Salesforce platform, it is essentially a member of the "Buy family".
The Salesforce equivalent of buying is making the most of the components already available on the platform by favouring button-click configuration over code (say <20% code). A config-only strategy can be too restrictive and use a little code here and there to refine an application is absolutely fine from an architecture perspective. This mature approach now even has a name, "low-code", and is considered by many, including me, as a best practice.
The availability of the AppExchange marketplace makes this strategy even more compelling to me. Not only can you configure Salesforce's robust out-of-the-box capabilities, but you can also buy more capabilities on the AppExchange and configure them without code either. And the good thing about purchased code is that it tends to be more robust than in-house code because testing is done by way more users.
Building on Salesforce is about writing a code-heavy application (say >80% code). Think of replacing most of the out-of-the-box business logic like approval processes with code to work around current feature limits. Although technically possible, I don't recommend it for the main reason that it's not part of the platform's DNA, Salesforce started as a highly configurable on-demand CRM with the original strategy to reduce the need for IT involvement (click-no-code). Coding capabilities were rapidly added and, yes, using them all in the same project is possible and exciting for the nerd in you.
Unfortunately, this will also most certainly lead to technical debt. Still, this is what big SIs, coming from the world of J2EE bespoke apps, tend to favour and rarely think twice before building complex, unmaintainable systems.
Also, custom code doesn't benefit as much from Salesforce constant innovation as much as standard features do.
Think again, you either go with Salesforce, or you go alone...
Don't Do It
Not doing it is the new kid on the block of enterprise application design, sadly not a popular one though. In the old days, upgrading software was a multi-month long project and IT was often reluctant to upgrade a production environment for the sake of adding new features. As a result, there was quite a lot of pressure on implementation teams to squeeze in as many features as possible on v1 because nobody knew when will they get a v2. As a result, building often was an attractive option.
Now, here is the game changer:
- All Salesforce tenants run on the latest version.
- There are three new releases every year.
- Salesforce is quite an innovative company.
These three facts remove the pressure on feature richness and, instead, offer new capabilities you've never dreamt of (mobile, AI, IoT, ...). In my post "The million dollars picklist", I'm telling the story of a customization which has gone too far the custom build way!
When blocked by a feature's current limitation, don't start coding, start thinking... Align your application roadmap to Salesforce's own one. For the bits you don't know about, the best way to remain compliant with future releases is to stay as standard as possible (buy, don't build too much). You're not obliged to say "yes" to all requests from your stakeholders, but you're obliged to provide good advice! Many businesses are doing great running on "non-perfect" lean apps, whereas others are struggling to grow trapped into technical debt issues of what's become a bloated org.
Writing code is fun! Thing is, you're not here to have fun but to leave behind a resilient enterprise class application.
Related Posts & Resources
- Forbes: Custom software vs. canned solutions
- CIO.com: When to build or buy enterprise software
- Salesforce: The power of low code
I hope you enjoyed this post. Don't hesitate to ping me on Twitter if you have any comment or question.