TIBCO EBX Reviews

We're using the solution for reference data, master data management. To basically implement data governance around the reference data.

One of the big initiatives is to capture all the information that the branch operations team is looking to capture. Or operational information or reference data. We're a credit union. We're like a bank. It's all about managing the data of the branches, and the ATMs, and some of the business partners that are at the branches.

There used to be a lot of handholding by ISD. This kind of solution gives control to either ISD or business units to do what they need to do. We don't have to play the game of telephone or do any handoff. We don't have to specify "Here's what I want" and then get it translated unnecessarily by the ISD people that don't understand the business.

That's why the business is entering the information. They're verifying the information for files or tables or whatever that aren't really controlled by that department. Then the ISD can kind of step in as custodians and handle some of that for them. Typical stuff like stuff that's sourced externally - like an ISO country table.

They don't want the department saying that there is such and such a country, and adding to the country table. We basically want to pull it from the internet, from the ISO International Standards Organization, and say, "These are the official, full list of countries and country subdivisions," which are states and provinces and such.

The data modeling is very good. It creates for you a GUI interface, which are the forms that the stewards would fill out to add or modify data. That works fairly well. 

I like the features of that, especially with regard to the product key relationships, which result in pull-down lists in the forms.

The workflow models are great. We use them a lot. It's text-based and you can basically add different kinds of steps right into the workflow. There are different parameters for each kind of step. 

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.

I've been using the solution for almost two years now.

We just recently ran into an issue in one of the test environments. The jury is still out on stability. It's been fairly good and pretty reliable. I believe I haven't seen the system come down on production really, other than when some of the teams involved make mistakes on rolling out the next deployment. It gets a little rocky if they don't know what they're doing, however, that's just an operations issue.

The scalability may be somewhat limited. Basically, the application is designed to run on a single application here. You can have it hooked to various different databases. It works with Oracle or SQL Server. We implemented a SQL Server. SQL Server itself is not horizontally scalable. You can't add servers. They're just replications. It's good for high availability, however, not for scalability. That said, it also can run in SQL Azure, and SQL Azure in my understanding is scalable both vertically and horizontally.

The tool is not limited. On the database tier, the database isn't limited. It's only limited by your implementation choice. If we're in Oracle or SQL Azure, we can scale. For reference, data is probably not that relevant because it's relatively small volumes in the grand scheme of things.

However, for the application, if we rolled this out across the organization and had a lot of activity, we could get into potential trouble as you can't run with load balancing and such. You basically have an active-passive failover. You have some high availability and not the scalability of the applications. That could be designed in various ways. We haven't tried that yet.

We only have a handful of people who have access to the solution. They're either stewards such as subject matter experts or they are some kind of reviewers, approvers, overseers. There are also developers that are functioning like admins. There are two main departments that are using it currently.

When it comes to technical support, most of the challenges have been at development time on production, and therefore we haven't really had much opportunity to test their response in a production outage situation.

However, in development, it's a lower bar. Sometimes we don't get a quick response. It depends on who is helping us, who's been assigned to support us. Some guys have been great and other guys are out of office and they don't seem to have anyone backing them up and we need to wait for them to return. We don't know what the answer is. Sometimes getting answers has been challenging.

The technical support is average, or slightly above. On a scale from one to ten, I'd rate them somewhere between five and seven.

We had a contact that was really good and then, after the acquisition, when Orchestra sold to TIBCO, TIBCO started migrating some of their functionality to direct with some of their other products. Things shifted a bit and after they were solidified, with COVID, they've cut resources and we've ended up losing one of the good resources that was giving us pretty good answers to technical challenges.

We didn't really use a different solution previously. For data governance, we used some homegrown stuff, basically. We're still doing that in some areas.

The initial setup can be a challenge due to the fact that there is not enough examples to model after. There isn't enough documentation to go off of. 

They gave us some templates and things to work from, and that helped those artists. We also had to dumb down some of the templates and start from almost scratch to kind of get the workflow actually working. It would be great if there were some standard items to work off of. It would be nice if there was a bigger community where you could share ideas with other customers about the product.

The deployment took a while. We were refocused three times on different aspects. Then there were multiple organizational changes, department changes, et cetera. The first production implementation took almost a year. After that, we've probably handled seven or eight subsequent releases.

