There are really two explanations that one can offer to this question, the first is a comparative answer for the IT savvy, Low Code/ No Code (LC/NC) can see comparisons with the 4GL (Fourth Generation Languages) approach seen in the 1990’s and 2000’s. The business answer is that LC/NC is targeted at users who wish to develop functionality without the need for development knowledge or experience.
Let’s take the business perspective as this is probably the most compelling to the non-software development community. If we could ask our users to create their own solutions without the need for specialist knowledge or without the typical project lifecycle, we should be able to get our tools quicker and cheaper than we do following the traditional software development lifecycle (SDLC). Gartner Research Director Paul Vincent drew on an example quoting a reduction in timeframes from the typical six to 24-month delivery window down to two to three months. In addition to the referenced ‘time-to-market’ benefits, the reduction in needed skills and experience offers both an answer to the skills shortage questions that we read about so much as well as being able to benefit from reduced resourcing costs due through a lower skills requirement.
A recent 2018 Forrester study highlighted that of 3,200 developers surveyed, 23% were already using LN/NC tools and a further 22% were aware of organisational plans to adopt them in the coming 12 months.
John Rymer, an analyst at Forrester Research estimated that within five years or so, that possibly there will be a business user-base of over 100 million people globally focused on the IT Department, customer service and e-commerce solutions. If this analysis is even moderately accurate, we can see that LC/NC tool adoption is not a theory any longer but a trend that its growing and will, in all likelihood, continue to grow.
This picture is supported by a 2019 Garter report that predicts that by 2024 over 75% of large enterprises will be using LC/NC tools representing over 65% of all applications. We can look to freelance tools such as Upwork and PeoplePerHour to also see and validate that the demand for individuals with LC/NC skills is rapidly increasing.
Today there are a number of LC/NC development tools in use today and I’ve listed below a few of the key players.
1. PowerApps – Microsoft
2. Mendix
3. Kony – Temenos
4. AgilePoint
5. Outsystems
6. APEX – Oracle
7. VBCS – Oracle
8. Lightning – Salesforce
9. BettyBlocks
10. Skuid (a Salesforce tool)
11. Appian
12. PegaInfinity – Pega Systems
Some of the above platforms are based around existing or dependent infrastructure components with the objective of making enhancements and customised solutions that much easier. These tools undoubtedly add a great deal of value within the business however it’s worth noting that they have a platform dependency and are not really targeted as independent tools. It’s also worth noting that this dependency carries with it both third-party risks (albeit manageable) and the associated costs that go with the middle/ back-end infrastructure including licensing, maintenance and other costs. Note therefore that Skuid and lightning are aimed at the Salesforce user base whilst APEX and VBCS at the Oracle users.
With a quicker time-to-market, a reduction in the needed knowledge to build our solutions, it seems like it’s a bit of a no-brainer. We can get our solutions, quicker and cheaper, we don’t need IT anymore. Erm, nope. Theory and sales processes often miss a number of key points and dependencies. Let’s have a quick look at five of those gaps.
1. Existing Infrastructure – To use LN/NC tools there will be the need to both setup the tools into the current IT infrastructure and then enable and manage levels of connectivity and security. Not only will the tool need to be setup but users will require permissions, updates will need to be applied to the LC/NC tools and legacy infrastructure will see future changes so up and downstream dependency management is important.
2. Security Implications – Aside from the above connectivity issues on setup, any organisation will want to implement access control issues when it comes to data, especially customer or sales data. Those developing tools will need to understand both the current setup and manage who can access what data in the future. GDPR limits what data we capture, who can see it, and how it is used for example. The build into the picture the idea that some of the LC/NC tools are able to create mobile applications so your data will be on phones and tablets, a real security nightmare.
3. New Dependencies – If the LN/NC tool is based around Salesforce or Oracle as an example, then any future infrastructure changes could be both complex and risky unless there is a register of all applications whether it’s from IT or within the business units. The tools may be based around cloud-based deployment and/ or storage needs creating a very real operating dependency. Increased costs, service availability and performance issues from these dependencies could create real future challenges. PowerApps for example is based around Microsoft Azure. What is this infrastructure were to change or a future merger creates the need to use other platforms? Dependencies create operating and financial risks if not managed effectively.
4. Solution Support – When applications are developed using the LC/NC tools there may be the need to enable user/ customer support. Who will look after users, maintain the applications and what happens if the application is built by a single user who later opts to move to another organisation? How will issues be managed, who will users call, how long will fixes take? If an application is built within the business rather than IT departments then the user base issues may rapidly become an issue as time goes on.
5. Solution Compliance Issues – We’ve already mentioned GDPR issues as an example however nowadays business and market regulation in an ever-increasing burden and not something that we can or should ignore. Without the correct oversight and/ or review processes, applications could be built that either did not meet the compliance needs at the time of implementation or cease to meet the requirements when subsequent changes are made. Without some form of central oversight issues will occur.
We read on the various websites and reports about the comparison with 4GL’s however they never really found the place in the market you’d expect, especially not when it came to user generated solutions. As an example, here’s a few of the 4GL tools,
Clarion, Clipper, Forte, LabView, PowerBuilder, Dataflex, Informix, Natural, Progress, Oracle Reports, MATLAB, Mathematica, R, and so forth.
Over the years I’ve used the likes of MATLAB, R, and PowerBuilder and where I’ve seen them in productive use has pretty much so far been limited to the IT department, financial analysts and the scientific community. None of these are representative of the proposed average business user due to their complexity or knowledge requirements. Each of the users I’ve seen in action have gained a lot out of the tools however it’s a very limited number and certainly very specialised with each requiring IT support and regular interaction. Their use was valid, but it wasn’t simple. Also, over time, a skills and knowledge dependency grew to the extent that the roles became extensions of the IT department anyway. Now, as with an example, there will be exceptions such as finance analysts and quants, data scientists, etc, but they’re highly skilled and dedicated resources. It’s rare to see Joe or Susan from accounts or sales developing their own tools. Again, I accept that there may be an exception in your organisation however bear in mind the word exception.
If we can optimise the application development and deployment window for users making the basic applications quicker and cheaper then we should not ignore it. After all, this is what we are trying to deliver through Lean and Agile methods sow should look towards embracing positive changes. But, I’m not sure that we should be buying into the idea that we decentralise application builds just yet due to the operational, security and regulatory risks if we get it wrong. The plethora of solution providers offers a particular challenge where we must rely on young organisations or the incumbents with their sustainability or dependency risks. As the pace picks up there will no doubt be some consolidation and standardisation however the idea that an untrained user can build a functional application with little knowledge is still not quite with us. The tools vendors will argue that simplicity is at the core of their solutions however as we saw with the various 4GL solutions, reality is never as close as the picture that we are given by very nice, competent and convincing sales staff.
There is certainly a time for Caveat Emptor however the growth and adoption rates show that the tide is firmly moving in one direction and there is always an element of truth behind the old adage that ‘fortune favours the brave’. Be brave, but be cautious, analyse and assess before jumping into the LC/NC pool and for now, don’t be too enthusiastic at the idea that you can start to get rid of those IT developer
So, to the opening question, Is Low Code /No Code a thing? Yes, it is, today it just might not yet be as big a thing as the brochures say it is. Tomorrow, almost certainly.