All about integration

So, as a company you want to structure your system integration. However, many organizations still work with a mix of on-premises systems and online applications. You may want to migrate one or more systems to the cloud first, before you start with data and system integration. Whether you are cloud ready depends on how flexible your applications are. The cloud offers the advantage that you can turn off systems and purchase additional computing or storage capacity when necessary. Applications that can handle this flexibly are more suitable for the cloud.
 

It is also advantageous for enterprise, data and system integration when you work with cloud agnostic applications. Cloud agnostic means that your application always works, regardless of the cloud platform. If that is not the case and you are bound to one cloud platform, we call that cloud native. If you are cloud agnostic, it is easier to use (open-source) data integration tools. Ultimately, integrating systems is always possible, regardless of whether they are in the cloud or not.

Then we have SOAP: a somewhat older protocol that has been used for communication between web services for a long time. Indeed, it is the predecessor of REST. Compared to SOAP, REST is simpler and more modern, which can create the need to migrate from SOAP to REST. A complete migration is quite complex, because SOAP is like an envelope with data, while REST is built from resources in collections. This means that the functional structure of your data changes when you completely switch from SOAP to REST. To solve this, an integration component is often chosen, on which both the SOAP and REST interfaces are available.

Finally, there is GraphQL: a query language in which you specifically indicate what information you want in the response. In contrast, REST is an architectural style that returns an overview of data, divided into objects. The difference is that REST retrieves much larger packets of information than is sometimes necessary, while GraphQL returns very specific responses. Which solution is better? That depends entirely on whether you need query functionality or work with an object model.

A 'one API fits all' does not exist

Unfortunately, there is no single REST API for all of your connections, because you build a REST API for a specific customer, i.e. for an application or end user. An API between applications works differently than an API between an application and end user. The difference is, for example, in caching and authorizations. It is therefore not unusual to have multiple APIs for an object model. Try to avoid developing a point-to-point API for each customer, otherwise you will quickly end up in a tangle of REST APIs. In addition, try to avoid these four pitfalls in system integration when you start working on application integration with REST APIs.

You can see an integration framework as a power strip to which you connect all your systems and applications via a plug. You can imagine that this offers a lot of flexibility. When you want to adjust or phase out a system, you simply pull the plug, without it having a major impact on the rest of your IT landscape. But also when you want to integrate a new application, you can easily connect it to the integration layer. An integration framework therefore offers a great deal of flexibility to quickly scale up and down. In addition, you benefit from multiple options multiple options, such as dealing with granularity, flexibility during upgrades, orchestration of requests orchestration of requests and mapping, for example, for converting languages.

What should you pay attention to when choosing an integration framework?

• Whether the functional layer is decoupled from the technical layer. This makes it easier to connect components to each other or to separate them.
• Whether it is an open-source framework. In that case, you have no vendor lock-in, no high license costs and no need for expensive Java programmers, which is the case with Closed Source.
• Whether you have to take out a mandatory subscription. With large parties such as TIBCO, MuleSoft or WSO2, this is often the case. This usually means that their open-source solution has limited functionalities and you will pay for the entire suite with additional solutions.
• Whether there is good support. It is annoying when you have to wait a long time for patches, feature requests and a solution to incidents.

A simple IT landscape with a core system and a few additional applications can be maintained easily enough. But as soon as it expands with multiple internal and external customers and the number of APIs increases, maintenance and management of system integrations becomes a daily task. When you then work in a glass box, including a transparent management environment, it helps to protect your organization against data loss.

Transparency is key for an administrator. An IT landscape that is in a black box is much more difficult to manage due to the lack of insight. In the event of similar incidents in different applications, you have to reinvent the wheel again and again. By adding an integration layer, you standardize a number of things, such as writing to a queue, reading it and calls from web services. You transform into a glass-box environment, as it were, which suddenly makes it measurable how your application chain is running and what potential bottlenecks are.

As an administrator, you want insight – insight into the connections that exist, and insight when something goes wrong. An integration framework such as the Frank!Framework has an extensive management environment. This dashboard not only helps to trace unprocessed data, but also facilitates the administrator in many other ways.

Of course, you want to be able to monitor whether all processes are running correctly. This requires an overview of all connections within the integration framework, because then you can check exactly whether a message has been delivered correctly or processed correctly. Analyzing message flows is also part of a good management environment.

In addition to the fact that it is interesting to know that there is an exchange of data between two applications, you also want to see how much data is exchanged, how large those messages are and how long they take to go through your entire application chain. Is something going wrong? Then error logs indicate what went wrong, so that you can resend messages. A proper management environment allows you to solve 99% of problems yourself, without the need for a programmer.

The Frank!Framework is an open-source integration framework and it is the basis for the integration of business systems and applications. Simply put, the Frank!Framework makes it easier for organizations to integrate all kinds of systems with each other, in order to expand and simplify work. In this blog you can read the 5 ways in which the Frank!Framework makes it easier for insurers.

The Frank!Framework is open-source, and anyone can use it. If you ever need specialist knowledge, we are here for you.

You can purchase support from us for any conceivable issue, without having to have a number of licenses. Of course, you are not obliged to purchase support. As mentioned, you can solve 99% problems yourself using the extensive management environment of the Frank!Framework. Would you still like to use a support contract? We would be happy to discuss it with you. You determine the term yourself.

Learn more about Frank as a Service

Proof of Concept 

Of course, we are quite convinced of the power of our integration framework. A Proof of Concept (PoC), however, is an accessible way to discover whether the Frank!Framework is an answer to your problems and meets your needs. Whether it concerns linking two APIs or solving a particularly annoying file, we are happy to get started with it. Though it is often thought that a PoC is expensive, with the Frank!Framework a Proof of Concept is quite affordable and it allows you to discover the possibilities. You can therefore benefit from our integration knowledge without being tied to anything right away.