It's a pretty steep learning curve, I find. And not really fluid and flexible. There is some graphical rendering of the workflows, however, you can't really develop them in terms of the graphical picture. Whereas a lot of BPM-type tools will give you that kind of capability.

The workflows need improvement. You need to develop, kind of conceptually, what you want. It's basically a web app generator, so there's a lot of magic under the covers. When you're trying to promote the changes through a version control system, it's hard to know what to expect as far as all the content. For example, if we were building and writing Java code, we would know what's changing. However, due to the fact that we're just putting in models and embedding some business logic in the models and such, it generates a web app, a job of whatever. It generates XML and some other stuff. And that's XSD. Then when you go and say, "Okay, let's push these changes," in Git or in Eclipse, et cetera, it's tricky to have a multi-developer environment where you're not stepping on each other a little bit. You're not as aware of the repercussions of your design changes.

The documentation needs improvement. It would be helpful to have more during implementation, for example. It would help make the initial setup more straightforward.

In a workflow, you can't set default values for certain columns, which would be nice.

If you're handy with Java, you can create your own services and such and do something there, however, it should be out-of-the-box functionality. If you have a generic system, you should be able to say, "Hey, this structure supports A, B or C." Yet, if you launch it, if department A launches it, assume that certain values are set to their preferences. As department D launches assume that the department is B and you know, certain values are set, et cetera. Otherwise, everybody comes in generically, and then they have to know more than they want to know.

There's this thing called replication. You could replicate the XML database to SQL Server on Oracle. That replication doesn't happen if you use certain features of the product. For example, with one of these features, you can do calculations or calculated fields. You could say it's X, then do a sum, et cetera. If you have a calculated field, you're not allowed to replicate it. It would be better if they could allow the replication, even if maybe they have to limit the functionality to those columns. 

There's an item called inheritance. You could say, I don't want to, if I asked for your name, I don't want to ask for your name three more times. So when I get to another file on the table, it's already there. It will carry information by inheritance, so you're not going to enter it wrong three different ways, however, once you have inheritance, you can't replicate. It would be better to ignore the inherited fields, just nix those columns, yet allow the table to replicate. Then you can have an SQL server go in and read the data in a relational way, which is very helpful to make it acceptable to developers and business analysts, et cetera.

Currently, users can't use Plain SQL queries in TIBCO EBX. It would be great to use Plain SQL queries in TIBCO EBX. Right now, TIBCO EBX only supports Java, but I believe that it should support SQL queries on its interface. In short, certain areas in the UI area can be improved to support SQL queries.

Everything is updated through forms, and working with UI web forms. It's more record-based processing. It is not mass-based processing. This is one of the things that are not good for TIBCO EBX.  Another problem is we cannot join tables and prepare a view where the tables are joined. Someone can code it but it is not a feature of the solution without code. You have to take data from a table, combine it with data from another table and then present it. This could be done better.

TIBCO EBX should improve the UI, to allow users to easily mass change the data a bit more. We should not have to click the records one by one to change the data. 

The filter is in a form, and if one is to filter the data based on a form, you have to click every single attribute. It is difficult with the UI. However, one could be inspired by mobile phone UIs, how they are doing it because they are more efficient and this is missing in TIBCO EBX.

We would like to see the community an documentation for this solution be developed. At present there is very little tutorial documentation available, and limited community support for issues with the product.

We would also like to see support added for the mobile MDM, so that the solution can be integrated with handheld and IOS devices.

TIBCO EBX could improve by making the building of rules less complex and the repository is not robust.

In a future release, it would be beneficial to have a Match and Merge feature.

We are currently using TIBCO EBX, however, we are not very happy with the performance of that tool. 

The product does not scale well horizontally particularly in the cloud. We find the scalability to be quite inferior to other options. 

The product has some compatibility issues with Azure SQL also. We heard that it works best with PostgreSQL which is not an ideal Cloud Database as it has scalability issues.

The business team is not very happy with the product's UI/UX. It could be a lot more clear. Right now, they struggle, for example, with creating certain views from the UI. A lot of irrelevant questions are asked during the view creation which actually confuses a Non Technical user. Also, simple things like copy, paste, bulk copy, and bulk paste features are not available(one has to insert separators manually between the different data elements manually). The multi-index search feature is either not there or not very useful.

These are some other problems which the business users have mentioned, as they don't have the technical knowhow to manage these tasks. If they directly want to change a particular set of data within EBX, they cannot do it directly as direct editing in EBX is not available - it may be for a good reason, but the tool still should allow this with the check and balances in place. This involves a Data Engineer in between which slows down the process a bit . 

The hierarchy, in terms of downward or upward drilling, is not great as the links are not well preserved. Sometimes when you are searching multiple tables, child tables or linked tables in a particular Dataset, there is a possibility that you might get lost and struggle to go back to some upstream table. The bread crump needs further improvement.

The learning curve is pretty steep, as you need to learn a lot of things in Java and do some coding to implement certain customizations.

Some other modules have also been removed in future version. For example, Information Governance, which we were using , will no longer be available in Version 6 is what we heard. Without that, the integration of Data Governance Rules with the transformations might be impacted. 

The tool has to improve mapping and workflow. It should be made more robust. 

There are some areas when I compare this to other products where it could be better.  The data quality, workflow, integration of data quality, and the force to master data attributes can be enhanced. 

The performance could be better. 

The initial setup can be a bit complex. 

I would like to see higher-level filters.

It creates a bundle of all its related entities and its versions too, so the record changes too many times, it ends up with a bigger bundle to load, and this results in it taking longer to update/view.

The support isn't great and takes too long. And the pricing can be improved.

Sometimes it is a little difficult to find an architect for certain developments. You kind of have to be like technicians to work with this product if you want to make some specific development. So perhaps it could be simplified. The design should also be easier and more visual.

In terms of improvements that this solution needs, it should support big data. 

EBX should target becoming horizontally scalable. Currently, it supports vertical scalability only.

Version 6 needs more work - stay with 5 unless you have to move.