4 min read
The value of a UI for middleware
It often happens that larger companies want (or need) to create a connection between different systems. Sometimes this is a situation where the different systems all remain in use, and sometimes it's to migrate from one system to another. Middleware can be used to accomplish this. It's even better if an interface is also built for it, so that stakeholders (including software administrators, data managers) can monitor the flow of data and influence it where necessary. In this blog we explain why it's a good idea to add an interface to this with Mendix.
Middleware, what does it solve?
Middleware is, as the name suggests, software that sits between different systems. It is mostly used to connect data from various sources and make it accessible to the end user's system. This process often happens in the background, and the end user has little to no influence over it while it's running. However, there are plenty of situations imaginable where the end user wants to monitor the process, so that a timely response is possible if something threatens to go wrong, for example when the user wants to safeguard data quality or when conversion applies to the data, requiring a check (and possibly even manual processing).
How does a UI solve this problem?
By adding a User Interface (UI) to the whole, the end user gains influence. Of course it's ideal if as much as possible (preferably everything) runs automated, but monitoring the process gives the end user the opportunity to plug the leak before the damage is done (i.e. a timely response is possible if something threatens to go wrong).
Mendix is a very suitable tool for creating this UI entirely according to needs. 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. What also makes Mendix so suitable as a tool is that — especially compared to traditional development — it can be developed quickly. This allows more attention to be paid to the ultimate goal of the systems to be connected, instead of how the connection will be made.
In addition, the middleware developed with Mendix is easy to deploy on one of the well-secured Mendix cloud environments. This means that the capacity and storage space the middleware will need is not a concern for whoever wants to connect the systems. That provides more room (mentally and technically) to focus on the end result: an architecture of different pieces of software and data, elegantly interwoven.
A practical example
I can imagine that as a reader you can no longer see the forest for the trees after the story above. An example might make the whole thing clearer. For this practical example, I'll gladly draw on my own experience.
The Dutch branch of an insurer received word from its parent company that (preferably immediately) the current system needed to be migrated to different software, with the current software containing vast amounts of — sometimes incorrect — data. To make the migration successful, it was also necessary to filter the incorrect data out of the system right away, so that it wouldn't cause problems later. The supply of information — as is often the case — also came from external parties. This caused a number of problems, mainly these two: the data wasn't 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 as is? Then problems that existed in the old system would also be carried over, and we wouldn't have gained anything. A typical case of trash in, trash out. So it's essential that all information ends up in the new system from the middleware in a unified way. To achieve this unified way, it's necessary for the user to be able to look into the software, to see (and influence) the various data transformations.
The application developed for this is the central point for various sources of information. All data ends up there, is processed and reviewed where necessary, and is then correctly exported to the new system. This way it can be verified that the data entered into the new system is error-free and in the correct format.
Curious about the possibilities? Schedule a no-obligation (online) demo
This blog was written by Steve Jonk
Mendix Developer at E-mergo