What is it?
Integration Platform as a Service (IPaaS) is a definition that analysts, vendors and organisations use to refer to a specific category of integration technologies. Initially viewed as mid-market low-code SaaS integration technologies, analysts began to position them as part of a Hybrid Integration Platform or part of an enterprise’s overall capability framework. It is seen as a bridge between cloud/SaaS and on premise application and integration technologies. Typically we expect to see the following from IPaaS technology:
- Low-code UI
- Connectors for common SaaS systems
- Templates/blueprints/recipes for integration patterns
- Support for multiple integrator roles
- An ability to expose integration processes as APIs
- A basic level of API Management capability
Value proposition of the capability
The value in IPaaS as a solution technology is generally in its pricing and time to value. Historically, integration was always viewed as an expensive undertaking with license costs regularly running to 6 and 7 figure contracts. Delivery was also complex and required a high degree of skill and experience in order to be successful. Most IPaaS vendors boast low-code development platforms, reusable templates and connectors to assist in rapid deployment of solutions.
The need for skill hasn’t gone away though and complex integration processes are rarely delivered by unskilled integration resources. What has happened is that non-developers and SaaS power users are now able to deliver some integration scenarios. All IPaaS offerings generally have some feature capability that supports scripting and there is a reason why it is there. It gets used.
Time to value is generally realised through the tooling supporting the overall productivity of the integration developer. Taking away the need to script certain capabilities, template processes, popular SaaS connectors, simplified deployment, management and monitoring. Combined, these capabilities help reduce the overall total cost of ownership of these solutions compared to more traditional integration approaches.
Common uses or use cases
The most common use cases for IPaaS generally involve integration of SaaS endpoints either with each other or with on-premise systems. Common scenarios include Quote-to-Cash, Joiners, Movers & Leavers and Procure-to-Pay. Moving ‘Closed Won’ opportunities from Salesforce/Microsoft Dynamics to accounts/customers with invoices in an organisations finance system. Alternatively, co-ordinating online orders with CRM/Customer Service systems, Fulfilment Systems and Finance.
Many mid-market organisations use solely IPaaS technologies within their integration strategies as they are heavy SaaS adopters, and these technologies provide solid coverage of their integration needs. In large enterprises, IPaaS allows for integration delivery with SaaS centres of excellence and in tactical scenarios. It’s common for a large enterprise to use IPaaS, Enterprise Service Bus, API Management, Microservices and more traditional Extract, Transform and Load (ETL) solutions. For these organisations it is about selecting the right capability for the problem in hand. The same should be true for smaller organisations, however, the reality is that organisational scale and capability end up limiting choice. This is frequently why IPaaS is such a salient choice for these sorts of organisations.
Implementation Best Practices
Low/no-code solutions don’t remove the need for implementation best practices. Far from it. The strength of your documentation, requirements, standards and architecture are key enablers for this type of approach. The easier it is to deploy an outcome, the easier it becomes to deploy poor outcomes. Getting data models and solution architecture right up front is always important in the world of integration. Capturing business rules, mappings, systems of record and understanding the basis of change data capture is crucial to success in integration delivery.
It may be easy for a vendor support team to decipher how an integration process works within their technology stack. However, the business drivers for the way an integration process is delivered isn’t something that is clear from an IPaaS UI. This is where solid discipline in requirements gathering and documentation continue to be pivotal to the success of an implementation. It’s important to understand the value of any given integration process. It drives the development priority, service level and business case for its existence.
Solution value is an important aspect of how Chakray works with its customers to understand deployment needs. We help our customers achieve the right balance in architecture, documentation and delivery discipline.
How do technologies differ?
Technologies in the IPaaS market generally differ in terms of their coverage of IPaaS features, focus on connectors and target users. Some technologies are stronger in terms of deployment flexibility, API Management capability, developer experience, developer support, connector coverage and even ecosystems that they play strongly in. It would generally be unlikely that Mulesoft and Tray.io for example would compete for the same business in the market.
Buyers will also encounter varying degrees of maturity as well in terms of the overall SaaS offering, especially where vendors don’t have deployable agents or gateways. For some vendors the only option for the customer is for their data to be processed within the vendor’s cloud platform on infrastructure shared between customers. Rotating keys for your in flight data may be something you find exceedingly difficult to validate in practice.
Support for a given application or technology connector also doesn’t necessarily mean complete support. Often whilst a vendor may list a connector for a given SaaS application, they may only have partially implemented the API of that application. Likewise with respect to a technology connector. A buyer may find that a JMS connector for example doesn’t support the full JMS standard. IPaaS technology vendors tend to be driven by the needs of the business/customers they signed.
As with any selection of technology, buyers should take the time to validate the features that are important to them. Time invested in proving exercises to validate capability is time saved in deployment or redeployment of another technology further down the track. All integration technologies can generally be made to work for nearly all integration scenarios. Again, this is where valuing the solution and the data are important factors to consider. We can bend technology to fit almost any scenario. The questions should be: does the value stack up at the end? and Did we lean on the technology the right way?
Whilst many IPaaS vendors can tell a big data story it isn’t generally something we associate with it. There’s a tipping point on volume where we might consider event streaming as a more appropriate technology. Organisations with strict regulatory requirements around data processing and residency may have issues/challenges with IPaaS under some circumstances. Likewise with respect to organisations for whom API monetisation is a key part of their business. They may find API Management capability a little too rudimentary in some IPaaS platforms.
Low-code and easy deployment technologies bring compromises in order to deliver on the features they support. Coding visually tends to lock us into the platform we are using as does simplified deployment. The complexity in using a standards based ESB also affords a fair degree of portability across vendor technologies. It’s important for buyers to understand the compromises and whether or not the benefits associated with those are something the organisation can live with.
You May Be Interested In…
Further information and reading on subjects related to this page.