I can’t provide a complete comparison between the services you plan to use, but your question is quite interesting, so I decided to share my thoughts and experiences and I hope that you will benefit from this.
Ready-made connectors are not new - they existed long before SaaS and iPaaS became things. Thus, their pros and cons are still the same, the main problems that you will consider are still very related to the lack of flexibility that you will encounter, and, of course, to the disadvantages of point-to-point integration. Things are somewhat refracted through the prism of SaaS / iPaaS, but I believe that most aspects are still relevant.
Features and support for off-the-shelf connectors
You need to evaluate the extent to which the finished connector really covers the integration between the two systems. Services like salesforce pride themselves on being customizable and extensible using third-party extensions. In most cases, the connector will follow the one-time use principle, which satisfies the simplest and easiest integration needs of all. All this is fun and games until something changes. It is impossible to know in advance what you may need in the future, but think about it - can you count on the fact that your settings and extensions will be covered with a ready-made connector if you also decide to integrate them?
Another thing you should consider is support — what happens if one of these companies suddenly decides that they will no longer support future integration with the ready-made connectors that you already use? You should check if you have any warranties.
Blocking a hard link and a service provider
Using point-to-point connectors connects systems to each other, so you will greatly limit your options for switching between platforms if you need at some point. Now, this may seem like a fairly simple integration scenario, but adding more systems to the mix over time makes things even worse, since you will have dependencies between yourself and there, and not every new system will have a connector out of the box to easily integrate with everyone else that you already use. Having middleware gives you the valuable ability to map and transform data if necessary, and maybe even apply some business logic that makes your life a lot easier (and cheaper). You can also replace the system without having to replace others, depending on it.
Consider your scenario: if you decide to change your billing system, you will need to find one that is properly supported by both CRM and ERP providers. Thus, you can potentially block the use of these three, even if, for example, they no longer meet your needs or there is something else on the market that would give you an excellent competitive advantage if you could integrate with it.
Orchestration and future investment
An important note about the p-2-p scenario is that you cannot implement the process services that will be used on all systems if necessary. The added flexibility and benefits of using even simple forms of orchestration (I'm not even talking about achieving what can be achieved using full-featured business process management) will not be available for your business. When the market changes, and time to market is a decisive factor, you may not be ready.
Thoughts on choosing iPaaS
Using the iPaaS platform in the long run looks much better. However, you still need to make sure that the platform not only gives you a set of predefined connectors, as well as drag & drop beautyies (they all do), but also makes it easy to implement your own integrations from scratch, supporting industry standards. I believe that it’s absolutely necessary to have such flexibility when it comes to ESB solutions, whether in the cloud or indoors.
Potential disadvantages of the iPaaS approach are:
- you depend on another service provider and you will have more costs because the service is not free;
- your data is transferred to another service provider, so there is an additional security risk, regardless of what the service providers can tell you;
- more efforts to develop and implement;
- an additional burden associated with the need to support integration and take into account potential changes (however rare they may be) if a new version is released.
Conclusion
All this is truly a compromise between the desired flexibility and the investments that you are ready to make. Your decision will largely depend on the current state of your business and your expectations for future growth, and not on the purely technical side.
I hope my thoughts gave you some perspective. Please update the question with your decision and reasoning when the time comes. Good luck