Welcome back to the second part of this series, taking you along and explaining how we do fundamental research at VI Company. Last time, in the first part of this series, I already explained how we kicked off the project. We learned about the definition of low-code (vs. no-code) and how selected the technologies we put to the test.
In this second part, I will continue to explain how we were able to gather information about each of our selected technologies in a comparable way. I will also explain more about the rapid prototyping we undertook and the results of the experiment. So, without further ado, let us continue where we left off!
Quantifying the low-code platforms
After gathering of the required information was completed, we had to create an objective comparison. But how can you do this?
We started by setting up a scorecard containing 29 criteria, each belonging to one of the subjects we used to gather the information. For each criterium, we also thought of a scale to measure it. As an example, we will look at three criteria within the ‘Features’ subject:
Using these criteria, we filled in the scorecard for each of the 13 selected alternatives to be able to compare them.
In the table below, you can see the average results per subject for five of the most popular low-code platforms that also scored high on our scorecard. Although it can be hard to read the results without the full scorecard, you can easily see they perform equally when it comes to features and the biggest differences can be found when it comes to pricing and the technical match.
Putting them to the test
However, these numbers do not give insights into the usability of these platforms and the leverage that they offer in comparison with traditional development projects. To be able to say more about that, we were going to build prototypes using each of these 5 alternatives.
For these prototypes, we selected a real client reference case that focused on ETL purposes (extracting, transforming, and exporting data from a spreadsheet). In the past, we already built a full-code prototype for this reference case that took around 16 hours to complete.
We set up a list of requirements that needed to be met:
- The prototype should be able to read data from the input spreadsheet.
- The prototype should be able to parse and use the formulas from the spreadsheet to perform calculations.
- The prototype should be able to display the output using a dashboard or report functionality.
- The maximum amount of time spent per prototype is 8 hours.
| Mendix results | |
|---|---|
| Read data from the input spreadsheet | ✓ |
| Parse and use formulas from the spreadsheet | ✓ |
| Display output using a dashboard or report functionality | X |
| Time spent (hours) | 8 |
Uncharacteristically from Microsoft, it again proved difficult to automatically import the spreadsheet. We managed to read, extract, and calculate the data once using a workaround. However, after changing the parameters, we were not able to recalculate the spreadsheet and update the output. This was a bit disappointing since you would expect Microsoft to have the best integration.
Although the interface felt very familiar and lowered the learning curve, it was originally designed for Office and did not always suit the purpose of a low-code platform. Hence, the platform did not feel very intuitive and sometimes functionality was limited.
| Microsoft Power Platform results | |
|---|---|
| Read data from the input spreadsheet | ✓ |
| Parse and use formulas from the spreadsheet | ✓ |
| Display output using a dashboard or report functionality | X |
| Time spent (hours) | 8 |
One of the biggest letdowns was the inability to export or redistribute data to other platforms, although the visualizations available in Tableau looked good.
| Tableau results | |
|---|---|
| Read data from the input spreadsheet | ✓ |
| Parse and use formulas from the spreadsheet | ✓ |
| Display output using a dashboard or report functionality | X |
| Time spent (hours) | 8 |
Although the documentation is hard to find and browse through, there is still sufficient information to find your way around the platform. However, their visual workflows to create business logic feels limited and makes simple tasks, such as creating loops or lists of values, much harder in comparison to normal programming.
OutSystems does not offer spreadsheet importing functionality out of the box, but their online store contains many plugins that can be used for this purpose. Within 6 hours, we succeeded to create an app that imports the data and used the parameters to change the output.
| OutSystems results | |
|---|---|
| Read data from the input spreadsheet | ✓ |
| Parse and use formulas from the spreadsheet | ✓ |
| Display output using a dashboard or report functionality | ✓ |
| Time spent (hours) | 6 |
Most of the functionality is data-related, and they are very good at it. Importing, cleaning, aggregating, or finding relations are just some of the basic tasks they make easier. But they also support more complex tasks, like automated data modeling and pattern recognition.
There is a lot of documentation available, and an academy and community to learn how to use Alteryx’s tools properly.
In the end, for our reference case, Alteryx seemed the perfect fit because it was very data-focused. We managed to comply with all the requirements within only 5 hours.
| Alteryx results | |
|---|---|
| Read data from the input spreadsheet | ✓ |
| Parse and use formulas from the spreadsheet | ✓ |
| Display output using a dashboard or report functionality | ✓ |
| Time spent (hours) | 5 |
Lessons learned…
Along the way, we learned there are many low-code solutions available that might answer your needs. However, finding the right one is a challenge.
Many tools have great marketing pages, but there is no such thing as “one tool to rule them all”. So how do you make the right decision? Our approach might help you to find the right platform for your purpose. For our specific use case, this was Alteryx. But every tool has its pros and cons, and although proper research takes time you will greatly benefit from it.
Like with any other new technique, we found that low-code does some things very well (e.g. working with lots data or rapid prototyping), but less well with other things (e.g. tasks might even take longer to complete, and are not solved better, quicker or easier using low-code instead of traditional full-code development).
We will continue to approach intrinsic or extrinsic needs tech-agnostically by finding the right solution for the right problem (as we call it, the “Pipi-mentality”). In some cases, this means low-code is a very good fit. In other cases, we would recommend full-code solutions or even hybrid solutions consisting of both low-code and full-code components.
Alteryx Partnership
After rounding up this project, we at VI Company were determined to keep investigating in low-code. This recently resulted in us becoming official Alteryx Partner, after some of our colleagues got officially certified. We hope this will contribute to keep bringing the best fitting solutions to our clients in the future.
Contact us
Are you curious to learn more about low-code? Our solution engineer Kevin Wareman is happy to tell you all about it. You can contact him via kevin@vicompany.nl.
##**Related articles** - Fundamental research into low-code pt. 1 - How can we bring innovation and digital transformation to financial markets?