IBM webMethods Hybrid Integration Reviews

We had quite a heavy use case in terms of transactional traffic, and webMethods was quite fantastic in processing all of those workloads.

Some of the key features are the integration platform, query mechanism, message handling within the bus, and the rules engine. We've had a really good experience with webMethods Integration Server.

On the monitoring side of things, the UI for monitoring could be improved. It's a bit cumbersome to work with.

I've been using webMethods Integration Server for about five years.

The current version is in our private cloud, and we implemented the same solution on-premises and in the cloud. So, we have implemented a hybrid solution.

The initial setup was straightforward.

We implemented it through an in-house team, and it took about four weeks.

There are no hidden costs in addition to the standard licensing fees for webMethods.

For corporate organizations, it's a very cheap or fairly priced product, but for growing or small businesses, it's quite expensive. These businesses would probably need to consider an enterprise services bus at some point. Thus, from a pricing point, it closes out non-cooperate businesses.

A slightly watered down version would be nice so that small, growing businesses could afford it.

We tried to use Oracle, and it just didn't do it for us. We explored MuleSoft, but it was a little bit expensive because of their pricing model, which is per transaction. So, it was also not a viable option for us.

You just need to find the right skills. In our country, we don't have people with qualified webMethods skills, so that's a problem for us in terms of resources. Depending on where you are from and if you don't deal with resource scarcity, webMethods could be a good option for you.

On a scale from one to ten, I would rate webMethods at eight. 

I am an integrator of the solution. Our use case is for integration factory for SAP. It is mostly for SAP integration.

The solution is deployed on-premise. We are one version 7.

I am not satisfied with the solution because it takes too much effort to migrate and add new information. The migration could be easier. There's a lot of rework that needs to be done if you go to a newer version.

I have been using this solution for one year.

The solution is stable.

For supporting the solution and installing things, we have maybe 10 or so users. We have no plans to increase usage.

The solution is scalable.

Before using webMethods, I used a different cloud data migration solution for other customers. 

It's a running system, so I haven't had any experience with the installations.

The pricing is a yearly license.

I would rate this solution 8 out of 10.

I would recommend this solution, but it is old fashioned.

While I do not recall exactly which version of webMethods.io Integration we are using, I believe it to be 10 or 12. 

We use the solution in respect of eight or nine integrations that we did with the different applications.

Oracle's self-service capabilities, of which we make extensive use, is the most valuable feature. 

The products, at the moment, are new and there should perhaps be support for the older version of the protocols. While I know that they have the new versions, which are actually needed, I don't believe they have that capacity when it comes to any integration with older systems. This is because I believe us to be more advanced nowadays, with what they are doing for the roadmap of new technologies.

The solution is very stable and we have had no issues with it thus far, two years running. 

The solution is, for sure, scalable and can go to containers and dockers. I believe this to be the plan for the moment. 

I found the technical support to be very good. Although we implemented during the pandemic, us being in need of the resources from a side KSA, we did not face any difficulty, as the resources are available locally. Also, we were able to do the implementation during the peak of the pandemic. 

We had a very good implementation engineer, so the deployment was very straightforward, nothing complex. Once the input and output signatures are aligned between the systems, everything is as it should be. 

The number of people needed for maintenance will vary with the features one is using. We use features which may require two to three people. The same holds true with implementation. 

While I have yet to calculate a return on investment, I have definitely seen one. Owing to the number of users, I would say that it is huge. This is because we have used it for self-services, something which is very productive. 

In the past, we dealt with paperwork, but we now use the solution to digitize everything. We use it as a platform towards the goal of digitization, which was the whole point of the project itself. 

In the past, we had Oracle ESP and we replaced that with Software AG. Contractually, it was Oracle ESB, at which point we got the change request to switch over to Softwares AG webMethods.

I feel the solution provides a very good platform for interconnectivity between the applications, beyond what most users have, which is point-to-point connectivity. This is a good platform for doing multipoint connections and allows one to use the APIs in multiple ways for a variety of purposes and services. It also has caching features, which greatly allows one to cache the data. It has so many caching mechanisms for speeding up the data towards the users. 

This saves the user from having to go to the backend to retrieve the data, as it is available on the ESB, something which is cached and can be released to the user. This saves time going to the backend. 

I rate webMethods.io Integration as a nine out of ten. 

We are using it to orchestrate and configure our APIs.

I believe we are using its latest version.

We needed a tool that was able to orchestrate and help us configure our APIs so that we could maintain and see the heartbeat, traffic, trends, etc.

