I consulted with a company using boomi which appears as one of the winners in the article.
In my experience, it was painful and the solution should have been replaced with a small in-house custom script.
Boomi uses some visual scripting that seems to require a lot of training. I suspect this is the salespitch - programmer not required. Instead, you end up needing consultants specialized in this particular system which are even more expensive.
In the end, boomi worked for this company as an expensive, complicated message queue.
One of the key benefits of an iPaaS is the pre-built connectors to popular systems and servives. Did the solution not require connecting to external systems?
I consulted for an energy company using Boomi and like you was surprised to see it in the top-right quadrant. I remember version control being a nightmare and the platform having serious scaling issues.
iPAAS' are essentially ESBs remarketed for the cloud for organatisations without the in-house expertise to coordinate building their own integration hub with a combination of tools like Kafka and API management gateways.
Organizations lacking the
* Architectural leadership
* Coordination capabilities
* Engineering resources
* strong comms between teams
tend to go for these solutions to paper over their existing problems. Particularly those around engineering capabilities.
These solutions work great for a while until the edge cases around data arrival and consumption usages resurface.
It's important to note that these solutions shine when it comes to the API discoverability across teams and light data format translations but as soon as that has happened get your data out quick!
Don't be tempted by their in-house solutions that try to solve caching, scaling and the ETL languages provided because they will tend to be half-baked and not as battle tested and will lock you in. The commitment for a large org using these systems is a 5-10 horizon.
By all means check them out and be ready for alot upfront design work to find the sweet spot and alot of engineering effort and frustration (alot).
i'm working in the enterprise integration field for a few years now. most vendors seem to have no idea how to get their integration product in the cloud. most of the time its just their old product as a docker container.
graphical drag and drop languages are everywhere. mulesoft has their anypoint studio, software ag has their flow language. at least for software ag i know you can barely refactor this graphical stuff unless you edit the source xml files by hand (bad practice, i know).
even as an expert those products are hell to develop. i have never felt so unproductive. big, clunky, barely usable ...
most of our customers moving away from big platforms like that. some move to java+api spec+api gateway, some go a step further and put their apps on k8s.
In my experience, it was painful and the solution should have been replaced with a small in-house custom script.
Boomi uses some visual scripting that seems to require a lot of training. I suspect this is the salespitch - programmer not required. Instead, you end up needing consultants specialized in this particular system which are even more expensive.
In the end, boomi worked for this company as an expensive, complicated message queue.