OpenLegacy Reviews

We're using OpenLegacy to monetize our mainframe assets. I've been doing this for 40-plus years. I was working in diagnostics since CICS and Mainframer. Then I moved to distribution back in the nineties. Everybody has tried to get away from those mainframe applications and assets as much as possible, but the reality is you literally can't. Our bank was bought by this $500 billion bank working with Hogan. I was a Hogan expert back in the eighties and nineties. It's an early-1990s mainframe. Once you're tied up with that kind of stuff, you're not going to easily get off it. I had a boss who always used to say we should be able to get off a mainframe application in two to three weeks. He got fired.

There are many people who will try and get you off a mainframe and say that we can port the data. Of course, you can import the data, but here's what people fail to understand about a mainframe. IMS, CICS-transaction, or shared databases — whether it's by IMS Db2 or even VSAM— have been around for 40 years. So that means that, for all intents and purposes, the mainframe is a big PC with a lot of DLLs. And those DLLs allow you to jump from one application seamlessly to another application.

So over a 40-year period, it's likely that nobody ever built a component-based architecture on a mainframe, or they may have started with a component-based architecture on a mainframe, but you have data sharing through shared data sets where you have program-to-program jumps from one application to another seamlessly. When someone says they can pull an application out, they failed to take into account 15 other applications that have dependencies. 

That's the challenge with a project like this. It's like that Jenga game where you pull stuff out. You need technology that allows you to have a bidirectional call in and call out. You have to look for tooling that is flexible within the constraints that you have for that mainframe in the portfolio. Our project went south, and it was a half a billion-dollar project.

It might be considered to be a hybrid deployment. On the Microsoft service side, we're running an AWS application in our own tenant. But it's still an AWS public cloud. Obviously, there's the kernel and pieces of code that run on the mainframe. And those pieces that are on the mainframe would be on-prem. So I would call it a hybrid deployment.

The biggest advantage of OpenLegacy was how simple the technology was. We were able to build out the OpenLegacy parts very quickly. We put together a couple hundred APIs in six months.

I'd like to see OpenLegacy develop its low-code/no-code (LCNC) solutions. They've expanded somewhat their horizons for integration beyond mainframe CICS, which is their sweet spot. They have some tooling in that area, but it's not as good as it needs to be. 

OpenLegacy handles the bread-and-butter TP monitoring stuff, but I am working for one of the six banks in the United States still using the Hogan mainframe, which has a slightly proprietary mechanism. But OpenLegacy currently doesn't have a connector for Hogan. So it would help if they could build one. That would appeal to financial institutions that still use Hogan, like US Bank, Wells Fargo, KeyBank, and Vanguard.

We've been using OpenLegacy for two years.

We were able to execute mainframe enablement within six months. We had all that built.

We partnered with FIS Global, one of the largest and most prominent banking software vendors. They had solutions that actually work in production. Our leadership at the time would not look at those solutions that were working. Instead, they wanted to partner with a vendor to build a new microservice-based platform because we were imposing that on our vendor partner. Of course, they'll do anything for money, but they couldn't deliver on schedule.

That's really where we're the problem began and ended. We were building our stuff and were on time with our delivery, but our vendor partner was constantly missing their deadline, and you're burning $20 million dollars a month. It doesn't take very many months before you've wasted a lot of money without any progress.

OpenLegacy charges you based on the API. I'm not exactly sure, but I think the final negotiated price was something north of $100,000, but less than $200,000 for upwards of a thousand APIs. So it was a very reasonable price point. IBM pricing is built around the Altair size or the size of the machine. If you're running a big machine efficiently, you pay a penalty for running a big machine. So the IBM pricing tends to be not competitive.

We chose OpenLegacy over the IBM product for a few reasons. When it comes to monetizing existing assets — mainframe assets in particular — there are two use cases. One has been solved for years, and that's the ability to expose a mainframe asset as an API. Several technologies can do this, such as the old MQ CICS bridge and IMS Connect. 

But the real challenge has been the ability of mainframe assets or IE programs to consume a microservice API. That's why we gravitated toward OpenLegacy. I know IBM can also do the same thing, but here's the second. The problem is most of the dev teams don't want to touch the mainframe. The mainframe is like a mysterious box that your grandfather worked on.

IBM tooling requires a level of knowledge that most contractors don't have. OpenLegacy involves a very minimal effort on the part of the mainframe team. Connecting is very simple because it connects straight into the CICs applications. It was simply a matter of creating a sub-program and passing the right COBALT copybook out to something called the API caller. There is a bit of work on the mainframe, but it's very contained. At the same time, the other solutions required too much mainframe knowledge for a project where you have a lot of offshoring. We wanted to use primarily non-specialized IT people working with Java or .NET because of those microservices. That was the primary driver: much less complexity. The cost was a factor, but it mainly was the complexity.