A while ago, they were hacked, and it took them a very long time to open their website again in order to download any service packs or any features. I don't know what they could do differently. I know that they were vulnerable, and there was some downtime, but because they were down, we were unable to download any potential service packs.

I have been using this solution for about three years.

I would rate it an eight out of 10 in terms of stability and scalability.

We used Dollar Universe or Dollar U. It was more for batch scheduling. We didn't have anything for maintaining, configuring, or hosting our APIs. It was more of a manual process before that.

It is a little complex, but we're okay with that. MuleSoft is obviously the Cadillac and the best of the best, but we just didn't want to pay that sort of price for what MuleSoft can do.

We partnered with our implementation partner to do the install for us. 

Its maintenance is more of a shifting of duties. There are no new FTEs for it. It is just a shifting of duties.

I signed a three-year deal with them. It is a yearly locked-in price for the next three years.

I was the architect of it, and I wasn't personally the one who went deep into it. My advice would be to just partner with an implementation team and make sure that things are documented so that for upgrades, you're not married to them, and you don't have to use them all the time.

I would rate it an eight out of 10.

By linking apps and services, the webMethods Integration Server allows you to automate processes.

I like the stability of the webMethods Integration Server.

I would like to see the price improve.

I have been working with webMethods Integration Server for eight years.

We are currently using version 10. x.

webMethods Integration Server is quite stable, especially given the amount of load it has been handling.

webMethods Integration Server is a scalable solution.

In general, I contact technical support if we are experiencing any problems. They are extremely helpful.

Previously, I had not used another solution.

The installation is straightforward. It's easy.

It can take thirty minutes to deploy depending on the number of components.

It can be installed both on-premises and in the cloud. It has been migrated to the cloud, and we also use it on-premise.

You can complete the installation yourself.

I would like to see better pricing for the license.

We are researching cloud-based solutions, such as AWS and MuleSoft.

I am a user, so I'm not entirely familiar with everything this solution has to offer. I am utilizing one of the technologies that they provide.

Using this solution is dependant upon each area's perspective. I can't exactly say, if you had only one user that it's only for this solution or that solution, but it actually depends upon each other's perspectives.

WebMethods is the recommended solution if you want a stable integration, an ESB platform, and a B2B.

I am unfamiliar with cloud-based solutions or their environment. We are exploring their options and services.

I would rate webMethods Integration Server a nine out of ten.

The API Gateway and Portal go together. It's not one or the other. Essentially they're just leveraged for overall enterprise API management facilities, being able to go on the API development life cycle, being able to go on the API run time, API monetization, things like that. Usually, most organizations, most of our customers use APIs to supplement other architectures, typically microservices-based application architecture, and SaaS integration etc.

API Gateways and API Management in general first and foremost standardizes and democratizes the Integration problem across all IT domains. API Gateway specifically allows for centralizing all integration interfaces to a simple style and normalizes the patterns of security, access control, cross-domain compatibility across the enterprise. API Gateways also enable enterprise integration across various public cloud infrastructure and enable Hybrid nature of Enterprise IT.

On the API gateway, I would say the runtime metrics that the gateway collects are definitely useful.

The product provides a lot of insights into the operations of the API itself at runtime.

The cloud version of the solution is very easy to set up.

The stability has been good. The performance is strong.

The scalability is excellent overall.

We have found the technical support to be very helpful and responsive when we have questions.

In terms of improvements, maybe on the API monetization side, having users able to create separate API consumption plans and to be able to throttle API execution against those consumption plans at run time could be better. Those are abilities that might need some improvement.

The on-premises setup can get a little complex, needs to be more simplified.

I've been dealing with the solution over the last three or so years at this point.

The stability and performance are excellent. 3G really comes strong on an enterprise-scale in terms of stability and performance. It doesn't crash or freeze. There are no bugs or glitches. We find it to be reliable.

We have found that the solution scales quite well.

API management is all about internally leveraging the software development life cycle, across various domains. Typically, most customers, when they adopt API management, they are delivering it for their entire IT software development organization, not just the integration team. The application team and the database team and so on will also use it. Everybody will be on board. Sometimes we have seen customers onboard about 60, 70 developers and then maybe a few additional external consumers. However, we also see some customers with very small teams of around 10 people. It works well for both.

We've dealt with technical support in the past. There's always that possibility, especially with newer versions, that we might run into some technical issues. However, tech support and issue management are both pretty straightforward.

You can create tickets with the portal on Software AG through Software AG's support portal. They respond within 24 hours usually, and try to resolve the issue quickly. Sometimes the issues might need a product or a quote fix, which might take a day or two. Otherwise, they might be able to look through the knowledge base and give us a solution immediately. 

