This solution's adaptability to our use case has helped us integrate our systems seamlessly.

Functionality-wise, the workflow has become more automated. When something is ordered within electronic medical records, it's easily available in the ancillary systems. When the results are in the ancillary systems, they can appear in electronic medical systems. It's one integrated system.

From a workflow perspective, it's very quick and efficient. Doctors and physicians can see their notes, documents, and all of the information they need. The interface engine sitting in the middle makes that possible.

Because we have been doing Red Hat Fuse projects for three years, and over time we have matured, we can employ similar use cases and make use of accelerators or templates. It gives us an edge when we deliver these services or APIs quickly. 

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.

Because it was relatively easy to get set up, it saved us a lot of time in building the solution. 

In terms of functionality, it's influencing a key piece of integration, one that actually allows our company to operate. It makes possible a core part of our business.

The integration layer handles all of the complexity, which results in faster implementations.

The solution has improved the way our company works on a variety of levels. 

The implementation of a ESB solution bring the opportunity of review the entire local integration strategy and start to rethink the company as a set of services.

I was asked to implement an application that was supposed to protect a lot of information in XML format. After I analyzed the business case, I proposed the VPN Red Hat Fuse as the solution to implement for the application. We also analyzed what was needed to use Java for implementation, but using Red Hat Fuse simplified the look of the application. It integrates very well with XML, with JSON, MongoDB, and relational databases. It was a perfect choice.