Low-code & No-code

As a Java developer and integration analyst, I've encountered several implementations of low-code and no-code solutions for integration services. My most notable experiences are with WSO2 Enterprise Integrator/WSO2 Micro Integrator and Karavan. Initially, I found it convenient that payload transformations could be achieved by clicking in a GUI without having to generate chunks of code. The graphical representation was also beneficial, providing a clearer understanding of what a given service does. In the case of Karavan, an operator could be used to trigger services simply by defining a route in YAML, and the operator would package and deploy it as an application.

However, this seems more suitable for simple integrations like receiving a message, remapping the payload, and sending it to a target application. In my IT experience, I've never encountered such a straightforward implementation. Customizations were always needed based on customer requirements, and predefined functions were often insufficient. For example, merging two arrays from two API calls might require creating a Java class, a skill not every analyst possesses. Consequently, service development always shifted towards a development team with programming knowledge, or integration analysts transformed into development teams.

From my experience, developers are reluctant to use GUIs that render flows slowly, making it challenging to easily test and run services. They would prefer not to write services in XML, as is the case with Camel XML DSL. Why bother when they eventually have to write something in Java? It's more appealing to have everything in one language, and it's much simpler to click a play button in IntelliJ IDEA, start a Spring Boot application, and call the API from Postman. With WSO2 services, having a running server on your machine was necessary for deploying the application, and community applications had to be deployed to utilize company-wide common processes like API calls and logging.

Karavan presented challenges for creating a folder structure or a Java class for object mapping. I see so many drawbacks that my recommendation is, if you're purely open source or low-cost, steer clear of low-code/no-code solutions and write it traditionally in a programming language. You'll find developers more easily, and you won't have to worry about losing someone with deep understanding, which might hinder your delivery. Believe me, especially concerning Java developers, they have options today and won't choose something where they have to define services in XML/YAML. Perhaps juniors might, but even they will want to progress eventually.

However, if you have a budget and want a more robust solution, I can recommend Boomi or Informatica.