They have a pretty good response time and offer quality service. We're pretty satisfied with the level of support.

In terms of setting up the solution, the solution offers both cloud and on-premises options. The on-premise license and setup can be done yourself. That can be a little complex depending on what is the overall deployment architecture that is needed. 

However, webMethods API also comes in a cloud form, the webMethods.io, and that is just a subscription. Most of our customers can just subscribe to it and they don't really have to worry about the setup. Everything is already pre-set.

Typically, while the on-premises setup is somewhat complex, we don't really require people to be continuously monitoring it once it's launched. The setup itself might take less than a week or two, depending on the size. 

In terms of maintenance, unless there's a lot of APIs subsequently developed and running, you don't really have too much. Once the customer starts developing a lot of APIs and puts a lot of those APIs into production, that's what will contribute to the support and monitoring needs of the team. 

Typically one person can handle deployment and maintenance. Of course, the cloud doesn't really require the same amount of work.

The pricing can fluctuate. I don't have the numbers on hand, however, I can say that they're somewhere in the middle in terms of pricing. They aren't the most expensive or the cheapest. They're priced right for their capabilities and the quality of service as well as the stability and performance on offer. They're well priced for their general offering.

We are partners with Software AG. We've been a partner for more than 20 years now.

I'm a consultant. I work with a consulting company. 

I'm familiar with API Gateway, API Portal, and Active Transfer.

The API Portal and Gateway form the layer of API management, however, usually, API management does not go on its own. There's typically some level of an integration layer behind it as well. Either a customer is applying an API management layer on top of an existing integration layer, or, if not, a customer is starting fresh and has to apply both layers subsequently, or consecutively, kind of like creating an API management layer, and integration, a hybrid integration layer. 

Both go together, especially in data integration, or in application integration and cloud application integration.

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

The API Gateway and the Portal go together. It's not one or the other. Essentially they're just leveraged for overall enterprise API management facilities, being able to go on the API development life cycle, being able to go on the API run time, API monetization, things like that. Usually, most organizations, most of our customers use APIs to supplement other architectures, typically microservices, based application architecture, and so on.

On the portal, the user management and the API life cycle management are definitely robust. 

They have nominal features for API. They have a self-serve API portal as well. That means consumers for APIs can come onto the portal and learn about various APIs that they can put into the consumption model. 

The initial setup of the cloud version of the solution is very easy.

The solution can scale.

The product is quite stable.

Technical support is responsive and quite helpful.

We have found the pricing of the solution to be fair.

On the API monetization side, being able to create separate consumption plans and throttle all those consumption plans towards the run time. Those are abilities that might need some improvements.

The on-premises setup can be difficult.

I've been dealing with the solution over the last three or so years at least.

The stability and performance are definitely very good. 3G really comes strong on an enterprise-scale in terms of stability and performance. It doesn't crash or freeze. There are no bugs or glitches.

The solution can scale quite well. A company that needs to scale can do so.

API management is all about internally leveraging the software development life cycle, across various domains. Typically, most customers, when they adopt API management, they are delivering it for their entire IT software development organization, not just the integration team. The application team and the database team and so on will also use it. Everybody will be on board. Sometimes we have seen customers onboard about 60, 70 developers and then maybe a few additional external consumers. However, we also see some customers with very small teams of around 10 people. It works well for both.

We've dealt with technical support in the past. There's always that possibility, especially with newer versions, that we might run into some technical issues. However, tech support and issue management are both pretty straightforward. 

You can now create a ticket on an issue with the portal on Software AG through Software AG's support portal. They respond within a day, and at least try to resolve the issue. Sometimes the issues might need a product or a quote fix, which might take a day or two. Otherwise, they might be able to look through the knowledge base and give us a solution immediately. In general, they have a decent response time and a decent quality of service. We're satisfied. 

In terms of setting up the solution, there are two ways. The first is that you can have an on-premise license and set up this conference yourself. That can be a little complex depending on what is the overall deployment architecture that is needed. On the other side, webMethods API also comes in a cloud form, the webMethods.io, and that is just a subscription. Most of our customers can just subscribe to it and they don't really have to worry about the setup. Everything is already pre-set.

Usually, while the on-premises setup is fairly complex, we don't really require people to be continuously monitoring it once it's launched. The setup itself might take less than a week or two, depending on the size of the enrollment. In terms of maintenance, unless there's a lot of APIs subsequently developed and running, you don't really have too much. Once the customer starts developing a lot of APIs and puts a lot of those APIs into production, that's what will contribute to the support and monitoring needs of the team. Typically one person can handle deployment and maintenance. Of course, the cloud doesn't really require the same amount of work. 

