We have Fuse installed on our on-premises servers, and we use it as an enterprise service bus for connecting different applications. For the time being, all of these applications are installed on-premises.
We also use cloud-based applications, but none of them is currently interacting with Fuse.
We try to implement third-party applications, if possible, out of the box and, if not, with minimum customization. That leaves something which is very important outside. The applications in many cases have to talk between each other and this is why we need integrations.
So, we chose Fuse to act as a membrane or glue for all of our applications to be able to interact. For that particular purpose, we hire third-party development companies that create the integrations for us, but we chose Fuse as this membrane that glues everything together because that was, when we first evaluated it, the best approach that we could select at that point in time.
The comprehensiveness of Fuse's API management is quite good, and this is important to us. From a usability standpoint, particularly for the developers that have to interact with the API, it's fairly straightforward. We don't have in-house developers. We always make use of third-party companies to develop integrations for us. We don't interact directly with the APIs. Rather, it's third-party development companies that we hire to create integrations for us.
Having said that, most of the companies that do such integration development for us, maybe half of them have experience with Fuse, and the other half who don't have experience can handle the APIs pretty well once they are exposed to them and someone explains to them how they work. These third-party companies have been working for us for maybe two or three years and have no problem at all with the APIs.
With respect to reducing our developer's dependency for integration and custom code, our situation is mixed. We rely on developers to create integrations so it has not changed in that regard. However, if we compare it to a non-enterprise service bus integration scheme then there is less dependency on developers.
At the end of the day, we rely on external developers for creating integrations and maintaining them because, of course, maintenance occurs. Businesses have changing requirements so we have to adapt those integrations. In the comparison with a non-enterprise bus scenario, we have less dependency because the alternative use case is to make these applications talk between themselves instead of to a third party that stands in the middle, such as an ESB. This approach is typically more expensive. It takes a lot of time and it requires, which is most important, that developers who know both applications talk between themselves, maybe from different companies.
In our case, when we have the situation where Application A has to maintain a dialogue with Application B through the ESB, it may have different sets of developers. One for, let's say, Company Alpha doing the maintenance for Application A and Company Beta doing maintenance on Application B. They all have to talk to the API. The two companies don't need to talk among themselves, and that is something that reduces the dependency.
There's another use case as well. Let's suppose we have these Application A and B, and we replace B with another application called C. When this happens, we don't need to rewrite the whole integration. We only need to rewrite the integration between the ESB and Application C. So, there are some advantages down the road and overall, the dependence on developers slightly diminishes.
There are a couple of examples where using Fuse has benefited us. We have three applications that are running on top of Fuse.
With Fuse, we have been able to create a bidirectional integration between two applications in order to diminish the need for end-users to input or key in the same data into two different applications. This is what was happening before we suggested implementing a solution based on Fuse.
The benefits were immediate in the sense that there were almost zero errors because, of course, when you key in data in two different systems, chances are that you can make an error maybe in one system, maybe in the other system, maybe in both systems at the same time. When you are copying data or extracting data to Excel spreadsheets and then trying to import them into the next system, that is cumbersome. It takes a lot of time. It's manual work that can be completely avoided and the possibility of inserting errors is fairly high. So, on the data quality aspect of the equation, it has improved a lot and that was a benefit for the end-users. In our case, if we can avoid doing manual tasks, that is highly desirable.
We have also another case where we implemented a workflow that interacts with a repository management solution. This workflow was developed from scratch because one of the companies had a solution that was written for them because there is no package in the market for their particular business.
The industry comprises a very small number of companies in the world so there are no general solutions. We have to write them from scratch. But at the same time, we already possessed a corporate document repository where all copies of invoices, purchase orders, receipts, and other documentation have to be stored for disaster recovery purposes. Ideally, what we needed to do was have these two applications interact, which is exactly what we did by employing Fuse.
We have other use cases, for example, integration between an ERP and the corporate repository. For all of these integrations, instead of being point-to-point, we are using Fuse. This means that the maintenance of those applications was reduced. In fact, next year we are planning to change our ERP solution for several group companies. All of the documentation that is generated, for example, invoices to our customers, will be created by another ERP. We will only have to rewrite the communication between the new ERP and Fuse. This will result in less time to market and that all equates to savings.
We have other similar use cases but essentially, they all involve making two different applications talk between themselves or making a certain application store things in our corporate repository.