Business systems are becoming more specific and

Support for Various Integration Standards

JSON REST APIs are becoming standard, but there are plenty of other standards still in use. It should be easy to interact with most if not all of these different file formats and protocols. The most critical ones I have encountered are JSON, XML, SOAP, REST and FTP.

Powerful Data Transformation

The other core function of an integration platform is data transformation. Any integration platform needs to enable fast, easy transformation of data.

Error Logging

This is imperative for all software, but errors should be caught and logged, so they can be investigated and remediated. Without an error log this is not possible.

Error Monitoring and Notifications

At any given time you should be able to see the status of your integrations. You should also be able to configure notifications to send if errors are exceeding your expectations, so you can limit the impact of the issue.

Error Retrying

When integrating numerous systems there are times where these systems run into temporary errors, or your integrations have bugs. After these issues are resolved some logged errors may need to be retried to get your systems back in sync.

Scheduling

Frequently integrations need to retrieve and then sync data on a schedule, either to minimize load and API calls, or because the source system is not capable of pushing data.

Easy Endpoint Creation

Webhooks are a common way to receive data from external platforms and enable the creation of real time integrations. Different systems support different authentication, so this ingress should be relatively simple and then you should have the ability to write the validation and authentication you want.

Message Queue

Message queues are the easiest way to send the same data to multiple places. It requires the least external development, increases flexibility and offers the most stability.

With message queues the source system only has to send the data to one place and it can be passed from there to multiple targets, all within the integration platform. This means that, at most, integration developers will have to rely on someone sending the data to their message queue, but can handle everything from that point on.

Adding targets for the data is easier because you just have to create a new subscriber. If one of the target systems is being replaced, for example, you only need to write the code from the message queue to that target system and turn off the old integration. Neither the code syncing data to other target systems, nor the code syncing the data to the message queue need to be modified. This makes it easier to keep up with a changing systems landscape.

Having multiple, independent processes syncing data from this messaging queue to different target systems means that errors, or delays in one sync will not impact other syncs of the same data. Additionally if there is an issue with one sync the sync can be paused until the issue is fixed and it will pick back up from where it left off in the message queue when it is turned back on. This way the other integrations remain live and you do not have to figure out how to reprocess all of the data that was sent while the integration was down.

Testing

Automation passing large amounts of data between different, complex systems is error prone. It is important to be able to test not only the integrations code to ensure it works as expected, but ideally provide a way to perform end to end tests with source and target systems.

Visibility

It can be hard for integrations developers, much less stakeholders, to keep track of all of the data flows, not to mention the details of each of these data flows. To avoid having to spend lots of time troubleshooting and clarifying scenarios it is important that the platform provides visibility into the integrations, in a format stakeholders can consume, without requiring the independent creation and maintenance of documentation that will become outdated.