Critical features include ease of use, scalability, security, robust integration capabilities, comprehensive API support, reliable data transformation, exceptional monitoring and analytics, and flexible pricing.
Ease of Use
Scalability
Security
Robust Integration Capabilities
Comprehensive API Support
Data Transformation
Monitoring and Analytics
Flexible Pricing
In choosing an iPaaS solution, ease of use is vital to ensure quick adoption by cross-functional teams. Scalability allows for growing business demands without compromising performance. Security is paramount to protect sensitive information during integrations and complies with regulatory requirements. Robust integration capabilities facilitate seamless connections among various systems and applications. API support is essential for integrating modern cloud-based applications. Reliable data transformation handles diverse data formats, smoothing out differences between systems.
Monitoring and analytics provide insights into integration performance and potential issues, helping maintain system health. Flexible pricing supports different use cases, accommodating enterprises of varying sizes. Additionally, the ability to perform real-time processing and support for hybrid cloud architectures are important considerations. An iPaaS that ensures smooth operations while adapting to changes in the technological landscape is an asset to any business. These features collectively enhance efficiency and drive innovation.
Search for a product comparison in Integration Platform as a Service (iPaaS)
Senior Principal Architect at Invenio Business Solution Pvt Ltd
User
Jul 13, 2021
I was previously part of the Oracle SOA/OSB development team. I was putting the product onto Cloud as SOACS. In my current capacity I architected solutions using MuleSoft Anypoint Platform on cloud / on-premises and hybrid modes and on PCE/RTF on Self Managed Kubernetes and On premise apart from regular CloudHub Deployment;
Integraiton is always a heavy one not like applilcation development as you are trying to make disparate systems to work together seamlessly. There are different kinds of solutions based on Traditional SOA, ESB which are heavy/monolithic but proven w.r.t. transaction management/coherent closed integrations which work; -- Oracle SOA/OSB or
The monolithic solutions are evolving into Microservices for agility, management and for giving more freedom to the individual business units to explore and innovate as time to market is the most imporant factor in the modern world.
I would consider the following when I am evaluating the platform:
1. What is the business use case?
-- Is it standard integration file/FTP, Batch and Dataload kind of stuff or
-- Business Transformation from legacy to Modern?
-- What is the future I am projecting?
2. What is the feature set for the product I am looking at?
-- This is driven by point no 1;
-- Do I need low code platform -- these are costly like Mule Anypoint Platform
3. Would the open-source solutions fit my bill like Spring Integration with VMware Tanzu or Apache Camel as RedHat Fuse etc.. -- These would bring down the TCO greatly when you compare them with MuleSoft Anypoint Platform or Oracle SOACS or Oracle OIC etc.. But the trade-off is you need to spend time more in development and managing your code. (What I observed in practice is Managing the code once the solutions stabilize will be almost the same on both)
4. What is my budget?
5. What kind of resources do I have?
-- What time I can give them to ramp up w.r.t. technology
-- Quality of the Resources.
6. What are the kinds of protocols I am talking about?
-- Transport -- HTTP/Websockets/FTP etc..
-- Data protocols -- Database/SAP/Salesforce
-- OOB support for Adapters I am looking for
7. Need for HA / DR
-- will my IT team be maintaining this or the PaaS provider can take care of it?
-- does my product support the same?
8. What is the RPO/RTO I can afford?
9. Does the solution require Distributed Transactions or can I close it with Microservices with SEDA / CQRS patterns?
10. If legacy to modern -- and I am choosing transformation -- does my platform/solution support business continuity in the journey of transformation?
11. Need for securing the solutions/services along with the need for RBAC etc.
Consulting Software Engineer at Singhpora Consulting
Real User
Top 20
Jan 28, 2021
Total cost of ownership - identify how much the platform costs to run for a given volume of messages/requests or data per unit time.
Secondly, identify how much would it cost to develop and deliver actual functionality on the platform (typically involves data flows, integration flows, message transformations, unit tests, deployment scripts etc.). Developers tend to be highly skilled on particular platforms but many can transfer skills easily. Generally, Java developers could work well with iPaaS platforms like Mulesoft or similar (e.g. an Apache Camel or Spring boot variant provisioned on a cloud platform) whereas adopting Oracle Integration cloud could take some transition unless they already work with Oracle products.
Thirdly, it helps to know what the customer's existing environment consists of - for instance, if it heavily uses Oracle products, then Oracle Integration Cloud (OIC iPaaS) might be the most suitable. Generally, developers with experience on other Oracle technologies and experience of working with Oracle support should ramp up very quickly on this. OIC is also very easy to provision and has predictable costs for generous message allowances.
In terms of features, most integration platforms offer the standard types of connectors (http Rest/SOAP, file, ftp, databases, message queues, plus a range of other connectors to somewhat ease integration with various cloud or in-house products), message transformation tools (like XSL, XQuery, XPath), and means to expose callable services like Rest or SOAP. Although principles are the same, it takes some time to ramp up developer productivity on the specific platform of choice. The actual runtime performance on any platform will depend on both iPaaS platform's quality AND how well the actual applications developed to run on it cater to non-functional requirements (like scalability, concurrency, response time, throughput, etc. etc.)
Integration Platform as a Service (iPaaS) connects applications and services, facilitating seamless data integration. It streamlines workflows between cloud and on-premise solutions.Integration Platform as a Service (iPaaS) offers businesses a comprehensive way to integrate diverse systems efficiently. By automating data flow and connecting disparate software solutions, iPaaS minimizes manual data handling, reducing errors and improving operational efficiency. It supports scalability,...
Critical features include ease of use, scalability, security, robust integration capabilities, comprehensive API support, reliable data transformation, exceptional monitoring and analytics, and flexible pricing.
In choosing an iPaaS solution, ease of use is vital to ensure quick adoption by cross-functional teams. Scalability allows for growing business demands without compromising performance. Security is paramount to protect sensitive information during integrations and complies with regulatory requirements. Robust integration capabilities facilitate seamless connections among various systems and applications. API support is essential for integrating modern cloud-based applications. Reliable data transformation handles diverse data formats, smoothing out differences between systems.
Monitoring and analytics provide insights into integration performance and potential issues, helping maintain system health. Flexible pricing supports different use cases, accommodating enterprises of varying sizes. Additionally, the ability to perform real-time processing and support for hybrid cloud architectures are important considerations. An iPaaS that ensures smooth operations while adapting to changes in the technological landscape is an asset to any business. These features collectively enhance efficiency and drive innovation.
I was previously part of the Oracle SOA/OSB development team. I was putting the product onto Cloud as SOACS. In my current capacity I architected solutions using MuleSoft Anypoint Platform on cloud / on-premises and hybrid modes and on PCE/RTF on Self Managed Kubernetes and On premise apart from regular CloudHub Deployment;
Integraiton is always a heavy one not like applilcation development as you are trying to make disparate systems to work together seamlessly. There are different kinds of solutions based on Traditional SOA, ESB which are heavy/monolithic but proven w.r.t. transaction management/coherent closed integrations which work; -- Oracle SOA/OSB or
The monolithic solutions are evolving into Microservices for agility, management and for giving more freedom to the individual business units to explore and innovate as time to market is the most imporant factor in the modern world.
I would consider the following when I am evaluating the platform:
1. What is the business use case?
-- Is it standard integration file/FTP, Batch and Dataload kind of stuff or
-- Business Transformation from legacy to Modern?
-- What is the future I am projecting?
2. What is the feature set for the product I am looking at?
-- This is driven by point no 1;
-- Do I need low code platform -- these are costly like Mule Anypoint Platform
3. Would the open-source solutions fit my bill like Spring Integration with VMware Tanzu or Apache Camel as RedHat Fuse etc.. -- These would bring down the TCO greatly when you compare them with MuleSoft Anypoint Platform or Oracle SOACS or Oracle OIC etc.. But the trade-off is you need to spend time more in development and managing your code. (What I observed in practice is Managing the code once the solutions stabilize will be almost the same on both)
4. What is my budget?
5. What kind of resources do I have?
-- What time I can give them to ramp up w.r.t. technology
-- Quality of the Resources.
6. What are the kinds of protocols I am talking about?
-- Transport -- HTTP/Websockets/FTP etc..
-- Data protocols -- Database/SAP/Salesforce
-- OOB support for Adapters I am looking for
7. Need for HA / DR
-- will my IT team be maintaining this or the PaaS provider can take care of it?
-- does my product support the same?
8. What is the RPO/RTO I can afford?
9. Does the solution require Distributed Transactions or can I close it with Microservices with SEDA / CQRS patterns?
10. If legacy to modern -- and I am choosing transformation -- does my platform/solution support business continuity in the journey of transformation?
11. Need for securing the solutions/services along with the need for RBAC etc.
Total cost of ownership - identify how much the platform costs to run for a given volume of messages/requests or data per unit time.
Secondly, identify how much would it cost to develop and deliver actual functionality on the platform (typically involves data flows, integration flows, message transformations, unit tests, deployment scripts etc.). Developers tend to be highly skilled on particular platforms but many can transfer skills easily. Generally, Java developers could work well with iPaaS platforms like Mulesoft or similar (e.g. an Apache Camel or Spring boot variant provisioned on a cloud platform) whereas adopting Oracle Integration cloud could take some transition unless they already work with Oracle products.
Thirdly, it helps to know what the customer's existing environment consists of - for instance, if it heavily uses Oracle products, then Oracle Integration Cloud (OIC iPaaS) might be the most suitable. Generally, developers with experience on other Oracle technologies and experience of working with Oracle support should ramp up very quickly on this. OIC is also very easy to provision and has predictable costs for generous message allowances.
In terms of features, most integration platforms offer the standard types of connectors (http Rest/SOAP, file, ftp, databases, message queues, plus a range of other connectors to somewhat ease integration with various cloud or in-house products), message transformation tools (like XSL, XQuery, XPath), and means to expose callable services like Rest or SOAP. Although principles are the same, it takes some time to ramp up developer productivity on the specific platform of choice. The actual runtime performance on any platform will depend on both iPaaS platform's quality AND how well the actual applications developed to run on it cater to non-functional requirements (like scalability, concurrency, response time, throughput, etc. etc.)
Self-service
The ability of dev teams to subscribe, configure, test and then publish
The ability of consumers to subscribe
The ability to manage subscribers API keys
The ability to produce usage reports and get feedback