WSO2 Enterprise Integrator alternatives and competitors

Our primary use case of BusinessWorks is integration, to ensure that our various systems are communicating and integrated. Instead of doing point-to-point integration, we implemented this solution to ensure that system A can talk to system B via BusinessWorks. 

We started with on-premise, but have migrated to the cloud version, so we're using the latest update of BusinessWorks. We have a hybrid deployment—some services still run on-premise, but the latest services are running on our private cloud. We have a Kubernetes cluster set up within our VMs. 

One of the most valuable features is data transformation. We have some legacy systems which are in old technology, like SOAP, whereas the new ones are in REST. So we use BusinessWorks to transform data from one format to another, from SOAP to REST. BusinessWorks has many useful features. Every product we have is being used on a day-to-day basis. Some might have been retired, but we're at least using most of the basic BusinessWorks products. 

This solution's cloud could be improved. I don't know whether it was because we didn't have the internal expertise or if it was the product itself, but since they came later—I think only two or three years into the cloud—after many other iPaaS that had been in the cloud for longer, I feel that maybe they haven't matured in terms of the cloud. Even building cloud images is relatively huge compared to other iPaaS services, but I know it's something that is in progress since there are releases almost every day. 

For the on-premise deployment, the memory could be improved. It consumes a lot of memory, so we have to ask our infrastructure team to increase the memory every day. With BusinessWorks, the application or payload can be small, but it still uses a lot of memory. Memory utilization is my biggest worry, so maybe they can optimize on that. 

In the next update, I would like to see support around IoT, internet of things, because we are moving toward that now. We are going to have so many devices that need to connect and communicate. Also, maybe they can gather information and improve their monitoring. They have TIBCO Hawk, but it's not as powerful as other monitoring tools that we have, so we use third-party monitoring applications.

I have been using BusinessWorks for around five years now. 

This solution is stable. I don't have any other iPaaS to compare it to, but it performs well. I haven't had any issues with development.  

As far as maintenance, it's mostly just HotFix updates they share, maybe to fix a bug or maybe they don't support the latest security protocol, what we call SSL, so they have to fix it. I think they're trying to catch up with other technologies—for example, maybe you upgraded your security level or have secure applications—so they do their hot fixes just to catch up. I'm in development, but the operations team is the one who raises tickets to Safaricom and interacts with TIBCO on a day-to-day basis. They identify bugs and if there's something that needs to be fixed, they fix it on UAT and production. 

I'm not sure about scalability. When we test, it's only one or two users who are testing because we don't have the live traffic. Even if we're doing a load test, we don't do load tests on UAT, we do our load test on production. I have to confirm with our operations team because, as a developer, I'm focused more on the functional and maybe load testing. I've never had an issue with load testing, at least. 

Our DevOps team has around 35 people. 

There's a case that I raised some time back and it took almost two weeks, with them telling me they took it to the engineering team, the engineering team took it back to L2, and I felt like I was being bounced around. There are various product portfolios, so from L2, they take you from portfolio A to portfolio B, portfolio B will take you to the engineering team, the engineering team will just come back to you and tell you it's not a product issue. I don't feel that they're completely competent when it comes to just answering you and providing support. 

The initial setup was simple because it's what we call low-code/no-code. I think that as long as you come from a programming background, it's easy to understand and you can easily implement TIBCO BusinessWorks. It's more of a drag-and-drop, and then it generates codes in the background. I'll give credit to TIBCO at least on that front. It's easy for guys to come in and, within a month, they can start implementing without having prior knowledge of TIBCO. So it's easy to learn and start implementation. 

When I joined my company, I had a team that was already competent in TIBCO, in terms of development and support, so it was easy to be trained. Initially, I think they were using one of the system integrators to support them, but by the time I joined, we had enough competency within the team to support and develop it. 

We implemented through an in-house team. 

I think BusinessWorks is more expensive compared to other products. We have the ELA, so at least we have some sort of bargain or discount with that. But for a start-up, it's very expensive compared to other ESBs. 

This solution is more suited for large enterprises. For someone who's just starting up without enough CapEx or OpEx, it's going to be a bit expensive. 

We have another ESB, which is called WSO2, that I would recommend because it's very strong. The only factor I would maybe recommend TIBCO on, over WSO2, is the pricing.

I don't think I would recommend this solution to others. We have another ESB, which is called WSO2—I would rather recommend this one, since it was very strong. With TIBCO, they don't even have some kind of open source where you can just download and practice, so you have to procure the license in order to get the software. Other ESBs will at least give you the ID so you can do everything, but you have to pay and be locked in before you can start using TIBCO. Maybe it's number two or three, but it's not my top ESB. 

I rate TIBCO BusinessWorks a seven out of ten because it works. We have over 200 applications running on TIBCO, so I'll give it a seven. 

We primarily use the solution for integrations of traffic between internal applications, communications, and transactions between various internal applications. We also use it for integration with various external parties.

Before we implemented IBM to integrate with other external parties, we had buckets of applications to build, and maintenance was difficult, as was support. On top of that, integration wasn't well controlled and managed. Right now, post-implementation of IBM ESB, we have a better structure. We have better teams in development and response to customers. We have an application that is centrally managed and monitored. We have better SOA experience in our development process.

The feature we find most useful is the ease of development.

It provides a variable within our application it can easily be used across various applications. 

