Low-code tools are promising to democratise software development. Sometimes I’m afraid to open the fridge not to meet another such tool. But are they delivering on this promise? The answer is not a simple one.
Is there a low-code tool for everyone?
First, it’s good to define who are the “citizens” that we want to empower. We’ll leave out all the tools that focus on creating UIs with a relatively simple backend. They are usually aimed at people that need e.g. to prepare a survey or a marketing campaign, or create an onboarding guide. These are certainly valid, needed use cases, but we don’t want to focus on them.
The other important group, which gains much traction nowadays, especially within a real-time, data-driven world, are various analytical tools. There are many interesting examples there, and their main goal is usually to let users gain interesting insights - often in the form of dashboards. Again, we’ll not be talking about them here.
But what about tools that would be able to define the behaviour of core parts of your system? Surprisingly many of them are actually tools for various types of data integration - think e.g. Confluent Stream Designer, AWS Workflow Studio or NodeRed. If you look closer, you’ll notice that they are aimed at developers - or people with similar skills. Usually, you need to grasp the technical details of data structures, connections etc.
While we think there is a place for all of the above, this leaves us with a question: what about business/domain experts who want to be able to quickly define and control the business rules of their application? (We’ll call them Subject Matter Experts or SMEs below). No matter if it’s a relatively low-traffic credit score site or a massive stream of communication data.
Democracy is about making decisions!
While we believe the idea of empowering SMEs to define business rules is a powerful one, we don’t think it’s reasonable to assume that all kinds of logic can be managed this way. There are a lot of examples where it ended up tragically.
If we stretch the democracy metaphor a little bit more, we’ll see that while the citizens decide about rules (or policies) in various votings, the exact technical details of the laws are handled by professionals - economists, lawyers etc.
The same in application development - there are certain aspects like performance, transactions etc. that should be handled by skilled developers. Business logic itself also has a certain part that requires special handling - critical parts, rules that influence each other etc.
What’s left? In the programming world, there is a notion of a policy - a piece of code that encapsulates variable decision rules. Most of us are probably also familiar with the concept of business rules and business rules engines.
These are not new concepts, so why do we feel it’s time to bring them back?
Business rules done right?
We considered and used Business Rule Engine (mostly Drools) in a few projects in the past. Sometimes the results were better, sometimes worse. A common observation was that the rules and how they interact with each other were often unintuitive (even for developers) and their definition was far too complex to be done by SMEs.
Of course, this could be caused by several issues:
- We wanted to push too much logic to the rules, as we didn’t know the concept of a policy at that time.
- The rule definition language was not suitable for the rule we wanted to create.
Let’s stop for a while with the second problem - how do we present a decision algorithm? We think in many cases we’d be far closer to the goal if we depicted decision algorithms as a graph (users do it quite often, e.g. with MS Visio).
The other important aspect is general UX - the developers have advanced validations and suggestions in their IDEs - why shouldn’t they also be available for SMEs? Too often tools end up with a simple input to enter expressions - the experience similar to coding in a Notepad.
Last but not least, the aspect that differs us from the days of Rule Engines is the world around us. We believe that today’s architectures - modular, event-driven, based on microservices or lambdas - are far more friendly for components externalizing policies than it was in the Days of the Monolith and Waterfall.
Clean or quick?
There is one more problem that has to be addressed: how to hide technical details from SMEs. One part is not so difficult (but extremely important in our opinion) - we must leave configuration details for developers/operations (this is what differentiates Nussknacker from many low-code tools aimed at developers like NodeRed, etc). The user should not care about connections, passwords, or communication protocols - just the data at their disposal.
But here comes the other problem - in many fast-paced environments the data is not as clean as we’d like it to be - no matter if it’s DB structure, event schemas, or the REST API.
In a well-written application, an adapters layer usually takes care of the cleaning. We do believe that such a layer is needed also in architecture with a low-code tool for the rules - and that this layer should be written and handled by the developers.
Nevertheless, often an urgent need arises to use unprepared data or API - it may be necessary to define rules even if they won’t be as easily readable as we’d like them to be. This may mean SMEs will need some help with their work from technical staff. Actually, in some cases, the experts may know quite a lot about the data and its structure. Let’s take two examples for comparison:
- In marketing, the domain experts are usually more focused on social media, interactions, and so on, than on the exact shape of product data or a client profile. They’ll probably need some help to turn their ideas into precise rules.
- Fraud detection is different - as people detecting frauds usually work with the data to analyze them, and tend to know the structure pretty well.
The general approach should be pragmatic: while we should aim at hiding all technical complexities of underlying systems and data, sometimes we have to accept that there will be cases where technical help for the experts (temporary or permanent) will be needed.
Business rules: making it easy for domain experts
So, do low-code tools democratise software development? In many areas, they certainly do - from analytics through simpler webapps to data pipelines. However, we (as the software development world) are still not there when it comes to the democratisation of defining business rules or policies. The needs of domain experts are not satisfied. It’s not easy to find a tool that allows you to author business rules without technical details.
There are a lot of good, sound ideas in the concept of the business rules engine. We just have to leave centralized, drools-ridden baggage and bring fresh UX ideas to deliver their promises in a fast, real-time world. Nussknacker is our take on that.
Want to learn more? Be sure to check out our whitepaper or drop us a message at info@nussknacker.io