The pricing fluctuates. I don't have the numbers with me, however, I can say that they're not the cheapest in the market, and they're not the most expensive either. They fall right in the middle, and they're priced right for their capabilities and the quality of service as well as the stability and performance on offer. They're well priced for their general offering.

We are partners with Software AG. We've been a partner for more than 20 years now.

I'm an IT consultant. We are a consulting company, most of my teams are certified in Software AG technology, and we've worked for a lot of customers leveraging that technology.

We typically deal with the most up-to-date versions of the solution, although occasionally, one or two might be a version behind.

A lot of the API Portal and Gateway form the layer of API management, however, usually, API management does not go on its own. There's typically some level of an integration layer behind it as well. Either a customer is applying an API management layer on top of an existing integration layer, or, if not, a customer is starting fresh and has to apply both layers subsequently, or consecutively. It's kind of like creating an API management layer, and a hybrid integration layer. Both go together, especially in data integration, or in application integration and cloud application integration.

Overall, I would rate the solution at a seven out of ten.

We're a healthcare technology organization and that space has a great deal of integration work, so we use webMethods to help us manage and develop integration solutions for various healthcare-related needs. Those include HL7 messages, the new interop messages, the new CMS directives for data blocking, Affordable Care Act integrations, and integrations with other health systems.

Our particular product is a SaaS, multi-tenant environment that's on-prem but moving to cloud. It is used by hundreds of healthcare providers to run their businesses.

webMethods provides application integration, data integration, business-to-business communications, APIs, and microservices. We use it for all of those purposes. Having that range of features in a single platform is very important, because that means we have a single platform to learn and use. It reduces training costs. It reduces overall infrastructure costs. It even makes hiring easier because we have one set of resources we need to hire for.

In a very fast moving space—which is weird to say about healthcare, but it has certainly become that in the last few years, and especially in the last year—the ability to move very quickly and to reuse components and to connect to almost anything have become pretty paramount. The solution’s adapters and connectors provide the fastest way to build an integration. The demand curve for integrations goes up daily, so our ability to perform and build integrations is a key core competency.

Because we use most of the platform, it's hard to call out a most valuable feature, but it's probably the ease of mapping which is the single largest feature. It gives us the ability to craft anything. A lot of single-purpose technologies, like Mirth, are good for healthcare messages, but we use webMethods not only for healthcare messages but for other business-related purposes, like integrations to Salesforce or integrations to Office 365. It's multi-purpose nature is very strong.

The ease of deploy and maintenance of integrations is a key element for us. If the strength is the mapping tool and the ability to change quickly, and having all of the components that we can then alter as we need to, the result is that it allows us to react very quickly to changing business demands. For example, we have a need to send the same types of data to many different integration partners, and because we're able to tailor the delivery to each endpoint, but use one master flow, it allows great economies of scale.

I'd like to see the admin portal for managing the integration server go up a level, to have more capabilities and to have a more modern web interface.

We've been using webMethods Integration Server for four or five years.

It has been very stable.

We find that it scales very well. It's a true enterprise tool.

Our usage will increase as our business grows. It's a core part of our infrastructure.

The tool is very good and we haven't really needed to engage with support enough to know if their support for the solution’s adapters and connectors brings long-term stability.

Support has been there in the couple of times we've needed them. We have gotten a fine response. They completely meet our expectations of support for an enterprise tool. But typically, there's no need for them.

We had a couple of competing platforms: Systems Integration from IBM, and MuleSoft in the open source world. We switched to webMethods for the support from the company and the range and depth of available adapters and connectors. It gave us more capabilities.

We used an integration partner to help us stand it up, so the setup didn't really impact us. We had a total of two or three people involved on our side. We used The Normandy Group and our experience with them was very positive.

It took us about three months to have the first integration running. The implementation strategy was 

• install tool
• get it to work
• build first integration.

Those same two people in our organization are the ones involved in the day-to-day maintenance of Integration Server. We have two webMethods technical resources who are responsible for about 400 integration points or integration services.

We have seen return on investment from using it. We have to compute that every year, and the value is always greater than the cost. It's just that every year it gets harder to justify that value against the competitors. 

Keeping in mind that we haven't explored the microservices completely, which has been a key element of their innovation recently, I do think webMethods is coming under increasing pressure when it comes to their price-to-feature value proposition. It's probably the single biggest strategic risk they have. They're very expensive in their industry. They've been raising the price recently, especially when compared with their competitors.

