While low-code technologies have become mainstream, there are some concerns raised when talking with those in management that have not worked with a low-code platforms. And to be fair, they are valid concerns – given the right context.

So, I’ve decided to dedicate this blog to three of the more common concerns: limited flexibility, throughput, and testing.

Limited flexibility

This is probably the concern that comes up the most. It comes less from the business side and is more often mentioned by developers, particularly developers with experience in specific languages and frameworks.

It is true that low-code platforms do limit flexibility. But in the end, they are tools for a ‘practitioner’ to use. And, just like a hammer, they are very good at specific tasks and not so good at others. For example, if you need to nail something, then a hammer is an excellent tool, but if you need to screw something together, it’s not so helpful. Similarly, if you want to create the most immersive first-person shooter game, a low-code solution is probably not going to do the job, but if it relates to business logic, inputs, outputs, translation of data, etc., low-code solutions are well suited.

In fact, one might argue that solutions around logic, inputs, outputs, and translation of data are a perfect fit for a low-code platform. I’d even say, low-code platforms are often the superior approach to addressing those types issues.  

While low-code platforms may limit your scope, they dramatically speed up development time. And, they aren’t designed to replace all custom coding, rather they are meant to take on certain use cases. Other use cases would be developed in standard languages and frameworks.

Also, with an increasing number of API-driven services entering the market, adding flexibility within a low-code platform is getting easier.

Throughput

If I get agreement on my response to concern for lack of flexibility, the next point that usually comes up (at least by the more technical folks I speak to) is throughput. More specifically, the ability to handle computation and execution quickly. Think managing stock trades or credit card processing.

And, in fairness, some low-code platforms are simply not suited for that type of work. They are excellent when it comes to ‘front-end’ types of activities, such as case management, or data entry. But when it comes to managing a high volume of transactions or data, they quickly reach bottlenecks. Again, this goes back to the intent of the solution. Was it designed for high throughput, or for more front-office type of activities?

Part of the solution lies in using the platform for its intended purpose, but there is also another part: finding the right low-code platform for your needs. The dirty secret is that not all low-code platforms were designed for the same reasons. Some were designed with a focus on business process, others for IT management, and still others for sales and customer relationship management.

In our case, we’ve focused on financial businesses. Even more specifically, we focused on providing a low-code platform that supports rapid development for solutions that involve financial messages and transactions.

Testing

One of the benefits of many low and no-code tools is that testing of components has already been completed. The different components that exist in a platform have already been tested together to ensure compatibility. But, at times, a business can make the mistake assuming that testing is not needed, or only rudimentary testing is needed in a low-code or no-code context. That can lead to problems, including applications that don’t function as intended.

One criticism, occasionally mentioned, has to do with lack of proper testing leading to services that don’t function as they should. Yet, traditional ‘unit testing,’ as is done in development shops today, doesn’t quite cover the tool’s capabilities.

When it comes to low and no-code tools it’s important to seek ones that have testing capabilities built-in. But, more importantly, while testing should be done, it should be done differently than traditional coding. For no-coding tools, simple functional testing is usually adequate.

In a Volante context, you could consider our Corporate-to-Bank integration service as a no-code solution. While it is built on top of our low-code platform, the service itself is no-code, and business users simply map different inputs from a corporate client’s treasury or ERP system to a bank’s systems. No coding is required. Once the mapping has been done you would use the built-in testing functionality to test that integration’s flow.   

Low-code platforms, by contrast, might need a bit more depth in their testing approach as they can often include complex logic and detailed calculations. Again, using Volante as our example, our low-code platform allows for highly complex financial transactions to be supported, and testing those would be done inside of our platform. But, arguably, the best way to test them (depending on complexity) might be to break them up into smaller parts to ensure different logic elements work as desired.

Even in this case, however, we are not doing unit testing as we would with traditional development, but rather we are doing component-based and functional-level testing.

Hopefully that helps clarify a few of the issues financial businesses looking to embark on the low-code journey might be facing. What about you? If you have concerns that haven’t been addressed in this blog I’d love to hear them. Fill out the ‘Contact Us’ form and ask for me. I’m always interested to hear what others are thinking around low-code vs. no-code vs traditional coding.