We're rolling out to different groups more frequently. It's not just the branch shops. We've done some things for other teams as well. In general, it's been a year and a couple of months.

For maintenance, right now, we're down at two or three developers. 

We didn't really solicit any outside help. The implementation was handled by employees and our internal consultants, and not any kind of system integrator. Everybody on the project kind of learned from the ground up. It would have been nice if we have here an implementation team that some third-party ran. It would help to have outside help from a company that was familiar with the product and the process. However, that wasn't available.

While my understanding is that the solution is on the less expensive side, I can't describe the actual costs. We do pay an extra fee that covers upgrades and support. While that may have been included in the original cost, it may have to be renewed every year.

We evaluated a few different options. We looked at Teradata, which has some kind of reference data management. We looked at Informatica MDM. We looked at Collibra, which is more of a governance tool than an MDM tool. We may have looked at an Oracle tool as well.

In the end, we felt technically this product had more robust data modeling capability, especially for the foreign key referential integrity.

Collibra is very atomic. It'll handle a lot of reference tables. However, there was no referential integrity plus no relationships between tables and stuff. That was pretty much non-existent.

We aren't using the latest version of the solution. We're a few minor versions behind.

There are some questions coming up, of what our direction is going organizationally. There are some new directions that may include moving to the cloud from on-premises.

That could have an impact. There's also an appetite for high availability and scalability and all of that as we are a very large organization. On the other hand, some of the competition that is using the same tool, are some of the really big banks and such. There are other organizations, other financial institutions that use it. Their typical complaints are concern over scalability but they're using it, so it's not so surmountable.

The advice I give to others is if it's the first time you're doing data governance, you're not just implementing what you're doing manually today. You want to improve the process. There has to be some practice and awareness of the process design and the rules about governance.

I'd rate the solution at an eight out of ten.

We have multiple sets of data coming in from various upstream systems, SAP being one of the main and most dominant systems. We have non-SAP as well, such as Microsoft systems, Oracle Database, and some other legacy databases. We need an MDM tool where we can merge the data and get the main records out of it after merging and matching everything.

The tool has merge and match features and allows us to get the golden record out of it as a single source of truth and then use it as a master of our data, as a Master Data Management tool. We also stored the Data Governance Rules using the information Governance Add On.

We have used EBX to collate data from multiple source systems, a majority of them are SAP systems to create and update the Master Data and Reference Data. Also to to perform the Match and Cleanse activities and then store the set of Golden Records to feed the various downstream BI and ML systems.

The product is highly customizable. 

The product is extremely flexible. 

The Data Model view and compare feature.

The Workflow once created is very stable.

If not much customization is needed the product overall is quite stable and runs consistently.

They are working at adding in match and merge capabilities in future versions . 

There is also an expected good amount of improvement on the UX . 

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. 

We have been using the solution for three years at this point. Initially it was fitting our Bill as the SAP data was handled separately at that time using SAP MDM and MDGM.

The tool is quite stable and very rarely goes down or crashes.

The solution doesn't scale as well as we would expect. Although it has some dependency on the underlying database but still we would expect better MPP features and also the tool should be able to optimize the underlying clusters more effectively.

As our SI partner interacted and we did not interact directly with the TIBCO support we would not be able to comment on this. 

As our SI partner takes care of the further upgrades and patches so we would not exactly know about the effective of TIBCO's support as the SI themselves handle that. But at times we felt that it could have been a bit faster.

The initial installation is not very complex, however, it was not extremely straightforward either. Our SI partner did it for us and it was on time. Also after the initial installation and configuration we were happy with it overall.

We implemented it though our SI partner who are preferred Implementation partner of TIBCO.

This is one area where I think EBX scores well. There licensing is quite straight forward.

As we are not totally happy with this product in the present scenario, we've been looking into alternatives that may be better suited to our needs and the needs of the company. We are trying to shortlist tools at this time. We're doing some research around it right now from both ease of implementation and Use and Licensing terms. 

We're just customers and end-users. 