I'm familiar with Mirth, in the healthcare space, and IBM SI is still a very large tool. Various other IBM platforms that will do similar things. The space has gotten more crowded over the years.

The single biggest differences between webMethods and the other solutions are the range of the offering, the connectors, the stability of the system, the fact that it is an enterprise-grade system, and that you can basically do anything you need with it. 

The con is the fact that you are paying for the best-of-breed solution in the space, and the expense of it can be quite high. When you couple that with the fact that adding Software AG services increases the cost very fast, there is a real detriment to our adding additional Software AG offerings to the portfolio. The sheer expense makes us reluctant to do that. It's still justifying its cost for us, currently, but I feel that there are open source solutions that are charging up very fast. Also, finding resources who are trained in the tool is becoming increasingly hard as they become increasingly more in-demand.

It's a very valuable and a very powerful tool, but it's a tool that you have to dedicate resources to, to learn and to use well. Use an integration partner to help get it stood up and in use in your organization faster. That is something that is very valuable. And then dedicate staff to learn it. This isn't one more tool in the toolbox. This has to become someone's toolbox.

The comprehensiveness and depth of its connectors to packaged apps and custom apps is fairly low, but its ability to build what you need is very high. The value of the tool is the Lego block nature of it, so instead of being framed into set paths, we can build what we need.

I would rate it at seven out of 10. The cost-to-feature value is what brings that number down. The difficulty in finding webMethods-trained resources in North America also brings that number down. The powerful, scalable, stable nature of the offering brings that number up.

We use it for everything. Three years or four years ago our company was bought. In our original company we used it for EDI, although that has pretty much gone away since the purchase. We do use it for EDI, but we use it for more free EAI, enterprise application integration. It allows us to have plant software talk to SAP. It allows us to interface with external parties through their MFT (managed file transfer) product called Active Transfer. We use it to connect all kinds of systems.

Also, in a company that's big, there are always acquisitions, and before the acquisition can be fully integrated there is always the challenge of getting data in and out of that acquisition. We use webMethods for that too, because we can either use internal network or external network.

It's hosted in Azure, on VMs.

Its adapters and connectors absolutely provide the fastest way to build an integration. An example of the effect of that speed of integration on our business is that when our company was acquired, the acquiring company didn't have webMethods and wasn't interested in it. We were able to build interfaces quickly and show that they didn't need constant babysitting. For example, you can build frameworks. We had built an error-handling framework that can notify people with meaningful error messages when they happen. It never crashes. It always tells people what happened. We were able to build solutions much faster than with the other tools.

Process orchestration is another benefit. Driving towards an event-driven architecture, and not a batch-oriented architecture—which introduces all kinds of time delays and doesn't give a true picture of the end-to-end process—we've used webMethods Designer to design process models that can orchestrate a process from beginning to end. For example, we can get data via SFTP, trigger an event in webMethods to process the data, and load it into a third-party data warehouse database such as Snowflake, which is a new up-and-comer. We can then trigger other processes to move that data and process it in Snowflake. We get responses back and, at the end, we can consume the processed data and send it to a different endpoint. All of that is orchestrated by webMethods. Process orchestration is a very strong point of the solution.

Modifying and troubleshooting are very easy. They have a nice debugging app interface. It's faster than anything else that we've ever used. For example, when we were acquired, we had to keep our legacy SAP system, which was still functioning for the legacy company, synchronized with the acquiring company's SAP system. This was a very complicated task and we were able to do it very quickly using webMethods Integration Server.

We use Active Transfer quite a bit. It's very convenient because it is integrated with Integration Server. That means you can deploy an event-driven architecture, based on SFTP, which most people can't pull off. Most of the time, with SFTP, there is file polling and it's not an event-driven architecture. But webMethods' solution allows you to plug into their integration server and have a totally end-to-end event-driven architecture.

The comprehensiveness and depth of Integration Servers' connectors to packaged apps and custom apps is unlimited. They have a connector for everything. If they don't, you can build it yourself. Or oftentimes, if there is value for other customers as well, you can talk with webMethods about creating a new adapter for you. That's particularly true of their cloud-based webMethods.io and their hybrid cloud solution. It's an on-prem plugin called CloudStreams. That allows you to connect your on-prem services with cloud-based things. The number-one example that everyone always gets is Salesforce.

That depth of comprehensiveness is similarly true for the solution’s connectors to SaaS apps, IoT devices, and legacy applications. That is the number-one strong point of webMethods. It can connect to anything. There are so many out-of-the-box connectors for SaaS things. There are JDBC adapters, SAP adapters. They have pretty much unlimited connectivity, or you can build it through their toolkits.