OpenLegacy caters to a specific niche, which is one of the reasons why we went with them. We were also looking at MuleSoft, which is a fabulous company that makes a lot of things easy. But even MuleSoft couldn't jump to the mainframe like OpenLegacy. That was really an eye-opener. While MuleSoft is a solid solution, you still have a niche problem with connectors, which OpenLegacy was able to solve. But ultimately we went for an open-source solution and then addressed the niche requirements with solutions like OpenLegacy. 

I would give OpenLegacy an eight out of 10. Almost no solution gets a 10. The reason for the eight is that it actually solved the problems that we had for 200-plus APIs very quickly. It was very impressive. There were some glitches, but OpenLegacy was extremely responsive. They don't get a 10 because we still couldn't employ their low code/no code.

We are a finance business and this solution is a development platform which has allowed us to create integrations and build solutions quickly. 

We use it to create the Springboard artifacts with logic connectors as well as Plainview Java codes. Once each of the microservices has been created,  Springboard artifacts can be used to create service mesh on the cloud of choice.

We are able to create services very quickly because it is just a matter of having the right talent and a customized version of Eclipse. The latest version of OpenLegacy also has a customized version of Intellij. 

At this point, we don't have OpenLegacy deployed. 

The speed of development of production, especially in specific environments like IBM mainframes, has been valuable. For example, it is possible to connect a service to a mainframe program or back transaction in a matter of minutes or hours at the most. 

The pricing of the solution could be more flexible and allow for once-off payment versus annual licensing. This would be more appealing to companies in Latin America. 

I have worked with OpenLegacy for five years. 

From a developer's perspective, I would rate it a ten out of ten. From a CIO perspective, because of the licensing pricing model, I would rate it a seven out of ten. I would also have given it a higher rating if it was a company that has been around for a longer period of time, like IBM.

Our primary use is handling data and transactions. I'm working for a bank in the end we develop and we deploy banking systems to resolve day-to-day issues with banking data and transactions while adhering to all the necessary regulations.

The product has helped our business by allowing us to become more efficient in data handling. In this way, it has helped us quite a lot. We had several legacy systems, and because we had a lot of separate systems, we had a lot of problems integrating the data for each of them. So we purchased Open Legacy for its integration capabilities and we actually integrated all of them. That efficiency absolutely it helps.

The features that have been most valuable in our situation is that this can be used as an enterprise solution and the fact that it is open-source. Partly because it is open-source, it has a lot of features and because of that, it has helped us be flexible with solutions. There is no end in this area to what can be accomplished. I can always learn more and more as I think it is the responsibility of being in my position and using this product effectively.

I think the features of many solutions can be improved, but not all have to be and they are not all urgent. The thing we need most is better support. It is hard for us to deploy systems because support is not always available. They sell the product licenses but they do not think about how to support for those who have problems like us which are immediate and urgent.

Other factors matter less than being able to resolve issues quickly. Not everything is negative. The user interface is a good one because the access to the features is not difficult. But for countries like mine and businesses like financial services, the pricing and consistent accessibility to an operational system is imperative. These are some problems and the support for them doesn't go far enough. When we have these problems with the system, we have big problems with our customers. It really bothers me when we need help and we need something or lost something and can't get access to help quickly. This really creates some big problems for us and we cannot handle them or do something about it right away.

Based on experiences the stability can be fine most of the time. The system itself is pretty stable. Honestly, some of our solutions and the things we have deployed are not suitable for what should be used in the system. Suddenly we would deploy and reveal that there were problems there and we had made something wrong. It was just because of how we did it and our problems were more about not having enough knowledge. That's because of system inefficiency and lack of support. So I think the problems that we have experienced are not because the product in a sense is because of our lack of knowledge. In other words, we have seen lots of instability, but I think it's not because of the system.

Based on our requirements and functionality we need, this product has met our needs for scalability. At first, our team had approximately about 10 to 20 changes due at a time and our team grew to about 25 people because we had a lot of problems.

We have been very dissatisfied with customer support. We hope they do something about it and that clients who use the product don't experience the same problems we did in the future.

Before I was at the company they had used a proprietary system. There were a lot of homemade, in house, systems. That caused some compatibility issues that needed to be resolved. Using Open Legacy, we actually omitted those issues by not needing to use the legacy components we created separately. We didn't use them and started to use Open Legacy and started eliminating issues.

