iPaaS – Integration Platform as a Service
altkomsoftware.pl
altkomsoftware.pl
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.
* 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).
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.