It provides a single hybrid-integration platform for all our needs.

Deploying is something we have found to be lacking with native webMethods tools, as is the ability to plug into a change management system, so we built our own deployment system. But again, we built it with webMethods' foundation tools and then interfaced with sub-version, version control, and our own home-built change management system. We used it to enforce that things can't go to prod unless they pass the QA stage and have had successful QA acceptance testing.

It would be nice if they had a change management system offering. We built our own deployer application because the one built into webMethods couldn't enforce change management rules. Integration into a change management system, along with the version control system, would be a good offering; it's something that they're lacking.

I've been using webMethods Integration Server for 20 years.

Overall, it's very incredibly stable. I've never seen any other software platform that can run for so long without crashing. We've had servers run for over a year, and we have restarted them not because they were broken but because we were installing something. We've had servers run for over a year.

In terms of support for the solution’s adapters and connectors and long-term stability for your services or integrations, you build once and forget it. 

Scalability is another strong point. It's very scalable. It's very easy to stand up parallel machines, and add them to a cluster. We have two machine clusters because another strong point is that we've built everything in high-availability. We have two of everything; everything is clustered. But if we all of a sudden acquired 50 more companies, and had all kinds of additional business, we would just stand up a couple of more servers in the cluster, they would inherit the same exact code, and it would be simple very simple to scale.

It's used for all our North America integrations. It runs the gamut of a little bit of EDI, a lot of EAI, and some MFT. Anything where one system needs to talk to another system, and trade data, we use WebMethods for that.

We are always building new things in it. There are always new projects. 

We don't need a lot of vendor support. You get the platform and you get some people that know how to use it and you really don't need much support from the vendor. However, when we do need support, they do have a good support portal and we do get support from their personnel pretty quickly. Our experience with their support has been good, for the most part. Once in a while we get people who aren't quite as good. I would rate it at eight out of 10.

We did not have a previous solution.

When it comes to upgrades, 20 years ago, it was very hard. Ten years ago, it was hard. Today, it's fairly straightforward. They've gotten much better at their upgrades.

As for how long an upgrade takes, there are many factors involved. We had a struggle with our infrastructure team just getting us the vanilla boxes and Azure. Once you have your boxes in a network so that they can talk to each other, the installation of WebMethods is fairly simple. 

Then there comes the complexity of importing your old code into it. And the hardest task of all is testing everything to make sure it still works. But the upgrades are pretty simple, they have apps that help out with that, and they work pretty well.

The upgrade we're doing right now has four people involved. I am the architect, and the other roles are developer/testers.

Day-to-day maintenance is almost zero. If there is a need for some maintenance, we have two people, me and another, who take care of system maintenance. But really, it's stand-it-up-and-forget-it. You do have to do certain things. webMethods is not in charge of your user databases. So if they fill up with data, and you haven't built in something to automatically purge them every so often, that's on you, not on webMethods. But as long as you have built in these types of maintenance routines, and schedule them, everything is pretty trouble-free.

I wish our company measured ROI. We're slowly getting there. 

But webMethods Integration Server just saves time, especially development time. We can implement solutions that save repetitive user-time, often. Often, if a group comes to us and says, "Fred is spending two hours a day doing this stupid task where he's just uploading into a spreadsheet, and downloading here; can you help?" We can turn that type of thing around so fast, and eliminate Fred's two hours per day.

Pricing is the number-one downfall. It's too expensive. They could make more money by dropping the price in half and getting more customers. It's the best product there is, but it's too expensive. It could be 10 out of 10 if they dropped the price. There are so many people who don't use it because it's so expensive.

It also provides application integration, data integration, business-to-business communications, APIs, and microservices. That range of features is very important because we can do anything with it. We tried Informatica, for example, which was portrayed as being an equal, and it wasn't. It can't do everything and then you have to go out to other products and combine them. webMethods can truly do everything within the webMethods environment. And you don't have to buy add-on products. In reality, a lot of the webMethods' plugins are add-on products that were acquired at some point. But they do pretty well when it comes to integrating their acquisitions into the main ecosystem.

The scope of abilities in Informatica is very limited. The scope of abilities for webMethods is pretty much unlimited.

We have also looked at SnapLogic, and again, it just doesn't have the breadth of abilities that webMethods does.

The biggest lesson I've learned from using it is to never build a one-off. Always think "reusability." Everything in webMethods is reusable. Even if you think you will never use it again, and you build it hastily, without error-handling, you will get burned. Always build for reusability.

