"Self-integrating applications"... Does not it sounds cool? Applications that automatically integrate your business system landscape with just permission to connect. Is this already a reality? The answer is simple: No.
So why do Gartner and other analysts then speak about it? The answer is that we are only heading towards this goal. It's not just applications that provide better interconnectivity via APIs but iPaaS platforms that bring in something called augmented integration, thus making integration faster, easier, and more cost-effective. A glue that the applications connect to or that connects the applications. That is called an integration platform or an integration Platform-as-a-Service (iPaaS). The integration capabilities of iPaaS platforms are evolving to be faster and more automated.
As the amount of best-of-breed applications grows in the companies, so do the amount and complexity of the integrations between them and business partners. To tackle the ever-growing number of integrations and the growing cost of operating them, iPaaS vendors have taken several different approaches by automating and augmenting integration development.
What does this augmented integration mean? There are several currently evolving areas within the iPaaS products like:
- Augmented data mapping and process automation
- Augmented discovery and publications of APIs
- Automated Dev(Sec)Ops
As the word "augmented" or "automated" may mean many things in this context, let's look at these concepts.
Augmented data mapping and process automation
Augmentation means that we are helping or automatically doing manual things. Yet the whole function is not fully automated; the integration developer or business IT still needs to control and check results. In data mapping, there are several approaches to augmentation. Some iPaaS use Machine Learning augmented data-mapping. They have taught ML engines to map the common cases of data mapping between systems even when the source and destination are not "known ."For example, when the integrator maps data, they show the iPaaS that this is the data object called "Customer" in our CRM interface. Then the integrator indicates that this is the destination object "Customer" in our ERP. When both ends are locked, the iPaaS automatically tries to map the fields like customer names, addresses, and more. As this sounds cool and uses fancy AI, the problem is that it is usually not accurate enough. Even if the accuracy is 95%, integrators must go through every field and ensure that the fields are mapped correctly.
Another way of doing augmented data mapping is with template maps between source and destination. Our experience shows that templates are, in the end, as fast as AI-based data mappings due to a simple reason: you still have to check the format and correlation of fields between systems. An almost endless list of tiny things forces the mapping to be checked carefully - that is nearly as laborious as doing it manually as modern iPaaS platforms are efficient with their low-code and copy-paste data mapping.
Like Frends iPaaS that I represent, modern integration platforms don't do mere data mapping but process automation. There are often ready-made industry-specific process templates instead of data-mapping templates. Another name for these that Gartner uses is Prepackaged Integration Processes, PIPs. PIPs include automation of a whole process, including matching systems like in the screen capture from Frends below. It is a PIP integrating energy sector systems (several real screen captures).
Augmented discovery and publication of APIs
In the near future, when a developer creates an integration process or front-end developer an app, the development environment may magically show all the choices of own and public data during development. Future development environments are aware of the data and business functions internal and external APIs may offer. Developers just choose from the desired data source and ensure that the provided data is precisely the process needs.
The AI inside the developer tool may be context-sensitive and, based on metadata and user actions, what "temperature" they are looking for.
The ingredients of Augmented iPaaS
When the developer is publishing data or a business functionality via API, the development progress is more and more low-code. The idea is not that development is faster with low-code as a pro developer writes code as fast as a visual low-code developer can drag and drop items. The benefit of low-code is that other people can see what your "code" is doing just out of the box. So if someone needs to make a change to the process or the operators need an answer to the question, "what went wrong in process execution at 21:02 for this peer" the answer is easy to find from the visual process execution instance.
There are many different approaches to iPaaS low-code; for example, Frends uses standard BPMN2.0 notation included in Microsoft Visio and other modeling tools. Unfortunately, many iPaaS vendors have chosen a closed approach to low-code. If you need to extend or expand your low-code toolbox, you can't, or it is incredibly tedious, and again the development is slow and expensive. With Frends, we have open-sourced the task libraries, which means you can access all the ready-made tasks and building blocks from GitHub. You can also see the source code if you want or create your Frends Tasks (building blocks) based on existing ones.
The key to efficient development is built-in DevOps tools and support for your CI\CD pipeline. So when choosing an iPaaS, make sure the platform supports things like:
- Automated tests that are executed during deployment of an API or process automation
- Automatic versioning and support for version controls
- Ability to visually point out differences in different API versions or low-code process automation.
- Comprehensive and pervasive stack of API and automation technologies
One of the reasons that destroy the efficiency of integration development is the stack approach. Your programming capable developers love to develop everything on top of different AWS and Azure services. They will try to convince you that "this is the way ."The benefit of that high-code approach is the artisan work that developers can do. More fun: developers are happy to learn the multitude of technologies these cloud stacks require. Sometimes you even need several people to implement simple APIs or integrations. See the sarcasm here? So instead of a pile of separate integration technologies, check that your iPaaS has built-in easy to use:
- API creating and hosting
- API management
- API gateway
- Business Process Automation capabilities, including the ability to execute RPA recordings
- Branch processes based on AI-based decision making
- Standard low-code language instead of proprietary
PiPs are already here, but augmented discovery is yet to come in coming years.
Cost of Operations
One thing is commonly forgotten when looking for innovative ways of developing integrations: the Total Cost of Ownership (TCO). In the era of low-code iPaaS platforms, integration and automation development are no longer the expensive part for most companies. Instead, it's the operations of those integrations. For example, now and then, the source system sends data that is not expected, and the destination system is not answering. Even though these repeating exceptions are automatically handled, there are lots of things that can go wrong. Therefore, monitorability and ease of use are even more essential features of the modern iPaaS than the augmented development.
Developing with Frends is Agile and standard low-code. Operations are where Frends goes from low-code to low-cost. To summarise, the elusive self-integrating application does not yet exist. Still, with automated service discovery and meta-data-based AI-enhanced data mapping, we may someday need only to onboard and check new applications to iPaaS. Meanwhile, ensure that your iPaaS is agile, easy to learn, and easy to upkeep.
