Common iPaaS Challenges
How helpful can an iPaaS solution be when difficulties happen?
iPaaS is known for offering no-code integration solutions anyone can use. However, not everything is as easy as it sounds. Setting up the right iPaaS solution for your business doesn't always come without challenges.
This article is brought to you with the help of our supporter, Software AG.
Software AG lets you create incredibly connected experiences for your customers, employees, and partners with an AI-enabled enterprise iPaaS.
I've worked with integrations for many years. From my experience, the biggest challenge is related to how complex an integration can be. Cases where different systems use different data formats and protocols can create very problematic integration experiences.
I clearly remember working on an integration for a customer who wanted to make two systems talk to each other. One system was using SOAP and the other one was an OData API. While each of the systems wasn't complex on its own, combining information from both systems was a highly complex and error-prone activity.
The difficulty is not so much in communicating with each API. The big hurdle is related to translating operations and data models between systems. When you have information from one system that you need to write into another system, there can't be any mistakes in the process. Otherwise, you end up losing information or, even worse, generating erroneous data.
That's why being able to customize an iPaaS solution to your specific needs is critical. Customization means different things. Being able to manipulate the data you receive from a system is one form of customization. It lets you prepare the information before you send it to a receiving system.
Another customization happens with errors. While some APIs return errors in a standardized way, others don't. You want to be able to configure the iPaaS to interpret errors whenever they happen. RESTful APIs, in particular, are known for using diverse error representations. Depending on the implementation you might find errors following the standard HTTP codes or errors might be encapsulated inside a response that would otherwise look successful.
The lack of flexibility an iPaaS solution offers can also be challenging. In a situation like the one above you want to be able to customize how the iPaaS interprets errors. However, APIs change all the time, and what is considered an error today might be something else tomorrow. You want the iPaaS solution to be flexible enough to let you adapt the integration to incoming changes.
Solutions that offer the best adaptability are the most flexible ones. Those solutions usually let you test your integration with each different API so you know whenever something changes. Then, you can change the way the iPaaS connects to the external system so it doesn't break the integration.
While a breaking change in one of the APIs is a sure way to stop an integration from working, there's another less visible challenge that iPaaS solutions need to address. I'm talking about scalability. Being able to scale automatically to handle a growing number of requests is mandatory. However, the iPaaS system needs to scale smartly and adapt the load to each one of the participating APIs.
Scalable iPaaS solutions need to offer a way to accept an increasing amount of requests from one side of the integration while queueing the load to APIs that don't support so much demand. Otherwise, you might overload some of the APIs and even get to a point where your requests are throttled and your integration stops working.
The ability to queue and prioritize requests is critical to achieve a scalable integration. Queueing is also important because it allows an iPaaS to handle retries gracefully. If one or more APIs are not responding, the system should be able to pause those outbound requests to avoid an avalanche of failures. When those APIs are again working properly you can't just push all requests at once. Instead, a proper iPaaS solution should be able to generate a ramp-up of the load.
If managing the amount of incoming and outgoing requests feels important for Web APIs, imagine the scenario with internal legacy systems. These are systems often left unsupported for years, using outdated software and hardware, with little or no documentation at all. Most of the time you understand how these systems work by trial and error, so it's not easy to manage situations where things fail.
The ability to interact with an "experimental" layer that connects to legacy systems is fundamental. You should be able to write glue code that handles the direct communication with the legacy system and translates it into what the iPaaS solution understands. You should be able to run and test this translation layer locally before connecting it to the iPaaS system.
All these features—especially the ones that require queueing—come at a cost. Understanding the incurring costs of an integration is also one challenge that often arrives unannounced. If you're not able to monitor the ongoing costs of the integrations you're building you might end up in a situation where you won't be able to pay. A good iPaaS solution should give you visibility into how much each feature you're using costs and show you how your real-time usage is affecting your next bill.
Overall, most of the challenges you'll face when building integrations on top of an iPaaS are related to the complexity of the involved APIs, the difficulty of customizing inputs and outputs, the work needed to handle breaking changes, the lack of queueing mechanisms that prevent throttling, the pain in connecting to legacy systems, and the obscurity of ongoing costs.
By evaluating how different iPaaS solutions address these challenges you'll be able to make an informed decision of what direction to take.