You should definitely build a couple of little reusable frameworks too. The first reusable framework I would build would be an error-handling framework. Once you build that, you add those service calls to every service you ever build. In that way, once things error, you always know. It knows how to send an email to the right people, it knows how to send a meaningful error message that someone can read and see what happened. Building a meaningful error-handling framework upfront will save you so much time when things break and people ask "How do we fix it?" It will also proactively let people know things errored out, instead of reactively. We also built a deployment framework. That's a little above and beyond. The webMethods' tools are not terrible in that regard, it just doesn't talk to a change management system.

Everything you build in webMethods is a microservice. It's been that way for 20 years. So even though the term wasn't coined back then, you can expose any service in webMethods to any other system you choose. Call it an API, call it a microservice, but it's all just built-in and it's already there.

They are focusing on their cloud offerings, as is everybody else, because everyone wants to go that way. Sometimes it's just for the sake of saying, "I have a cloud offering," but theirs seems to be pretty solid. Their cloud offering is webMethods.io. However, I haven't used that extensively. That'll be coming up this year. There is also a hybrid thing called CloudStreams and that is for on-prem webMethods, which is what we have, but it has canned connectors to SaaS solutions like Salesforce, whereas webMethods.io is entirely in the cloud. You would use that to connect one SaaS to another SaaS.

In terms of the solution's support for the latest standards making it possible to plug into modern tooling and third-party products, we've found no need. It's a pretty complete solution, unlike other solutions. And you really don't need to plug anything else into it.

We have an open banking initiative in Indonesia. We are mandated by a regulator's bank in Indonesia to open up our services to other institutions, not only banks, but also financial technology (FinTech) companies and startups as well as eCommerce or other industries.
Thereby, they can consume banking services through an API, such as our funds transfers, mobile banking services, or a bill payment, like electricity, water bills, college, and so on, through an API to their applications. It is not obligatory that you need to download our mobile banking in order to do these transactions, but you can do the transaction using other applications, such as the FinTech or eCommerce application that the customer currently has. Those use cases, for the open banking readiness for Indonesia, utilize webMethods API Gateway and standardized services of API for fund transfer, debit credit transfer, bill payments, and opening up a savings account using online applications. Those are pretty much the use cases for webMethods API Gateway in order for us to connect it with FinTech startups, eCommerce, and other institutions who would like to consume banking transactions through Mandiri.

Since we are a very highly regulated industry, which is a bank in Indonesia, we are not allowed to host any financial transaction outside of the Indonesian region. So, the solution must be deployed on-premise inside of our data center.

Are you using multiple products from this vendor?

We are using multiple products to build the end state of our service-oriented architecture (SOA). This is all orchestrated as a big building house. Those SOAs have many capabilities inside of them on the integration side, such as webMethods Integration Server. (Read my webMethods Integration Server review here.) There is also webMethods API Gateway and Software AG Apama. Those modules inside of Software AG complement the building blocks of SOA.

We also use it to complement other products in the markets outside Software AG, such as Kafka as well as all event processing and streaming. This is in combination with the capabilities (and beyond) of what Software AG stacks can do.

I find the native integrations between Software AG products to be very useful from a plain vanilla standpoint. Though, when we implement native integrations, there needs to be slight customizations to fit them into our core legacy system, and that needs to be integrated with other systems. For plain vanilla capabilities, it is sufficient enough.

The native integrations between Software AG products also have good performance in terms of transactions per second (TPS). These are acceptable in terms of the volume and speediness of a transaction that we can produce as well as being combined with the efficiency of using the hardware, memory, and CPUs.

If you combine the commodity hardware and performance as well as the plain vanilla capabilities of internal products that Software AG has, then there is a good price per value.

It gives you a one-stop service for your integrations area. You can really rely on one vendor, then you don't have to worry about sustainability or support. This is all guaranteed by Software AG as a single stop service from them. Whereas, when you need to combine other vendors, then you need to monitor each of their solutions, sustainability, product roadmaps, etc. Then, this becomes your technology liabilities, which is something that we consider. From the integration, we are selecting a good strategic partnership with one vendor in order to maximize our productivity. Thus, we don't have to worry how we can monitor each respective vendor if we do a best of breed combination of many vendors, just to do an integration.

By selecting Software AG and using multiple products, this saved us about 72 percent, which has definitely given us more agility.

Because we were already accustomed with webMethods Integration Server way before the webMethods API Gateway, they were almost the same. We just converted our knowledge from the prior WSDL into RESTful JSON standard messages. Therefore, the learning curve was very smooth because the environment that the developers use was still the same: My webMethods Console. It uses the IDEs coming from that, saving us a lot of time with the learning curve on new technologies.