Whether I would advise another company to choose this solution or not depends a bit on the use case they are going to develop. I would say that, if a company has a basic use case, a basic means of getting data from a few sources like Oracle, SQL Server, Teradata etc., then maybe it is sufficient. However, if you are having an enterprise-level situation for SAP or Oracle Apps , it might scale up that well.  Performance is also an issue as it does not optimize the underlying clusters to a great extent as compared of its competitors. One good thing is that, with the data model, you can just go and see the data model very well, to the most granular level and identify if there are any gaps. It also has a rich compare data model feature.

 However, again, for the workflow, you cannot edit it in the visual editor. You have to go back to that tree setup and there after complete editing during compile only one would be able to see if any errors has crept in or not. Having said that I would say the Workflows once created are very robust.

There are some competing tools that allow the editing of workflows in the visual setup itself. That is very easy for users. If you can edit it in the visual setup, you can directly see the impacted upstream and downstream tasks or jobs in that workflow and conflicts if any. This speeds up the updating of the workflows by the data engineers or data stewards.

I'd rate the solution at a six out of ten. The solution is average from an enterprise standpoint.

We are using TIBCO EBX for the data governance of our accounting system.

TIBCO EBX has centralized several master data tables, which were very often in private Excel sheets of accountants. With EBX it was possible to put a data governance process for the core accounting application, which was otherwise not possible.

The most valuable features of TIBCO EBX is its completeness. Everything can be done inside the tool, including data governance. We are able to model everything according to the needs of the company. If the company needs five people to agree to a change in data, they can do it with TIBCO EBX. They can model it with any particular rules. Additionally, there is dynamic data modeling, workflows editing directly using the GUI that comes from the server.

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.

I have been using TIBCO EBX for approximately three years.

Sometimes it's a problem of how people implement the TIBCO EBX solution. Elementary errors can potentially cause long-term instability of the system, We have had some issues with performance because of this.

I was not only working as a business analyst, but I was also programming with TIBCO EBX. TIBCO EBX is not always scalable, because if you start to process high amounts of data, you need a better UI. You can only display a limited amount of data on the screen. For example, 100 rows on the screen. If you have a lot of rows on the screen it's taking a long time until it gets displayed. There are some things, such as background validation that, at a certain point, have to be turned off because over a certain amount of records it slows down the system. However, it takes more than 30,000 to 40,000 records per table to start to have problems.

We have a preferred line to TIBCO EBX for support. Their response is very good but their efficiency could improve.

I rate the support from TIBCO EBX a four out of five.

The price of TIBCO EBX is too high. The solution can only be used in a project that has good sponsorship that can afford it.

I would advise others that are wanting to implement TIBCO EBX they should try to build the data model from the beginning until the end. Take the time that they need, try to build as much as possible in the data model. It is best to build the workflow that they want at the beginning. They have to decide if they want history or data governance, or exactly which other part they want. It is important to build what they have and want on paper regarding the functionality of their core system before implementing it into TIBCO EBX. 

I rate TIBCO EBX a ten out of ten.

We are trying to achieve is to have customer vendors fill in various master data. It will be used across the enterprise and will be used for sourcing from a different data sources. Currently, we are working through this process and providing master requests.

The match and merge features are very good. They help for, for example, validating visas.

We also use a lot of add-ons.

The data quality is very good. 

The solution is stable.

You can customize the product.

It can scale if you need it to.

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.

I've been using the solution for the last two years or so.

The performance could be better. We're not 100% happy with it at this time. 

That said, it is a stable product.

We have more than 48 users at this time. 

The solution is scalable and customizable. 

While I haven't been in direct communication with technical support, we do have teams that are able to reach them if they need to. 

The initial setup can be a bit difficult. It's not easy to configure it actually. We need some experience and configuring it right now is an issue. It's not so easy we can start using it on day one. The process is complex due to the level of customization.

The deployment process was long. It took us about three months in total. 

There is a bit of maintenance required. It's periodical. It may require patching every once in a while, for example. 

We had a third-party vendor that helped us implement the product.

I don't handle any aspect of the pricing or licensing. I'm not sure how much the solution costs. 

We're a customer and an end-user.

Currently, we are one version behind. We're going to upgrade to the latest version maybe in two months, however, I'm not sure of the exact date.

I'd advise new users to ensure they understand the scope of their implementation and applicability in their observation. 

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