Recently, many low-code/no-code solutions have gained speed in the enterprise, giving non-technical people the option to create simple applications. Analysts predict that the low-code industry will grow by 20+% each year. But what is low-code, why is it getting so popular and what are the issues with it?
Low-code is something that we’ve occasionally seen in the past decades – a drag-and-drop UI designer that allows you to create simple applications without coding skills. Products have matured and practically all offer similar features – the ability to design entity relationships in drag-and-drop entity-relationship diagrams, the ability to design UI via WYSIWYG, to design simple processes via BPMN-like notations, to call external services via importing web service definitions, to choose from pre-baked entity definitions and to fetch and store data in external databases and spreadsheets.
There are many tools in this domain – MS PowerApps, OutSystems, Appian, Mendix, Google’s recently acquired AppSheets, Ninox, WaveMaker, and many more. And they may differ slightly in their approach and in their feature set, but the whole point is to be able to easily create applications (web-based, mobile-based, hybrid) that solve some immediate pain that these users have, where going through a full-blown IT project with the associated development cost is an overkill.
And that sounds great – you don’t have to rely on the overly busy and not often too responsive IT department in your non-IT company, you just build something yourself to optimize your immediate problem and to digitize your paper processes. And it can do that. To be honest, I like the idea of such tools existing, because a large portion of digital transformation is not handled well by huge, centralized systems and years long development projects. A lot of agility is required in a landscape where there’s more and more demand for digital transformation with expensive developers with limited availability. We have to admit that professional developers can’t be everywhere and solve every problem that could be solved by information technology. And so such tools democratize digital transformation, allowing non-technical people to create software.
Or at least that’s the theory. In practice this is challenging in many ways:
- Some technical knowledge required – it’s cool to be able to draw an entity relationship diagrams, but first you need to know what a data model is. It’s nice to be able to import a web service and be able to call it, but you have to know what a web service is. Integrating user directories implies you know what LDAP/AD is. I’m not sure non-technical people are able to make real use of these capabilities. Some tools still require simple code even to open a new dialog, and you have to copy-paste that code from somewhere.
- Integration with on-premise systems – building something useful almost always requires integrating with an existing system. It’s fine to assume everything is in “the cloud”, but even the cloud can be seen as on-premise from the perspective of a 3rd party SaaS. Many tools that I’ve seen integrate with databases by supplying IP, username and password – something that is almost never the case and is a bad idea. The ability to connect to something within the orgnaization’s infrastructure (even if that infrastructure is on Azure and you are using MS PowerApps) means permissions, networks rules configuration, accounts, approvals. And you have to know what to request in order to get it.
- Vendor lock-in – most low-code tools use proprietary formats for meta-descriptions (some go so far as to store binary representation of their metadata in a local sqlite database, for example). Some providers allow you to run the application on your own cloud by installing their server-side application, but some are purely SaaS. Once you build an application with one tool, you can’t really switch to another. Nice exceptions are WaveMaker and Skyve which generate actual Java code which you can download at any time. Is that lock-in bad? Well, yes – if it happens that you need a feature that’s not yet available, or an integration that’s not yet there, you are stuck.
- Shadow IT – all IT in an organization is assumed to be managed and observed by the IT department. In terms of monitoring, security, compliance, data protection, lifecycle management, technical support, etc. With low-code these applications can exist without the IT department even knowing about them and that poses many risks (which I’ll discuss below)
- Sustainability – what if a low-code company goes out of business, or gets acquired by someone who decides to sunset a product or a set of features? What happens when the employee that created the low-code app leaves and there’s nobody that knows how to “program” with the selected tool in order to support the app? What happens when the low-code app becomes legacy itself? Because of the vendor-lock in and lack of any standardization, it’s a big risk to take in terms of sustainability. Sure, you’ll solve an immediate problem somehow, but you may create many more down the line.
- Security – on the one hand, using a PaaS/SaaS may be perceived as coming with built-in security. On the other hand, non-technical people can’t assess the security of a given platform. And security can’t be fully “built-in” – you have to make sure that authentication is required, that apps are not visible outside some whitelisted office locations, that data can’t be exported by unauthorized people, that you have protection against XSS, CSRF, SQLi and whatnot. Even if the platform gives these options, a non-technical person doesn’t know they have to take care of them in the first place.
- Compliance – many industries are regulated and there are horizontal regulations like the data protection ones (GDPR, CCPA). Data breaches often happen because data was fetched from its original well-protected storage and kept in various places (like a low-code app) that the data protection officer doesn’t know about. Encryption, anonymization, data minimization, retention periods – most low-code solutions don’t support these things out of the box and it’s unlikely that an employee not familiar with the specifics will walk the extra mile to have the app compliant.
- Bugs outside of your control – when you have a bug in your software, you can fix it. If it’s in a library, you can patch it. If it’s in a set of tools of a third-party platform, you can’t do anything. During my testing of several low-code solutions I stumbled upon many bugs and inconsistencies.
Some of these problems exist in regular projects as well. Developers may not know how to make an application GDPR-compliant, security is too often overlooked in many projects, and technologies are sometimes selected without taking sustainability into account. But these problems are aggravated by low-code solutions.
The interesting thing is that low-code is one part of a broader spectrum of technologies. They start with “Rapid application development” (RAD) tools and frameworks and end with “no-code” (a.k.a. less feature-rich no-code alternatives). Code-generation tools like Spring Roo are RAD, OpenXava is a RAD framework. Some low-code tools can actually be seen as RAD tools – the aforementioned WaveMaker can be used pretty easily by dev teams to quickly deliver simpler projects without sacrificing too much control (and I guess it is, being acquired by an software development company).
Then there’s RPA – “robotic process automation”, which I’ll bluntly simplify as “low-code with screen scraping” – you automate some processes that involve legacy systems with which you can only extract information and perform actions by having “bots” press buttons on screens. RPA lies slightly outside the rapid application development spectrum, but it brings one important point – there are RPA developers. People that are not deeply technical and aren’t as qualified as developers, but who can still automate processes using the RPA tools. Same goes for low-code and some flavors of RAD – it is assumed that you don’t have to be technical to develop something, but actually there can be (and there are) dedicated experts that can build stuff with these tools. They are not actual developers, but if you can deliver a project with 5 low-code developers and one actual developer, this can dramatically cut costs.
Developers and large companies certainly have a “toolbox” which they reuse across projects – snippets from here and there, occasionally some library or microservice. But each new project involves a lot of boilerplate that even developers need to get rid of. I’m certainly not a big fan of code generation, but RAD has some merit that we have to explore it in order to improve efficiency without sacrificing quality. And to be able to provide the simple tools that would otherwise be built with sub-optimal low-code approaches.
Blurring the line between “developer” and “non-developer” is already happening, though. And while focusing on our fancy frameworks, we shouldn’t lose sight on the tools for the less technically skilled; if only because there’s a risk we’ll have to support them in the long run. And because they will become part of a software ecosystem with which our software will have to interact.
Whether that’s the right and sustainable approach to digital transformation, I don’t know. I’d prefer, of course, everyone to be able to code at least simple things with the help of advanced RAD tools. And we’ll probably get there in a few decades. But as digital transformation needs to happen now, we may have to work with what we have and try to make it more secure, compliant, with less vendor lock-in and more visibility for the IT departments. Otherwise we risk creating an even bigger mess than we are at now.
Published on Java Code Geeks with permission by Bozhidar Bozhanov, partner at our JCG program. See the original article here: Low-Code, Rapid Application Development and Digital Transformation Opinions expressed by Java Code Geeks contributors are their own. |