Within the new version, webMethods API Gateway gives us an end-to-end lifecycle from the creation of the API up into the development, deployment, and promotion into production/live. The current end-to-end lifecycle of the API gives us enough authority and governance of the API. We know what are currently live services, what is in the testing stage of development, and what version that has been commissioned. So, the full life cycle itself gives us full authority and governance of the API.

You can carefully select what services can be consumed by the outside and what services can only be consumed internally. Also, you can see what the fallback scenario is, if some services are customized and what is the impact analysis, e.g., what is the impact to other services that depends on certain services that we are currently automizing. These are very critical capabilities for API implementation in any organization. You do need to have good API governance for it, not only tools, but also all the procedurals. You will need all the standard operating procedures for starting a development of API up to deployment into production.

webMethods API Gateway provides an engagement platform for managing hackathons. Our last hackathon was in 2019. We developed several services in the cloud using a sandbox environment, so it does not connect with our real life production environment. We created some accumulated transaction behavior, so hackathon developers could connect it with our box services within the sandbox environments. It does provide good freedom to host competition in an isolated environment.

At Mandiri, we divided webMethods API Gateway into two layers, the external API gateway and the internal API gateway. The external API gateway is for Mandiri channels and our core partner channel for feedback, eCommerce, and other institutions. With their channel, they like to connect and consume services. webMethods API Gateway gives you a sense of security and quite adequate minimum security to secure services, e.g., DDoS attacks, man-in-the-middle attacks, and queries for SQL injection. These are already built inside of webMethods API Gateway. 

It has a good role definition and scope for its services. Expected channels can only access what type of services, and we can define those as per our contract with prospective partners. So, it boils down to the architecture: How do you like to architect the integration and partnering with other institutions? It depends on that. However, the system itself gives you that flexibility.

webMethods API Gateway gives us a set of rules and good security for securing outside work to connect with our services. It has good minimum security measurements built-in. However, webMethods API Gateway itself has very minimum API governance. You need to have a central site in place to have full-fledged governance, which is one of their modules.

The solution provides a fully customizable portal that has built-in testing and collaboration capabilities. Because it is similar with other well-known products in the market, the process doesn't have specific requirements. We do have a good adoption rate. We only have two weeks of learning and customizing the behavior to developers. By the third week, every developer can actually develop by themselves.

Previously, we had some difficulties with end-to-end lifecycle management of APIs because the product was not yet mature enough. Two years ago, it was not yet mature in terms of the capabilities, which were still separated and not yet consolidated. There were several modules of webMethods API Gateway which needed to be consolidated into one webMethods API Gateway. Previously, they had two separate modules for API management as well as others. 

One of the improvements that need to be added into future releases is the ability to support other third-party monitoring tools. I know that they already support Jenkins, but in Mandiri. We use Bamboo for the deployment as well as part of Jenkins. We also install other monitoring tools, such as AppDynamics, for collecting information on performance and the problems of API Gateway hosting services. 

With performance, there is room for improvement in regards to if we would like to put another extra layer of security on it, such as SSL. This is affecting their performance quite significantly. They need to improve the process of managing the SSL and other things inside their solutions, so there will not be quite such a significant impact to the performance.

With their API-Portal, you need to have flexibility when changing the layout and teams, giving more flexibility to rearrange and do some type of UX/UI that fits into your organization. The API-Portal that comes from Software AG has some of those limitations, with only certain parts that can be fully customized.

We have used it for almost three years, since 2017.

How do you get money from selling or offering your financial services to the other partners or institutions? It comes down to monetization. How do you monitor usage of certain particular protection or usage of services? I do see a lack of capabilities inside of the monetization area for them. They have a cloud infrastructure that is pay per use type of a thing. If you already use 1,000 transactions per se, then you can be charged and billed. I see room for improvement there for their side on that particular capability of the monetization.

We have evaluated other solutions, such as Apigee and MuleSoft, back in 2016. but since we already have Enterprise Service Bus that is using the integration server, which is collecting and managing all the integration services inside, we wanted to see the end-to-end picture of the service itself. It was very logical that you need to have end-to-end monitoring and trend deployment from the service deployment, up into exposing the external world using webMethods API Gateway. We see those advantages from using webMethods compared with other solutions, such as Apigee or MuleSoft, because of the continuation of the architecture. We would also like to expand those into our separating stacks.

In every implementation of webMethods API Gateway, I strongly suggest that you need good API governance. webMethods has their API governance all built inside of your license. It is a continuation between the services using the webMethods Integration Server and webMethods API Gateway, exposing those services into the outside world. You need to have good governance for that.

I would rate this solution an eight (out of 10).