Last couple of weeks or so, I happened to hear about some of the ‘Low Code Development Platforms’ (LCDPs) from few project engagements in Tiqri and also from some technical discussions outside. In fact Tiqri hat its own LCDP – Compose (http://www.onctg.com/)

What is a LCDP ? according to wikipedia – Low-code development platforms represent a type of technology that allows for creating apps through configuration of functions, rather than coding those functions.

The Love

There are number of LCDPs available, where you can plug and play things and create screens. These screens are often simple web based ones or mobile apps.

If you’re an enterprise and you need some screens to read and write data from the devices of your sales team to your ERP,

• You need it instantly
• Don’t want to spend time in the discussions of  native/hybrid or web app/SPA
• Want to complete this from a small developer footprint and cost

LCDPs are good at achieving this, and they are often targeted at business stakeholders.

Like a developer with little business context getting obsessed with the recent conference he attended and want to convert the systems to the great technology he saw there; the business stakeholders with little technical context love the the promise of high productivity and low cost of LCDPs

In fact, we cannot have an intrinsic argument built on the idea of LCDPs do not offer productivity. They do offer faster feature delivery compared to the typical development due to obvious reasons.

The Hate

The general perception about LCDPs is – of course they offer quick feature delivery but when it comes to customization and granular business requirements they hit the limit at some point and then become the pain.

It is hard to evaluate any technology completely before using it, after all the evaluation itself has a shelf-life as technologies often upgrade. But LCDPs have an inherent disadvantage of (not all but most of them) being coupled with certain types of systems. If your organization has different systems and conformity of the LCDPs with the different systems should be considered.

LCDPs remain mostly in internal applications. If you’re launching an app for public usage and high penetration mostly technical stakeholders do not opt for the LCDPs because they can have their own limitations and reverting from such implementations is very costly compared to reverting from an internal application developed for your sales team.  Application branding and look & feel customization is one big challenge.

Finally a psychological reason – As developers we favor the engineering feast of the solution more than the business solution. – I accept this; this does not mean we do not care the business, we do and make our fullest effort to solve the business problems but we do not like to do it at the stake of losing the passion of coding. – I know there can be many arguments on this point

The Rise

LCDPs are not new to the market, even bigger development technology providers like Microsoft, Google and Oracle have their own share of LCDPs in the market.

Few platforms which are connected to a major products (SAP, Salesforce) have their fair share and some generic LCDPs have been living in their own sweet internal world specific to few industries. – Starting at a point some LCDPs have first phase customer’s industry influence in them, which makes them not suitable for other industries. 

According to Forrester Wave Q2 2016, LCDPs are categorized under these 5 categories. Does general purpose mean anything that cannot fit in other 4 categories ?;) 

I have marked the 2 solid green boxes, and one dashed as per my opinion and observation of the LCDPs. These categories will have a rise in the future. There are reasons for this.

1. APIs everywhere – Most of the LCDPs rely on data pipeline for the functionality, if the data cannot be accessed from a system they cannot begin their work. But now the proliferation of APIs help LCDPs to break their initial barrier.
2. Modern Cloud based tools – Modern services like AI, Machine Learning, Data pipelines, integrations and etc have cloud based LCDP tools. Azure, AWS or IBM Watson all have a drag & drop based or wizard based implementations of machine learning development platforms.
3. Serverless (BaaS) – Most of the Serverless Back-end as a Service models rely on the LCDP platform model. The visual designers and cloud based tools aid this. Also, the nature of the BaaS itself relies heavily on the third party integrations and configurations which makes it a choice to be a LCDP.

Conclusion

Based on the trends in APIs, Cloud based tools and Serverless, LCDPs have more potential to grow, but that does not mean they will have the solutions for all the problems in hand. Mainly the in the areas of handling dynamic data structures and modeling, UI, data governance, performance and so on. (individual LCDPs have some solutions for these problems in certain ways)

As of now back-end based LCPDs which come under the flavor of Serverless are promising in request handling and some process flows. These platforms are often offered by cloud giants like Azure & AWS. This would be a competition for some LCDPs whose strengths are in those areas.

Overall I believe the future of LCDPs are promising in terms of Serverless, APIs and Integrations but doesn’t look much convincing in terms of frontier application development except internal collateral application screens for the enterprises.

Visual programming, Rapid Application Development (RAD), high productivity PaaS (hpa-aPaaS) are some terms closely connected to the LCPD or used to refer LCDPs.