Is Low-Code Good Enough for Enterprise Software Development? Part II

What is low-code?

Low code/no code tools entered the development arena as a way of creating apps without coding. Awesome, isn’t it? Still, it doesn’t work equally well in every situation. Prosaic as it sounds, the deliverables depend on the goal you set before you put your hands on a low-code tool.

Why use low code?

Want to automate business workflows or make an internal app for a specific business function? Low code can help you do it fast and cheap. Yet low-code is likely to disappoint you in case you’re planning to build a great product to sell. 

In the front-end part, low-code is a way to go. As for the backend, the project I describe in this two-part series of articles, we still needed .NET capacities to tackle the complexities of the US insurance logic. A full-fledged framework gives us more freedom and control over what we want to do and how we want to do it.

Low code challenges

As long as business tasks are concerned, low code tools meet the demands just fine. Here are some minor challenges we faced when we used low code for our client, a US insurance company.

• Flexibility. We used Outsystems for the frontend, but we had to use .NET for the backend, because Outsystems could not handle the complex logic of the insurance domain.
• Version control. When one person updates the build, the others have to wait. Good project communication solves the issue, but it still can be annoying.

Is learning a low code can be a problem?

Is low-code going to be a challenge for your team if you plan to try it out on your project? 

Any full-stack developer with Angular and .NET skills can learn, say, Outsystems in a few weeks. We did not hire Outsystems developers, we trained our full-stack developers to use Outsystems.

As we are heading towards the end of my story, here’s one really important message for you.

Just as low code limits the creativity of the developer – remember, they are not writing code, but in fact playing with sort of a Lego constructor for money – low code also sets restrictions for the product owner, i.e. you.

Therefore, you need to weigh all pros and cons in order to see clearly which problem you are going to solve with low code solutions in each specific situation. 

And what if I want to sell the solution written on low code to make some money from it?

I don't think, or rather, I hope that this idea won't come to many, but just in case I’ll put it here for one last time. With low code you solve a specific problem within your specific company. The Alfa application I was talking about in Part I makes the lives of people in the Finance team easier. Instead of digging through Excel files and merging tables, they open the app, press two buttons and see the information they need. This is the tool to close a gaping hole. A functional, but not very elegant one. Still it works!

To see the results clearly, let’s go back to the start. Here’s at what state the Alfa application was before we placed our hands on it.

Let’s see how the Alfa application works now and the value it creates.

• The files are generated, edited and uploaded to the database automatically. There is an interface that allows employees to perform searches among the existing contracts in the database, change these contracts, create new ones (using ready-made templates / blanks for contracts), and set the role-based access control (viewing, editing, business segments and more), etc.
• All fields, values, data types in contracts uploaded via the Alfa application match the data types that are in the Omega application. We have all validations set up so two applications work in harmony. A simple example for you – if the user wants to enter a symbol in the field, and this field accepts numbers only, then the user won’t be able to do that.

Although I could simply mention that everyone on the Finance team is happy about the extended app’s functionality and new design, it’s crucial to remind you what I mentioned before – those deeper issues of custom software development cannot be solved with low code alone. Let’s see how the communication goes and the task is positioned before us. 

Together with the business unit, we create a detailed description of their pain points. The Symfa team leaves for a couple of days to sleep on it and comes back with a vision of how we can solve this problem using low code solutions or conventional coding, whichever suits us better in a given situation.

Here's another very simple example of how it works.

But John is capable of a lot more than paperwork and, honestly, this is not how it should be done in the age of business process automation. With our solution for bulk edits John automatically makes changes to all 50 contracts. As a result, an hour of work was reduced to a couple of minutes.

For this feature, we prepared for the customer both the logic (.NET) and the interface (Outsystems), made a demo and let them try it in their work. It’s just a teeny-tiny functionality, but the business unit says it’s a real life-savior.

The bottomline is – we built a fully functioning application on a budget within the specified timelines, with the back-end and APIs done on .NET, and the front-end built on Outsystems. The project was a success not because we used Outsystems, but because the team knew perfectly well which problems they should solve and the benefits expected.

Yes, if you have all the time in the world to get around the list of limitations imposed by the out-of-the-box solution. This was not our case. In addition, you need to understand how each specific customer makes these sorts of decisions. Our customer has all the infrastructure on Microsoft, and .NET is the main programming environment accordingly. Hence the combo.

Nope. In order to solve the customer's pain, you need to know the business well and where the problem comes from. We have been working with this customer for more than two years and have done 30+ projects together. The in-house engineers take us for their own as in terms of involvement and understanding of the customer's internal systems, we are no different from the customer's internal team.

So far, the answer is no. Those technologies are perfectly fine as helping tools, but they do not pose any danger to the development community.

See what our Solutions Architect has to say on the matter and wait for a new shiny article from my colleague, Alex Shumsky, Head of Presales, on Low-code for BI and Dashboards development that’s going live next week.

For more updates on how things are done in custom software development, follow us on LinkedIn. We post regularly on the modern practices and share useful tips to make your life easier on your custom software project.