ESQ is very robust and easy to learn. That's the language the solution is based on. 

The solution can scale.

The stability is mostly pretty good.

There are experiences we have on the application, such as latency issues. There are no inherent components for you to throttle and measure the velocity of transactions. For that, you have to get a separate application and set up more robust rules. Then, you can handle API throttling and a number of business logic and rules. You need to implement DataPower, in order to have this. It should have been integrated into a single application rather than having to deal with various applications and components. It would be nice if everything could be packaged under one solution.

Today, the IBM business rule engine, the DataPower is outside the Enterprise Service Bus. It's sold as a different feature or application. If it could be integrated, then it's able to handle a lot more of what we are doing now rather than just have a stateless ESB that you can't do much on, and a set of normal business rules.

If you have the business rule engine that can help us measure velocity, throttle, monetization, et cetera, within the ESB, it would be better than it is now. There won't be any need for one to start looking out for any possible change in the near future.

The initial setup is a bit complex. 

This is a very expensive product.

We've been using the solution for more than five years at this point. 

There is some latency and slowness in the application. At times, we have to restart the server, and there are some errors we can't handle. We send those to IBM. It's relatively stable, however, periodically, we have problems, which is why we have to get IBM to help us resolve them. That said, I would describe the product as stable.

In terms of extensibility to other applications after development, it's highly extensible. The solution can scale. 

We have developers, who develop various integration requirements, and we have support. Outside that, we don't have physical users using it. There are about 10 developers in all, that handle various requirements that come along. The support unit is about five people and they are handling the support.

We don't deal with IBM directly. There's a local partner of IBM that assists us. We only have a direct relationship with IBM, when the local partner cannot handle a problem. Our contract is designed with IBM in such a way that we have to go through their local partner. In terms of responsiveness, the local partner is good. I wouldn't say excellent, however, they are good in response time. In terms of timeline for issue resolution, TAT for issue resolution, they are fair.

Before we went to IBM, we didn't use a different solution, however, we checked in our industry and we checked how people felt about Microsoft middleware, and they didn't have a good experience. It's not robust, the support wasn't strong, et cetera. Therefore, we chose IBM. We were swayed by how other organizations, including banks in Nigeria, were mostly seeing success with IBM.

We are using WSO2 for some applications, however, we do not rely on it completely as it is open-source and if we run into issues we cannot rely on help from any support.

Setting up the solution is not straightforward. It's difficult and complex. We needed assistance in order to manage the process properly. It's not something you can just pick up, and then, run on your own. You need help from a partner, which involves additional costs.

We didn't do it alone. We worked with IBM, and then, IBM nominated a local partner in Nigeria that worked with us to set this up.

The solution is very expensive. 

We looked at another solution called WSO2. It is a lot easier to set up. It's easier to use, and it's less expensive. However, the challenge we have with that, is that the support is lacking as it is an open-source application. The support is not so strong. That's the only reservation we had for that. Outside that, we are also using it for some other applications as well.

The prominent other contenders were WebLogic from Oracle, and whatever was provided by Microsoft. Among the three then, IBM came out on top in our assessment and rating. However, with the benefit of the insights we now have, if we were to do the same process again, over five years, WSO2 has done so well, and some other middleware is also doing well. Likely we would not choose IBM if we had to choose again.

We are customers and end-users.

I'd rate the solution around a seven out of ten.

I would advise companies to evaluate and consider the options and whether they make sense vis-a-vis the benefit they hope to derive is worth the while. IBM is not cheap. They need to consider costs and make sure they have internal resources available to them. Those using the solution need to be well trained. Otherwise, the company will end up depending on third parties for everything, and that will drive up the costs further. 

I'd also suggest companies implement such a solution early. Load balancing is very critical in our experience. We didn't implement load balancing immediately, and that affected us. As a company is implementing, it should consider load balancing. Rather than invest on the on-prem, a company should consider the cloud. We did on IBM Unix servers on-prem, and that's pretty expensive.

We provide contracted services for our customers that include coordinating with providers and implementing the solution. 

A current project includes using the solution to deploy 200 microservices. 

The process-oriented solution allows you to define choreography and orchestration. This feature makes it stand out against competitors such as WSO2.

The solution is contract-based which allows for the selection of services and implementation options based on the customer's needs. 

Cloud deployment is weak and needs to be improved. 

I have been using the solution for ten years. 

The solution is stable. 

It is easier to scale with the solution's enterprise version but it can be done with the community edition. 

We were successful in processing five million messages per day and duplicating instances easily with the enterprise version. 

Technical support is good but I have complained about documentation that is abundant yet not well organized due to product acquisition. 

I sometimes seek documents via the support community because I am able to get them quicker than through technical support. 

The initial installation is straightforward and only requires unzipping a file. 

I rate setup a nine out of ten. 

We implement the solution for our customers.

One of our clients is a signature company and developed on a classic Java enterprise application using OpenESB. In one year they saved £20,000,000 on development and maintenance. 

In comparison to other tools such as Oracle, the price is good for the service we receive.

The cost for the prediction instrument is high because it is charged per instances based on prediction, but the rest of the solution is free. For example, if you pay for two instances on prediction, then you have the right to use two instances on the document, test, or QA. 

Developer's licenses are under a separate payment plan. 

I rate the solution an eight out of ten.