The value of a UI for middleware

Larger companies often want (or need) to connect different systems. Sometimes all the systems stay in use, and sometimes the aim is to migrate from one system to another. Middleware can be used to achieve this. Even better is to add an interface, so that stakeholders (such as software administrators and data managers) can monitor the flow of data and intervene where necessary. In this blog, we explain why it's a good idea to add an interface to it with Mendix.

Middleware: what problem does it solve?

As the name suggests, middleware is software that sits between different systems. It is mostly used to link data from different sources and make it available to the end user's system. This process often runs in the background, and the end user has little to no influence on it while it's running. There are, however, plenty of situations in which the end user wants to monitor the process so they can respond in time if something threatens to go wrong, for example when the user wants to safeguard data quality, or when a data conversion is involved that requires checking (and possibly even manual editing).

How does a UI solve this problem?

By adding a user interface (UI) to the whole, the end user gets influence. Of course, it's ideal if as much as possible (preferably everything) is automated, but monitoring the process gives the end user the chance to fix the problem before it gets out of hand (i.e. they can respond in time if something threatens to go wrong).

Mendix is a very suitable tool for building this UI exactly the way you need it. During development, the end user can be closely involved in the process, so that exactly what they want to see is shown on their screen. After all, the end user is the specialist when it comes to the systems that will be connected. Another reason Mendix is so suitable is that, especially compared to traditional development, it allows for rapid development. This lets you pay more attention to the ultimate goal of the systems being connected, rather than to how the connection will be made.

In addition, middleware built with Mendix can easily be deployed to one of the well-secured Mendix cloud environments. This means the capacity and storage the middleware needs is no concern for whoever is connecting the systems. That leaves more room (mentally and technically) to focus on the end result: an architecture of different pieces of software and data, interwoven in an elegant way.

A practical example

I can imagine that, as a reader, you may not be able to see the forest for the trees after the story above. An example might make it clearer. For this practical example, I'd like to draw on my own experience.

The Dutch branch of an insurer was told by its parent company that the current system had to be migrated to different software (preferably immediately), and the existing software contained seas of data, some of it incorrect. To make the migration a success, the incorrect data also had to be filtered out of the system right away, so it wouldn't cause problems later. As is often the case, the information was also supplied by external parties. This caused a number of problems, mainly these two: the data was not always delivered in the same way (data from 2017 contained slightly different information than data from 2018), and the various external parties also delivered their information in different ways.

This is exactly why it's useful to have insight into the data flow. What if all the data were simply transferred to the new software? Then the problems from the old system would be transferred as well, and we would have gained nothing. A typical case of garbage in, garbage out. It is therefore essential that all information arrives from the middleware in the new system in a uniform way. To achieve this, the user needs to be able to look along in the software, to see (and influence) the various data transformations.

The application developed for this is the central point for the various sources of information. All the data ends up in it, is edited and reviewed where necessary, and is then exported to the new system in the right way. This makes it possible to check that the data entered into the new system is error-free and in the right format.