Should you use a Low Code Application Platform (LCAP) for your next application buildout?
​
Until now, the choice of environment to use for development was on the stack (J2EE, MEAN, .NET etc.). With the availability of Low Code Application Development platforms (LCAP) that automate a large portion of the development process, you now get a new set of advantages related to speed, reduced effort and ease of maintenance. Some LCAP’s promise code elimination, but the reality is that automation of 70-90% is possible with mature platforms. However, considerations of ruggedness, scalability, performance, maintainability, technology direction and other factors needs to be considered before you decide between an LCAP or continue with conventional development stacks.
​Here are a set of crucial questions, which when answered will help make the choice
​
What type of application is it?
​
Is it heavily transaction oriented or is it more content management, analytics, IOT, Block Chain, VR, AI or ML based ? In case it is transaction or content management heavy, the choice is loaded in favor of LCAP’s. This is because LCAP’s effectively automate most of the plumbing across all the layers of transaction processing systems. In other types of systems, the automation levels in coding of LCAP’s are much lower and specialized platforms or development stacks are better. However as we speak startupus are improving the level of automated code in most areas.
​
Large application or small application?
​
If it is a small application, good software talent typically involving full stack developers can do the job as well LCAP’s through sheer talent and effective use of libraries. Conventional development is an option, if LCAP's do not give you an advantage.
​
For smaller applications, one could also use the many small footprint LCAP's like MS PowerApps or Google Appsheet. However do keep in mind that although they are designed for ease of use and good user interfaces, they all have limitations either in terms of automation capability or licensing. You could have limitations that allow you to do the application to a 90% level very fast but then it starts getting tough to do. The diagram below indicates the effort complexity problem, which you should watch out for.
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
However, if the system is large involving many transactions (say over 15 processes) then LCAP’s have the advantage because a larger portion of the development is automated. Productivity metrics of speed, effort and resource requirements become much better. Complexity of execution gets eased out through increased automation.
​
Is there a specialized performance or scale need?
​
Is there an exceptionally large transaction throughput involving millions of transactions expected, especially in peak loads. LCAP’s many are not crafted for such levels of performance and in these situations conventional code-based platforms may do a better job. Personalized algorithms that help parallel processing, or well-crafted asynchronous operations will give better responses than a cookie cutter transaction system that most LCAP’s are. However, as time progresses LCAP’s are getting better at handling scale and performance primarily because cloud infrastructure is progressing rapidly.
​
How important is speed, budget and other such indicators?
​
Every project has its criticality in terms of time to go live. When timeframes are small, and deadlines are tight, conventional approaches will fail. LCAP’s are now proven to reduce time and effort. Similarly, when budgets are small and costly tech resources are out of bounds for long periods of time LCAP’s will prove to be better. However, if one has time, one can craft a personalized system. However, in todays world of rapid digital transformation, time is at a premium and hence LCAP’s are seeing rapid growth of over 30 percent CAGR per annum.
​
How clear are your specifications?
​
If specifications are clear and unlikely to change it’s a positive for both approaches – LCAP and conventional. However, if specifications are unclear and users are likely to give genuine feedback only when they see something or give it through multiple iterations, then LCAP is better because one can quickly develop semi working prototypes and iterate through feedback cycles to reach a point where specifications can be locked in. Iterations in semi working prototypes take long time in conventional development but is relatively easy in LCAP. A lot of risks related to specification clarity can be eliminated.
​
How strong is your tech team and how familiar are they with LCAP’s ?
​
Familiarity of a team with a stack or a specific LCAP can swing productivity heavily because one avoids the learning and expertise building cycle. Similarly, corporate IT policies may drive choices to stacks. If the team is overwhelming strong in a stack or LCAP then you should consider it, but don’t make it the basis of your decision and be ready to review policy decisions since improvements in technologies are changing long held assumptions.
​
Is it in line with the future of development?
​
What are the pundits saying? Are full stack languages going to win the day or will LCAP’s win. Recent comments from Gartner indicate that LCAP’s are likely to win - with 65% of applications being built in 2024 will be LCAP based. As the answers would indicate, if the application buildout is heavily towards Enterprise Transaction systems, the pendulum is clearly swinging towards LCAP’s becoming the standard.
​
Disclaimer: As a vendor providing a Low Code Application Platform called www.Stragiliti.com our value proposition is to demonstrate 3x to 15x improvement is speed and budget reductions in Enterprise Application buildouts. With 100’s of projects and solutions delivered in the past 10 years, the pace of our innovation improves, and the conviction that LCAP’s are the future for Enterprise Applications stands cemented.
​
​
​