It may not be the perfect solution but it did solve some problems. In an enterprise system and enterprise companies, migration or changing the basic structure of the solution costs a lot. I think it is not a good plan for us to change in the future. I think that it is not perfect, but they won't want to change it. And if they did, they would not know if it were a better system.

I was not at the company for the original setup so I don't know.

Because we are under certain sanctions for the banking industry and there's a problem with technical support, we worked through test case studies, research and development and had a lot of problems. So then suddenly our deadline comes up and we did it all, but it was on our own. It was a big team and we accomplished a lot. But there are lots of problems without any help and no one with specific experience working on the project. 

I would be guessing that since implementing Open Legacy that we have seen a return on investment. It would be hard to put that into an actual amount.

I don't know if the company actually evaluated other solutions when they brought on Open Legacy as I was not yet in the company at the time. But the investment in the system will probably mean it will not be changed.

Because of sanctions, unfortunately, in our country, we can not use a Cloud-based system so even that could not have been part of the evaluation.

If I were to rate this product on a scale of one to ten, I think a five is good enough. The system is good and can accomplish a lot but because support is not so good, we had many problems we should not have had. We waste a lot of time to be stable in using the system, and that cost a lot for us. If there were better support then we would have had fewer problems and we would have saved a lot of time.

OpenLegacy is used anytime we need to send data from a modern web application into our iSeries legacy system. At this point, we are still developing the web applications to feed OpenLegacy. 

Our first use case is entering freight data into our legacy system. With OpenLegacy, we will be able to use a modern web form which is easy for our employees at the freight dock to use, and get data into our legacy system.

OpenLegacy opens the door to connect modern web products to our old legacy system. Before OpenLegacy, we would either transition our entire system (a huge undertaking) or do painful workarounds to allow for innovative web products to send data back into our system of record.

Ease of deployment. OpenLegacy produces a war file which includes everything you need to deploy a Tomcat server.

I would like to see SSL out-of-the-box. OpenLegacy certainly does SSL, but it was not the default for our use case. We are currently working with OpenLegacy to cross the SSL bridge and suspect that most users will want to do the same.

I am the chief programmer for the largest credit card company in my country, with 4.5 million credit card users. Isracard has a lot of business logic in our IBM 3270s, and it is impossible to use the regular ESB stack. We have to convert the logic into routines, which could potentially take weeks or even months using the Isracard Business Hub.

In some cases, the old mainframe system has been closed and we can’t get inside easily. The programmers said we needed to make a change, so we looked at OpenLegacy. 

We use OpenLegacy to give the 30-year-old legacy data to developers so they can make it available to consumers, including customer data, and the transactions between the customers and our business. End customers want access, via mobile, to details about what they bought, where they bought it, and how much it cost.

Using OpenLegacy, the exposure of services is far easier and quicker. In many cases, exposure of services requires just a few clicks and takes only minutes. In very complex cases, it still only takes half a day. Without OpenLegacy, it would take us several months to create the same services.

With OpenLegacy, it took only two clicks to get REST API to get to digital. We did a pilot and saw that it was easy to do. We can create REST APIs with a basic understanding of the mainframe's business logic, and without having significant Java knowledge.

Using mainframe programs (not screens), the OpenLegacy services do not require any changes by the mainframe programmers, thus reducing development cycles. In addition, OpenLegacy gives us a unified way of “calling” the mainframe programs both in 3270 screens and programs.

Digital is one of our biggest priorities and when we heard what OpenLegacy could do, we actually pursued them. Time to market is a big factor. OpenLegacy helps fill our requirement to go mobile and get more interactive between customers and our business via mobile.

We are able to take old legacy customer data and use REST APIs to give customers the best experience. We can do everything via mobile, including payments and transactions between our customers and their suppliers. 

OpenLegacy is definitely faster than writing old legacy code. We have the ability to change what we want more easily than the "old" vendor company. 

Debugging and logging for programmers.

We would also be more than happy if the product had the option to work in the opposite direction – the ability to consume REST/SOW services in the outer world from the mainframe.

No issues with stability.

No issues with scalability.

No, we did not have a solution that could be this flexible and give us the results we need.

The first installation was very simple. A team from OpenLegacy accompanied us but did not have to implement complex things.

OpenLegacy provides a way to go from the outside world to the legacy mainframe, to move the old standard application to a REST API application. New digital services can be created in a few clicks and this can be done easily by COBOL programmers. It is much easier for these programmers who wrote the old code.

OpenLegacy is so much easier. They understand our vision.