Let’s discuss the most commonly used integration approaches and the factors to be considered by clients while choosing an integration solution for the new SaaS and their on-premise legacy applications.
Standard On-Premise Middleware Integration
You can use traditional on-premise middleware for integrating with new SaaS applications acquired by your company. For example, with integration products like Oracle SOA Suite that offer cloud adapters, you have ways to interact with SaaS application securely, but there are limitations in supported platforms and there is still dependencies on developers with Oracle skill-set.
The other difficulty of using Oracle SOA is that its implementation often involves maintenance and staff training costs as well as the costs in the form of middleware and hardware that decreases the value and purpose of SaaS services.
Custom Developed Point to Point Integration
Many companies used FTP in the pre-cloud era for transferring data across systems. Using written shell scripts or custom Java code to invoke the FTP on a scheduled basis was also common among enterprise systems.
With the advent of widespread SaaS applications, supporting the modern standards such as REST, JSON in addition to SOAP protocols for exposing data, integrations can no longer work via FTP and force customers to move out of these legacy approaches.
Custom development using Node JS/Java may seem promising for smaller integration projects, the complexity of IT architecture grows immensely as the number of SaaS applications increases. In the end, it leads to multiple protocols, toolsets and security mechanisms involved.
Commonly small and midsize businesses are trying to use their preferred vendors for SaaS integrations, with custom development approach on a fixed price contract.
Integration Platform as a Service (iPaaS) Approach
Just a few years ago, an integration project always involved an army of consultants and a mix of custom technology and would take several months or years to come to complete with million dollar investment.
Moving back to our time we have a situation where small and midsized businesses want to try out integrations starting to use their newly acquired SaaS applications. After few weeks if a new SaaS application would fit well in their portfolio they can proceed with it. If not, they need to move fast with the next set of vendors.
Subscription based services are a great idea as they allow business users to move faster than ever because they are easier to setup and can start working on integrations and business processes from day one, leaving the maintenance worries with the cloud vendor and avoid large upfront capital investments. They also require only periodic operational expenses.
This certainly makes us think if iPaaS can be used for integration scenarios that do not involve data-intensive transactions and/or low-latency messaging, and where faster time-to-value is a critical requirement, along with the existing on-premise integration strategies for addressing on-premise integrations. Companies like Oracle call this approach the Hybrid Integration.
Key questions to ask while selecting an iPaaS vendor
- Is the iPaaS vendor offering an interface allowing business and product level users to add and edit integration rules ?
It won’t be a bad idea to check what skillset is required to use those integration products offered by vendors. For example, if a cloud vendor’s solution expects your team to have Java/Spring skillset, it’s a strict NO for your business team to adopt such integration tool.
- Does the iPaaS vendor provide native adapters to connect with SaaS or on-premise applications?
- Are the adapters well supported by a stable business or just the community resources?
- Are the adapters well documented and the documentation is up to date with the applications they are integrating with?
- Does the iPaaS solution have capability to recommend mapping of data across the systems you are trying to integrate?
- Does the iPaaS solution provide orchestration to support data flowing across different systems?
- Does the iPaaS vendor have a API Management and a workflow automation solution too or dependent on any third party company?
- Does the iPaaS solution provide a centralized console for scheduling, monitoring, and managing integrations?
- Does the iPaaS solution should provide enterprise-grade security and governance features?
- Does the iPaaS vendor have on-premise support capability too to support integration with on-premise applications?
- Any lock in period or contract with the iPaaS vendor?
How CloudGeometry can help
At CloudGeometry, we have integrated dozens of data providers, SaaS, PaaS and IaaS system on our clients projects. We have many years experience in working with APIs of popular data providers as Facebook, Google, Amazon, Twitter and the full range of Ad Networks. These APIs are frequently updated and we have to design and build special flexible systems to quickly change the integration rules without an impact to the downstream systems.