If you are to search for “low-code benefits” you will quickly find that there are many opinions and experiences around the benefits of low-code development. The aforementioned Google search returns about 8.5 billion results. A couple examples are:
- Decreased costs
- Higher productivity
- Improved agility
- Enhanced Innovation (hmm… that’s an interesting concept)
- Lower barrier to entry
At the root of all of these things is the root of what every company wants to accomplish, higher velocity that allows them to beat out the competition. None of these are bad things, in fact, they are the reason (except #4) that my own team is on this journey today. When using this second-hand Gartner’s forecast of 65% of application development by 2024, It’s clear that this isn’t a niche market or something that only a few are doing. After all, who doesn’t want to move faster than the competition and enable more employee productivity?
My goal here isn't to convince you to go or avoid low-code solutions. My goal is to share first-hand knowledge of the considerations that you should have before you start this journey.
The HackerNoon story referenced above is quite good and provides a very balanced view on the pros and cons of utilizing a Low-Code Application Platform (LCAP). However I do take exception with a few of their points as in need of further clarification. Primarily around security, risk and lifecycle support. That said, it’s a solid article that deserves a good read. In the meantime let’s dig a bit deeper.
Selection Criteria
Our selection criteria was based on 20 different factors.
Data Storage
- Must support a relational data model that allows extensibility with new, arbitrary table structures.
- Must support a unified data model linking all table structures together.
Reporting
- Must support reporting engine with:
- Schema dot walking
- Database views
- Ability to do left and inner joins
- Ability to save and export reports
Workflow Engine
- Must include a configurable workflow engine with the following capabilities:
- Ability to trigger workflows based on user-supplied conditions
- Ability to define custom issue statuses
Table Forms
- Ability to graphically create forms for interacting with the underlying data structure. Forms should allow:
- Graphical customization of the layout
- Support for multiple column layouts
- Client-side scripting for dynamic content in the forms
- Graphical rule builder for dynamic content in the form
- Ability to create a form to create new records without requiring a workflow
- Display related records through an integrated view
User Portal
- Support a user-facing portal which allows users to search for all relevant records.
- Ability to add any other user as a watcher on an indicated record
Record Operation Actions
- Provide capability on Create, Read, Update and Delete operations of database records:
- Execution of user-created scripts
- Execution of user-created rules, defined in an integrated, graphical rules engine
Record List Views
- Must support table list views with the following capabilities:
- Column Filters
- Group by column value
- Inline cell editing
- Bulk row editing
- Ability to view related records
Role-Based Access Control
- Must provide RBAC for all system elements and must provide granularity to the field level of a data object.
Audit Trail
- Must provide an audit trail for all capabilities within the system
Bi-Directional API
- Must provide a REST API for incoming requests as well as the ability to update other systems via REST.
Scheduler
- Must provide a job scheduler which allows the administrators to execute the following on a defined schedule.
- Scripts
- Rules
Code Migration
- Must support migration of all code/configuration between environments (e.g.: dev -> staging -> production)
Administrator Initiated Upgrades
- Must allow administrators to initiate upgrades at their own appointed schedule
Firewall Traversal
- Must allow bi-directional communication between the service and any on-prem components without the requirement of altering border firewall rule-sets.
SLA/Metrics
- Must be able to calculate user metrics based on records such as SLAs, etc.
Approvals
- Must provide the means to approve tasks and operations within a workflow.
Time-to-Value
- Should provide a rapid time-to-value. Ideally, we should have the core platform configured and running in under 1 month. (Much more to come on this later…)
Availability
- Must provide availability of at least 99.9% uptime.
Performance
- Must allow storage of at least 10 million records while maintaining performance SLAs.
Selection Process
There you have it… what we considered through assessment of what we needed in a low-code platform. Looking back on it In some areas we were a bit naive, but for the majority of them they were spot on. That brought us to the contenders, which I will not name individually. They contained the top names in the market, some internal prospects, and some lesser-known players. The selection process was done in 2 parts. First an initial assessment was completed, and, if the product scored high enough it went through the full assessment. Only 4 of the 8 products warranted a full assessment, and the scoring was decently close between them. Each had drawbacks as well as outlier benefits. However, as you can see below, based on the criteria that we had chosen Salesforce.com in conjunction with SalesforceDX ultimately won out.
Is Salesforce the right choice for you? Maybe, and then again, maybe not...
Don’t take the results of our assessment and assume it’s the correct choice for your enterprise. Instead, focus on the requirements that are most important to your use-case and perform your own assessment of the ecosystem. For us however, even after considering costs and strategic relationships the choice was clear; our partner in this journey of low-code development was going to be Salesforce.com.
Next Up – The Road to Low-Code | Mitigating Foreseen & Unforeseen Low-Code Impacts