Low Code Platforms - a Dangerous Bet
The low code application platforms (LCAP) have emerged in response to the complexity and variety of the modern software development landscape. Mendix is one of the most prominent players in this space according to Gartner, so let me use it as a reference in this article. However, similar conclusions would apply to Outsystems, Appian, Kony, Betty Blocks and many other platforms.
Being sold to business executives, LCAPs originally claimed that business users (aka citizen developers) can create enterprise-grade solutions. So, are the developers now obsolete? Well, a few years later Mendix confesses:
What a twist! I guess the guys at Mendix realized that anything more complex than a basic CRUD system still requires a professional software engineer, just like servicing your car beyond pumping tyres usually requires a professional mechanic.
Unfortunately, current low code platforms are just not made for a developer. Moreover, relying on them in the long term can be a dangerous bet for the business. Below I will explain why.
Great for prototyping
Mendix is indeed a great option for citizen developers to automate simple business operations, or deliver working prototypes. In a visual designer you can define data model, scaffold responsive UI using a collection of widgets and templates, and even describe logic with microflows:
When you’re done, you can deploy your app to the Mendix cloud with one click and see it working. Looks simple and works like a charm, so this is often just enough to get a business executive sign a cheque.
However, as your app passes the prototype stage, both user interaction and business logic almost inevitably become more complicated. Here comes the stage, when you require a professional to push the project forward to avoid ending up in a mess.
So, let’s look at this from the developer’s standpoint.
Any logic - whether calculations or user interaction - must be described in a microflow, a visual representation of the code as shown above. There are a few issues here.
First of all, this is just slow. Imagine dragging, configuring and connecting tens of stencils versus writing 10 lines of code in a good IDE. Over certain size, your microflow inevitably becomes unmanageable.
Second is readability. Those stencils look nice, but what’s behind that Sub_RegistrationValidation? You cannot really read it without having to dive in.
As a getaway, Mendix offers Java actions. This means that you can invoke Java methods (with serious limitations for cloud deployment) from a microflow. You can write Java code in Eclipse, which is OK, though many would prefer IntelliJ - the leading IDE. The downside is lack of transparency: all entry points to your code are in microflows, so debugging or tracing the dependencies is complicated. The logic flow is scattered between the two worlds.
The last bit I have to mention is version control. Good news is that there is one. Bad news is that it is a restricted subset of Subversion. Say bye to git flow.
Anyone familiar with the Java ecosystem, cannot underestimate the power of open source. When you have an exception somewhere down the stack, you see the code where it happened. You can debug it to figure out exactly what’s going on. You can google a solution. You can submit a pull request. Worst case, you can fork. You are in control.
Forget about that with Mendix. The framework is proprietary so the underlying stack is a black box. All you’re left with is paid support or praying someone will help on the community forum with ~200 questions a month (compare that to Spring tag on stackoverflow!).
Mendix probably gets poked for that quite often. They even put an article to explain how you are not locked into them. If you can read behind the lines though, it says:
You can get your data, DDL, UI resources and code (microflows magically converted to Java).
Will this run or compile without Mendix runtime and API? A rhetoric question. In fact, this would require a full system re-write. You are locked into a proprietary platform. You do not own the system you’ve built.
Mendix marketing is targeted at the largest companies out there, so “scalability” term pervades their marketing materials. In 2017 they introduced “stateless runtime” - which means that all session information is either stored on the client or persisted. In theory, this means unlimited horizontal scalability. Sounds cool, but there is a catch - the database.
Database is the usual bottleneck of an enterprise application. So, what stores the data behind the horde of stateless Mendix servers? No surprise - it is the good old relational database. In the case of Mendix cloud it is PostgreSQL. There is no caching and the DDL generated by Mendix is questionable. For example, I’ve encountered an interim table typically used to model N:M relations generated for a 1:N relation.
This would be fine if you had control. Oracle and others have proven that RDBMS can work at scale. You could optimize DB structure, cache data or even use solutions like Citus for true scalability. But you don’t.
The only DB scaling option is scaling through read-only replicas (e.g. Amazon RDS), but this does not help with writes.
To conclude, there is a fundamental scalability limitation and a lack of options for fine-tuning performance.
Deskilling sounds like a charm for any manager. No need for expensive, hard-to-find professionals. In reality, this plays a bad trick. When you actually need a developer for your project, you’ll be struggling to find a good one. For a professional developer, this means career dead-end.
Prices that Bite
Last but not least. A single app license starts from $1875 a month, limited to 50 internal users with a 3-year commitment. Enterprise license with the ability to deploy on premises starts from $7825, or almost $100K p.a. A decent enterprise with several thousand users will likely be paying multi-million annual fees.
Remember we are talking about relatively simple applications, as you could see from the above. To me, this is crazy. This pricing model is also prohibitive for distributing the applications you built.
Why are LCAP still popular then?
In my view, the answer is frustration. Managing development teams in large organizations - whether external or internal - turns out to be overly complicated. Advance budget planning, multiple stakeholders like architects or line managers with own agenda, lack of responsibility... It is just too hard to push your idea to implementation. The funniest thing is that a typical knee jerk reaction is hiring more developers and, of course, managers. Needless to say, this makes things even worse. I know a couple of banks with over 10 000 (!!!) developers and I know for a fact that at least half of them are doing useless work. In despair, business executives turn to magical solve-all-your-problems solutions like LCAP.
Getting out of this mess is a subject for a separate article. But this is a management issue, not a technological one. Skipping through details, if you manage to get a team of 3-10 reasonably qualified people fully dedicated to a project and with direct contact with the stakeholders and a decision-maker, you’ll get great results faster and cheaper than you think.
What are the Alternatives?
There is a great choice of developer tools and frameworks these days. As an example, Spring Framework is the most popular open-source technology for enterprise software, which can be nicely coupled with web frameworks like React or Angular. Tools like Spring Initializr and JHipster made this much easier over the last few years.
If you need faster results and easier adoption, it is worth looking at RAD tools like CUBA Platform. It is built on top of the same Spring Framework, complementing it with visual development tools and a marketplace of seamlessly integrated add-ons. This would probably be the closest alternative for LCAP for developers, still offering flexibility and convenient development process.
So there are many options around and the final choice should depend on the task, as well as your team skills and preferences.
Low code platforms are great for prototyping. They bridge business stakeholders with IT enabling them to produce visible results and gain common vision times faster. As there are very few users, the costs are also low. And this is exactly where you should seriously consider stopping!
If you continue, the development speed will slow down and you will be hooked more and more into an expensive and limiting proprietary platform.
As long as AI has not taken our jobs, enterprise software should be built by professional developers. So set an achievable goal, knock up a good small team with a competent lead, let them pick their tools and don’t forget to submerge them into the business domain. Very soon, you will see your ideas taking shape!