What needs improvement with Equalum?

If you need to use the basic features of Equalum, for example, you don't even need data integration, then many competitors in the market can give you basic features. For instance, if you need batch ETL, you can pick among solutions in the market that have been around longer than Equalum. What needs improvement in Equalum is replication, as it could be faster. Equalum also needs better integration with specific databases such as Oracle and Microsoft SQL Server. An additional feature I want in the next version of Equalum is integration with more databases such as ERPs, for example, SAP, and new technologies such as blockchain. That's the path to take because there's a lot of information on SAP, and it's what customers ask. If you need to integrate different systems, you must easily get information from SAP, for instance. You have ways to retrieve data from there, but there's still room for improvement, and as for the blockchain, there's little integration at this point, but in the future, more blockchain integration would be great to have on Equalum.

When it comes to the product as it's designed, we haven't really seen any flaws. It's doing what it's supposed to do. However, there is not enough proven integration with other vendors. That is what needs to be worked on. Equalum hasn't tested anything between vendors, which worries our clients. We need more proven vendor integration. It is an expensive product and it needs to support a multi-vendor approach. A proven integration would be that two vendors, let's say Cloudera and Equalum, agree that this is a product that works seamlessly with the other product. That includes testing the functionality and even looking at the support model. If you have a multi-vendor environment, you want to know who to call if there is an issue. For large investments, these kinds of things are bottlenecks, and they cause clients to stay with their incumbent suppliers, because of ease of use and not because of the technical quality. This is not something that can be solved in the field. This has to be done strategically by the vendor.

Their UI could use some work. Also, they could make it just a little faster to get around their user interface. It could be a bit more intuitive with things like keyboard shortcuts. They already know this from me, because I have already complained to them about it.

When we bought the tool, some of the features were missing, but we knew the power of the ETL was very good. Initially, I wanted scheduling within the tool itself, which is not there. However, I am using another open source software scheduling tool, Rundeck, which calls the Equalum APIs and runs them on the Equalum server. That was a workable solution for me to schedule the data loads. I wanted something with a UI interface where I could schedule within the tool, which is an improvement point for them. Right now, I have a workaround. For any application that you start, if it doesn't have a feature but is integratable with other applications, then it is a good tool. We are working with DB2, and there are some roadblocks there for us, but we are working through those. I should be able to see only my project versus somebody else's garbage. That is something that would be good in future. Right now, the security is by tenants, but I would like to have it by project, e.g., this project has this source and flows in these streams, and I have access to this on this site. Something not in the tool is a CLI interface. The interface is not open to everybody. It is very restricted to admins, a DBA, like me.

The Equalum user interface is extremely easy to use. I would rank it really highly on user-friendliness. The only issue with the user interface is it doesn't supply everything that you need for somebody who has to work with Equalum. For example, when you get deep into development, there are many areas where you have to go to the command line to do things and the Equalum user interface does not have that functionality. The deployment of their flows needs improvement. It doesn't work with a typical Git branching and CI/CD deployment strategy. If you have multiple projects, all working in one Equalum environment, separating out their work is something that you have to design into your implementation, as opposed to baked into the product.

There are areas they can do better in, like most software companies that are still relatively young. They need to expand their capabilities in some of the targets, as well as source connectors, and native connectors for a number of large data sources and databases. That's a huge challenge for every company in this area, not just Equalum. If I had the wherewithal to create a tool that could allow for all that connectivity, it would be massive, out-of-the-box. There are all the updates every month. An open source changes constantly, so compatibility for these sources or targets is not easy. And a lot of targets are proprietary and they actually don't want you to connect with them in real time. They want to keep that connectivity for their own competitive tool. What happens is that a customer will say, "Okay, I've got Oracle, and I've got MariaDB, and I've got SQL Server over here, and I've got something else over there. And I want to aggregate that, and put it into Google Cloud Platform." Having connectors to all of those is extremely difficult, as is maintaining them. So there are major challenges to keeping connectivity to those data sources, especially at a CDC level, because you've got to maintain your connectors. And every change that's made with a new version that comes out means they've got to upgrade their version of the connector. It's a real challenge in the industry. But one good thing about Equalum is that they're up for the challenge. If there's a customer opportunity, they will develop and make sure that they update a connector to meet the needs of the customer. They'll also look at custom development of connectors, based on the customer opportunity. It's a work in progress. Everybody in the space is in the same boat. And it's not just ETL tools. It's everybody in the Big Data space. It's a challenge. The other area for improvement, for Equalum, is their documentation of the product. But that comes with being a certain size and having a marketing team of 30 or 40 people and growing as an organization. They're getting there and I believe they know what the deficiencies are. Maintaining and driving a channel business, like Equalum is doing, is really quite a different business model than the direct-sales model. It requires a tremendous amount of documentation, marketing information, and educational information. It's not easy.

Right now, they have a good notification system, but it is in bulk. For example, if I have five projects running and I put a notification, the notification comes back to me for all five projects. I would like the notification to come back only for one project. They are working on this improvement because we told them about it. There are the small changes that we keep on asking from them, and they do them for us. If you want features or to modify it, they help us with that. So, the team is on it at all times.