| Type | Title | Date | |
|---|---|---|---|
| Category | Data Integration | Jun 1, 2025 | Download |
| Product | Reviews, tips, and advice from real users | Jun 1, 2025 | Download |
| Comparison | TIBCO BusinessWorks vs Azure Data Factory | Jun 1, 2025 | Download |
| Comparison | TIBCO BusinessWorks vs Informatica Intelligent Data Management Cloud (IDMC) | Jun 1, 2025 | Download |
| Comparison | TIBCO BusinessWorks vs SSIS | Jun 1, 2025 | Download |
| Title | Rating | Mindshare | Recommending | |
|---|---|---|---|---|
| Informatica Intelligent Data Management Cloud (IDMC) | 4.0 | 4.3% | 93% | 185 interviewsAdd to research |
| Azure Data Factory | 4.0 | 8.4% | 92% | 91 interviewsAdd to research |
We currently have 500 or more than 1,000 applications of TIBCO BusinessWorks. Our primary use case for the solution is the apps leader operations batch. We have users all across the globe. We have business in Japan, Amsterdam, the US, and Korea, among other countries. Whenever we need to perform region-specific activities when a region is not there – like region-related calculations, for example, we use TIBCO BusinessWorks. Even if a region is around, there will be some midday activities that we need data from different systems. All the backend-related logic and business rules are there in TIBCO BusinessWorks.
Good TIBCO BusinessWorks features are the admin console and the ability to roll back to the previous version.
The biggest problem with TIBCO BusinessWorks is the licensing costs. It's too expensive. We are planning to migrate from TIBCO BusinessWorks to Camel. On the enterprise side, we will use Kafka and Pulsar.
It's not just the license that is expensive with TIBCO BusinessWorks. Scaling with the solution is costly because if we need to scale up, we have to buy more memory. That means more money. Solutions like Camel or Pulsar come with built-in options to scale horizontally, vertically, region-wide or country-wide.
There are many other issues with TIBCO BusinessWorks, actually. For example, TIBCO BusinessWorks files can only be opened if you have TIBCO Designer. This is again more cost on top of what I mentioned above. Compiling or opening a file should not be an additional cost. If a person does not have TIBCO Designer on their machine and they receive a TIBCO BusinessWorks file, they will not be able to understand the logic or go through the source code. That's the biggest limitation.
TIBCO BusinessWorks mentioned that we can directly inject or connect with Java, but that's not easy. I would say it has many limitations. They will expect us to follow their protocol in injecting Java or any third-party library.
In addition, when we deploy, you have to add a class part. It would be better if we were expected to add a class part only in some cases. This is not user-friendly.
Overall, TIBCO BusinessWorks has not evolved properly over time. So, right now, if you compare it to other solutions that have evolved drastically, TIBCO BusinessWorks will pale in comparison. It's an outdated product.
I would say that they have to change their original design. The market is such these days that a solution needs to be able to handle live calculations and transactions – millions of transactions per second and billions of transactions per hour.
For example, if you have a server in the US and you have business users in Japan. You will have an integration with Japan and so the network IO always plays a very critical role when it comes to millions or billions of transactions. What happens in such cases, with the latest technology and tools available in the market, you can add, put memory, or replicate the server per country or per region. You can't do this with TIBCO BusinessWorks. With TIBCO BusinessWorks you just have an option to deploy everything on one server and then access that server.
TIBCO BusinessWorks also needs to introduce multi-trading. It is definitely not there or if it is, it's expensive.
I have been using TIBCO BusinessWorks for six to seven years now.
TIBCO BusinessWorks is not stable. I have many complex, business-critical applications and we have run into sudden issues related to them in the past. When we traced the log, we found that the issues were not created by changes we implemented in our business logic. They were just random issues. Also, sometimes the memory usage spikes up. We face these issues frequently with TIBCO BusinessWorks.
Scalability with TIBCO BusinessWorks is problematic for us as it is expensive. It is also not possible to scale up TIBCO BusinessWorks drastically. You can scale up to a certain extent by adding memory, but that is way more expensive.
The TIBCO BusinessWorks tech support is not very responsive. It's not that great. The tech support staff is not very knowledgeable. You can get an immediate response if you start an email thread, but the investigation takes time.
Whenever we contact support, I feel like we spend quite a bit of time going in circles. They will ask us for use case data, for example, and when we provide that, they will ask for more information. They should have a fixed template for support in certain domains for us to fill out when we reach out. They could even create a support page for us to investigate before reaching out to them.
Neutral
When we started six or seven years ago, we could choose between TIBCO BusinessWorks or Office's Shell. The clear choice between the two was TIBCO BusinessWorks as it has more advantages.
But later on, as things improved in the IT world, Apache became a better solution as it is open source. At the same time, it's backed by Java. It has significantly more features compared to TIBCO BusinessWorks and, at the same time, its licensing cost is almost zero because it's open source.
The initial setup was complex. On a scale of one to five, with one being simple and five being complex, I would give the initial setup process a three and a half.
The initial setup was done both in-house and with help from a third party. We hired an expert to onboard us. Then, when we were done with the knowledge transition, we created a team to manage the deployment and everything else. This is another reason why TIBCO BusinessWorks is problematic. You need separate expert teams for configurations, deployment, and everything else. A developer cannot do any of that.
We now have a maintenance team of 10 people for TIBCO BusinessWorks. The solution requires daily maintenance. This is because some of our applications are critical and sensitive and we do not want to run into any disruptions or have any negative impact on the business. We have people monitoring usage daily, 24/7.
The solution is too expensive. It's one of the most expensive solutions out there, particularly because there are so many open-source competitors on the market. I don't know the exact numbers, however.
On a scale of one to ten, with one being the worst and ten being the best, I would give this solution a four for overall performance.
