webMethods.io Reviews

We have a lot of use cases for this product. Initially, when we bought this product from Software AG, it was only for a specific project. But, we did watch for other opportunities where it could be used for integration and that's what happened.

Our business model has many verticals, so it's used across the enterprise. The main function is to provide application integration within the company. We have more than 60 applications and at the moment, it's talking to more than 30 applications and integrating them. In this context, it is used by our sales team and in a lot of automations.

Our second use case is to provide Write as a Service. We write any custom service using webMethods and then expose it to others as a REST service.

Another thing that we use this solution for is managed file transfers.

We have this solution deployed in a hybrid environment. It is available in our private cloud, where it is installed in AWS, and we also have it in our data center.

This solution has improved our productivity and efficiency in pretty much all of our applications. There are some currently-running automation projects where we are going to have to transform data and at the moment, it is being done manually. This is another case where we will implement webMethods to improve productivity.

We automate our sales cycle using API orchestrations. When sales come through, for example, we register them and enroll them in the policy. All of this is done within webMethods and it works well.

With respect to the comprehensiveness and depth of connectors that are available, they have a lot of traditional ones available. They are constantly adding new ones, which is good to see. However, what we found is that we can develop them very easily. Nowadays, pretty much everything is REST so it is easy to develop your own. We do not have a license for many of the connectors. One of them that we have is Salesforce, which was what we had originally envisioned.

Then, what happened when we needed another connector is that we reasoned that rather than buying additional ones, we would instead create our own. Ultimately, we found that it was quite easy to do and in my experience, it is always better to use your own because the out-of-the-box connections have limitations. This is what we found with the connector for SuccessFactors; we were better off building our own because there are no constraints when we do it that way.

This solution encompasses a range of features, which is important to us. We use it heavily for application integration and APIs, somewhat less for data integration, business to business communication, and we are trialing microservices. Although we do not yet heavily use the microservices feature, we do like that it provides it.

We plan to expand our usage of microservices because, in the AWS world, we want to make things auto-scalable. This is what we are playing around with and although we do not yet have it in production, the plan is to use it more.

Modifying and redeploying integrations is easy to do. This has made us more agile and the fact that we can churn things quicker has helped the business.

There are a few things about this product that we definitely like. It is very robust. If you build it nicely, you can't go wrong with it. It's rock solid.

The development is very fast. If you know what you're doing, you can develop something very easily and very fast.

For the latest services, the product is lacking in terms of connectors. For example, there are a lot of SaaS providers and if you look for the connectors out-of-the-box, they are definitely not going to be there. They have a lot of traditional options but they are basic. If you have an advanced use case then you are better to build your own.

For the most part, this solution supports the latest standards and makes it possible to plug in modern tooling and third-party products for automation and innovation. However, there are some things that it doesn't support and we find ourselves having to wait for a newer version. For example, when we were using version 9.10, it did not support OAuth.

In general, I would like to see the vendor release newer features sooner. Or, it would be helpful if we can use a newer feature but don't have to upgrade the entire product.

The UI for the admin console is very old. It hasn't been updated for years and is pretty much the same one that we started with. This is something that could be refreshed and made more modern.

We have been using the webMethods Integration Server for almost six years.

I would rate the stability very high. Once it is running, it's very stable.

The webMethods Integration Server is a tier-one application and if it's down, impacts pretty much everything. When it runs, no one knows about it but if it goes down, everyone screams. It is very crucial.

With our current licensing, it's very easy for us to scale. With our older licensing model, it was very hard. This is definitely something that I would highlight. I'm very happy with our current setup because we can scale and it's more of a constraint of your commercials rather than a product constraint when it comes to scalability.

We purchased a premium support package but to this point, we have not greatly depended upon it. In our day-to-day business, we haven't had to deal with them very often, which is a good thing. We generally resolve things within our team and don't generally need to rely on others. There are only a few issues that we have contacted technical support about, such as when we were having issues with the upgrade. Also, if there is something that we can't find then we will contact them.

In general, when I compare their support with other vendors, I would not rate them high. The customer experience with support is an area that needs improvement. The reason I say this is that regardless of the issue you raise, even if it is not necessary, they ask a lot of questions.  

Prior to webMethods, we were not using an integration solution. We were a .NET shop and we were using it to accomplish the same tasks. However, it was not to the full extent that webMethods is doing because its capabilities are less.

The reason we adopted webMethods is that a new project was coming and when we estimated the cost, we found that developing everything in .NET was cumbersome. At that point, we started to look for a tool and settled on webMethods.

We chose webMethods over MuleSoft because of how quick and easy it is for developing. It is simple and easy to use. The commercials is definitely another reason that we chose it. This was the product that was recommended after the technical evaluation was complete.

We also use webMethods.io, although that does not fall under Integration Server.

The initial setup is of medium complexity, although it depends on your scenario. If you have a simple use case to just integrate, it's easy. The actual installation is very straightforward but we had some complexity because of the zones.

We had multiple DMZ zones and we have a PCI zone. This meant that there were a lot of firewall rules that needed to be created. It was a greenfield project, so we had to build everything in addition to the webMethods aspect. The project was definitely complex. However, the webMethods setup in isolation was very straightforward. If you just focused on, "Okay, this is the one that you have to install." It's straightforward. If you know what you're doing, it's easy.

Upgrading is something that we can't do in a very fast manner. It's not like we are going to upgrade every six months. We have to wait a while. On the other hand, that's where the microservices architecture is good because anytime something new is released, we can upgrade to the latest.

We completed the initial setup in-house.

We evaluated MuleSoft and webMethods. There may have been others but these were the top choices. When we asked for demonstrations, these were the products that we looked at.

This product provides us with a single hybrid-integration platform for all of our integration needs. We do have another product but it is for a very specific use case, and it is separate because of the licensing. Otherwise, webMethods is our go-to for integration.

On the topic of development time, this product can save you time but it depends on what you're comparing it to. For example, if you are comparing it to having no platform, where all of the integrations have to be developed from scratch, then this product will definitely save you a lot of time. The undertaking would be massive. If instead, you are comparing it to another product such as MultSoft, then it will be a different answer. It is tricky to estimate because it depends on the tool.

This is a product that the vendor keeps adding things to. Sometimes, we have to wait until the next version comes out before there is support for what we want to do, but there hasn't been anything major.

My advice for anyone who is implementing this solution is to spend some time thinking about how it will be used. I have seen instances where the product was being used and didn't work properly. If it is designed nicely then it will work wonders, so spend some time thinking about the design and how it will be used and it's never going to have any issues.

I would rate this solution 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.

By Software AG, we are also using Integration Server, Trading Networks, Active Transfer, Optimize for Infrastructure, My webMethods, and their EDI package. As long as there is product parity between products, it makes sense to continue using multiple products from the same vendor. Obviously, you want to make sure you have a diverse portfolio. Where those products start breaking those links, you want to make sure that you are using the best product for your company in this region.

The fact that we were already using another solution from this vendor affected our decision to go with this particular product, mainly from a cost standpoint. As is any product in this region, the biggest cost is almost always the upfront cost of laying out the solution. Also, there are some costs in having that solution already available: between knowledge of the platform, having the licensing rights, and if you bring in a new solution, then you are now paying for two solutions.

The native integrations between the vendors' products are very seamless. The products interact very well. At times, it's kind of hard to tell where one product ends and the next one starts. As new products come in, the integrations probably take one or two updates before they are fully integrated. However, once products are fully integrated, it is very seamless and easy to hop between one product to another.

Using multiple products from the same vendor creates efficiencies:

1. In terms of knowledge. Obviously, there is a familiarity with the product and how you expect Software AG's products to act and respond. 
2. In terms of operational understanding between end users who are looking for specific data. They know how these products work and how to pull up these reports. 
3. In terms of having administrators overseeing these products.

There is a cost savings for using many of the same products. There are lower training costs. Also, typically, there are a lot of integrations that you ended up needing to build out, whether they be custom or out-of-the-box. Even if they are out-of-the-box, a lot of times that takes a lot of work to get those to work. However, since we are using Software AG products, it's very much like installing a plugin into an Excel program.

There was a reduction in the learning curve because we had already used the vendors' products. The products used work very similarly. In terms of verbiage, key aspects, or three-letter acronyms, you don't have to relearn any of those. There is an expectation of how these products will work. These products always work the same way when Software AG is rolling these types of products out.

We use webMethods Integration Server for two main aspects: 

1. For application-to-application integrations.
2. B2B: The transferring of on-premise data out to other business partners.

As with any integration platform, it is a single pane of glass that allows you to see and interact with transactions as they are flowing. Out-of-the-box, Software AG offers robust monitoring solutions to help you understand if a solution's up or down transactions aren't working, etc. The tool has been invaluable to our organization in terms of understanding where our data is, how it's flowing, and its current status.

Having a single hybrid-integration platform for all our needs is very important. From an IT perspective, it is a way for us to easily troubleshoot and quickly resolve issues. From a business perspective, it's very important because IT is readily available to assist with any system issues which are happening at that time. Anytime that you have applications talking to each other, it is a breeding ground for problems and issues. Having a solution like webMethods Integration Server in place can empower your IT department to be able to resolve issues and roll out solutions quickly as new applications come into your portfolio.

We have been on webMethods Integration Server for 15 years. We just got rid of our mainframe. It works wonders with our mainframe. With SaaS and cloud applications, webMethods Integration Server does not answer this need by itself. This is where you would be looking for APIs or custom plugins to work with those types of solutions. 

It is very open. It is extremely rare for us to find something that we are trying to integrate, but we can't integrate it. In the past seven years, I don't think that has ever happened. For any problem that we are looking at, the Software AG solution can solve. That has probably been the most valuable feature.

Application integrations are offered out-of-the-box, and that is extremely important to us. This is one of the main use cases that we have for it. It is about 60 to 70 percent of the workload in our application today.

Integration platform as a service (iPaaS) is probably the future and direction that many companies and organizations are looking at. Software AG is also rolling out robust solutions for this. So, if I was a brand new customer, that is where I would be looking. This is also the direction that I think Software AG is moving into along with almost every vendor in the industry. However, the integration platform, as it currently sits, runs really well. It's very robust and does what you would expect it to do.

My organization moved onto the webMethods platform 15 years ago. I have been using it for the past seven years.

Software AG is a partner who has been around for many years. The company is not going anywhere. Regarding the solution, you can get the capabilities that you need out of it.  It is a known solution that works really well and does exactly what you would expect it to do.

Software AG's full support for the solution’s adapters and connectors brings long-term stability to our services and integrations. Software AG has many SMEs in each region, both globally and in each product type. Being able to have access to a subject-matter expert in the specific tool or region that I'm looking for is invaluable. I feel like I am talking to someone who has hands-on experience in either developing the solution or has many years of experience with the product or similar customers. They also have people who just work in specific business groups. For example, if I'm looking for a knowledge worker to do something with IoT, then they have people ready who can answer specific questions about products that we might be looking to integrate with.

The solution is very scalable. If you want more webMethod Integration Servers, it is very easy to spin them up. It's very easy to apply packages to each one of those solutions. Or, if you want to just have one large webMethods Integration Server, it is easy to create the configuration settings to allow that JVM to have more memory.

There are less than 20 users. A solution like this is normally a back-end solution. Obviously, we have administrators who are overseeing the product to make sure it's up, patched, available, and secure. Developers who are rolling out new solutions and debugging any issues going on in production or lower environments. Then, the third group is probably the business users. That is a very small hand full of users at our company. Those users are typically looking just to make sure that the data is flowing as they would expect. For example, I expect a certain file to go out to this customer every day. That business user has access to log into the application and pull that file.

The product is used extensively at my organization. Out of all our integrations, it probably counts for 60 to 70 percent. Every minute of every day, it's being used. I think the usage that we have in place today is correct. If we were to expand any further, we would probably be looking at iPaaS solutions.

Their technical support is very good. I have never had any issues with the support or getting the resources that I need.

Two months ago, Software AG did have a data breach, so their support desk got shut down. It has been down since then, and that has not been a pleasant experience. Prior to that, it was a pleasant experience. I think Software AG has been reeling from that, but there are ways to get a hold of their support desk. This ensures that their customers still have access to support, which has been available and out there. However, they did have a public exposure, which has ended up causing some loopholes for their customers.

Upgrades are complex. They typically take about five months from start to finish. There are many packages that plug into webMethods Integration Server, which is the central point for a vast majority of the transactions at my organization. Anytime we are upgrading that, there are complexities within each component that we must understand. That makes any upgrade very cumbersome and complicated. That has been my experience at this company. Because there are many different business units that we are touching, there are so many different components that we are touching. The amount of READMEs that you have to go through takes some time.

This is where we would need to look at an iPaaS solution or moving to work with microservices solutions. Obviously, the smaller you make the solution, the more you're able to in an agile fashion.

From a high-level implementation strategy, we do a waterfall approach. That is the approach that we have ended up following for upgrading this solution.

Deploying solutions is very easy. The biggest thing that any company has to look at, because we have had a couple of pitfalls in this, is you have to look at how you're rolling your solution out. So, if you end up stacking or creating common services in the solution, those solutions become very tricky as they start to age, as any development cycle would end up having. The smaller you create the solution, the easier it is to keep rolling out those solutions, and staying away from common services really allows you to continue to roll out with ease.

As new solutions roll out or there is a different way for these apps to integrate, it has been fairly easy for developers to make the modified changes needed. The biggest thing is always knowledge because there have been some integrations that haven't been touched for 15 years. Then, if someone needs to touch one of those integrations, there is a learning curve in understanding how that integration works and what they are looking at.

Having a product like this is invaluable to any company in terms of the amount of time that IT gets to save in terms of integrating different products as well as having an open way to ensure that these applications are working. If you were to do this out of the box for each one of those solutions, while the upfront costs would be cheaper, the long-term stability of your applications would definitely degrade. As you are rolling this out for products that probably run your business, that's probably not a direction that any long-term company would want to go. I know my organization has seen time savings from not going with in-house built integrations from app to app.

For the B2B, we are probably saving somewhere between five to 10 full-time resources who would be working on this manually. For application-to-application, it probably has cut down 50 percent of our downtimes at a minimum. When you're talking about application-to-application integration, that is the thing that you would probably end up using as a key metric. For the amount of downtime that we have, I would double the amount or length of downtime that we would have if we didn't have this solution.

Currently, the licensing solution for this product is pretty straightforward. The way that Software AG has moved in their licensing agreements is very understandable. It is very easy for you to see where things land. Like most vendors today, they are transaction based. Therefore, just having a good understanding of how many transactions that you are doing a year would be very wise. Luckily, there are opportunities to work with the vendor to get a good understanding of how many transactions you have and what is the right limit for you to fall under.

With any solution like this, on day one you have a project that you're trying to work on, but just understand where you are trying to go with the solution. Some plugins are cheaper than others, and others are more expensive than others. Just make sure that you understand the full scope of what you might end up using the product for, so you can understand the all-in costs.

The tool works extremely well. Software AG offers packaged solutions for many packaged apps. Oracle SQL Server or Salesforce are add-ons that you can purchase and install easily for plug and play with packaged solutions. When you start moving into custom applications, there are no packaged solutions. The good news is that typically custom apps are built in some type of known technology, and that technology can easily be integrated into webMethods Integration Servers.

Business-to-business communications is an add-on that needs to be purchased. While super important to my organization, it is an add-on outside of the standard webMethods Integration Server. I would strongly recommend the business-to-business add-ons, especially if you're looking to use webMethods Integration Server in that capacity. It just makes the development cycles a lot shorter as well as making it much easier to manage your business profiles.

We routinely evaluate other options. I wasn't here when we made the decision to move onto this solution, but we periodically reassessed the platform to see if we are still sitting on the best solution that is matched to our corporation.

Today, there are many newer solutions out in the marketplace, and Software AG does offer those solutions. That is a great start. If I was starting over, I might look at those alternative solutions. However, if you are an alternative solution to webMethods Integration Server (not Software AG), then I would probably be looking a lot more into the cloud. webMethods Integration Server is used in a very legacy way. For example, we are on premise with data centers, which are legacy ways to solve a problem. If my solutions were in the cloud, then I would probably be looking at webMethods Integration Cloud as Software AG offers it, or any of the other vendors, like MuleSoft. So, you have to look at:

• What am I trying to integrate today? 
• Where are those solutions sitting? 
• If everything is on-prem and you are a 110-year-old company with 50 plants across the place, then probably having an on-prem is the right solution.
• If you are an eCommerce shop, then you are probably looking more in the cloud and for a cloud solution.

The solution pays for itself, but it is complicated as it stands today. Make sure that you are using it for exactly what you have architected it for. Don't try to fit a square peg into a round hole.

We have been moving away from data integration for webMethods Integration Server. So, it's becoming less of a priority for us.

Software AG has been moving in the direction of trying to make their tool as modern as possible. It has plugins for Docker today as well as ways to integrate into webMethods Integration Cloud. While these integrations are available, we don't use them.

I would rate webMethods Integration Server as a seven (out of 10). For what the solution can do, it does it extremely well. The upgrades are very cumbersome; they are very long and disruptive. You have to do them at least every three years. It's not a fun time for any company. If upgrades were a 100 times easier, it would get a much higher score.

Our use case is our service-oriented architecture transformation which started in 2017. It has been a three-year journey. Before that, between 2007 and 2017, we had not conducted a re-architecting of the SOA. In 2017, we had a big initiative for digital transformation at the bank to make ourselves more flexible, more agile, and competitive with all the startups and the financial industry in general, not only in Indonesia but also in other regions.

One of the critical capabilities included the integration area. That is why, in 2017, we re-architected the SOA to have layered architecture that is related closely to microservices. We are testing a new mobile banking channel to use a micro services architecture as well.

The integration use cases for webMethods involve connecting all of the back-end core systems at the bank so that they use the SOA integration server layer. Everything must go through this layer to speak or communicate with the back-end systems, such as the core banking, HR systems, and the treasury system; all the core systems that sit behind the ESB layer of the Integration Server. All the front-end systems like mobile banking, sales management, the CRM, etc., must go through this ESB layer, the integration server, to communicate with the back-end system. That is the prime use case of Integration Server.

Other than that, we successfully launched a new initiative for API about a year ago. We are commoditizing our financial services to not only be consumed by our channels, but by partners such as startups, FinTechs, InsureTechs, and other companies that would like to partner with us and use our financial services APIs.

When it comes to commoditizing for external parties, the partners, the other banks, or financial institutions that are our subsidiaries, they can connect to it and consume our services through the API Gateway products that we are providing to them. That includes sandboxing to test their applications. If they would like to partner with us, they need to register themselves and make an agreement with the bank regarding what sort of packages and fees that will be applied for the cooperation.

It's deployed on-prem. We are a banking institution. In Asia, regulators for the financial industry prohibit us from hosting financial transactions outside the Indonesian region.

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. There is also webMethods API Gateway and Software AG Apama. (Read my webMethods API Gateway review here.) 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.

One of the improvements is that everything is currently standardized. Previously, each system had its own connection to the core and back-end systems, a point-to-point connection. It created havoc for governance of the integration itself. There were so many connections without any governance whatsoever as to how the communication happened.;

There is also an improvement on our development side. When we have requests for new business requirements, products, business processes, and integrations with partners, Integration Server has dramatically decreased our development time. That's because we have standardized all the communications to the core system in one place.

In addition, we have improved availability of the channel itself.

It definitely gives us flexibility. The first stage, with these products, is the learning and customization. Once these are underway and things run, the performance is meeting our expectations. And when new requirements arise it becomes easier and development speeds up. For each integration service, the development cycle has come down from seven days to three days, maximum. And that's for the complex integrations. We have cut the development cycle by almost 50 percent.

Modifying and redeploying integrations is very easy. It gives us a good, stable, comprehensive, end-to-end development cycle, from development to deployment. It gives us a set of tools for checking the consistency and integrity of the code, which is something we didn't have with previous solutions. When deploying to the production server, it also does validation checking, whether certain libraries are missing, for example. It helps us do consistency checks. Because of that, we have cut down the system integration testing significantly. The user acceptance testing has also been reduced significantly. The reduction in testing time is almost 50 percent, compared to our previous solution. We used to test for five days and now it's just two days of testing for each of the services.

The vendor’s full support for the solution’s adapters and connectors has helped with uptime and availability. We are close to 24/7. And the number of transactions per second, previously, was around 600 to 700. Now, it has almost doubled. We are reaching more than 1,000 TPS. We have more than 2 million transactions. It has given us that type of scalability.

The solution has helped us contribute more to the business, to the expansion of the products and the volume of transactions.

There are three features of Integration Server that are the most valuable. One is the webMethods Designer. That helps our developers develop on their own. It's very intuitive for design. It helps our developers to speed the development of services for the integrations.

The second feature is the reliability. Mandiri Bank is the largest bank in Indonesia. That translates it into a humongous volume of transactions that flow down from the channels and go through the Integration Server, and then to the core banking itself. The components of Integration Server need to have 99.999 availability. It needs to be reliable all the time, available, and to be a scalable platform.

The third of the highlights of the features of Integration Server is the small footprint for infrastructure. It can run on any commodity hardware, unlike other solutions that need to run on specific hardware. It gives us the freedom to scale the platforms and create the greatest possible agility for the organization to expand, based on the demands. The other side effect of that is the additional advantage of transforming the architecture that we currently use into more of a microservices base. It gives us more flexibility and agility, going forward.

We would like to achieve a multi-site, soft data center. Multi-site meaning that we would like to have more than two Active-Active data centers because Indonesia is a big region with three time zones. We would like to have many data centers serve us across the islands to support the massive number of transactions. We need to have a good amount of availability. Hence, we would like to have a multi-site data center. To support that, the solution needs to be capable of Active-Active implementations, an Active-Active integration server. We would like to get to the point where transactions are not only coming into one data center but, simultaneously, could be redirected to several other data center sites. Integration Server needs the capabilities to help us to achieve that goal.

Also, the solution has big instances when deployed under microservices or in a containerized platform. They need to improve that so that it is competitive with other integration solutions, like Redis and Kafka. Deployments under microservices with those solutions are much more lightweight, in the size of the runtime itself, compared with Software AG. They need to improve it to be scalable enough and lightweight enough to run on the microservices/containerized platform.

We are paying them a lot so we have access to their product development engineers. We are waiting for them to revamp the microservices areas. We are waiting for the new version of that. They have come back to us with something that is much more lightweight, but to us, it has still not reached the lightweight level that we want.

We have several products from Software AG. The product is the SOA webMethods Enterprise Service Bus. We have been using that since 2007. The second, and one of the largest, is the API Gateway. Other products include Apama Complex Event Processing and Event Stream Processing engine. Those are the three main products we are currently using as part of the service oriented architecture building-blocks at Bank Mandiri.

Given that we have been using it all these years, you can imagine the stability of the system.

We experienced major issues at the beginning of the implementation when the product was still kind of new. But over the years they improved a lot. 

They keep producing new versions at a rate that we cannot keep up with. That is a problem for us because they have a very small set of supported versions. That is a downside of their products. Old versions are supported for a very limited time. They keep telling  us, "You need to upgrade." But we do an upgrade and they introduce a new version and the one we updated to is already obsolete. Their life cycle is very short.

It can run on commodity hardware, so it is scalable using commodity hardware, like Intel processors of any brand, as long they run on the Linux operating system. They can do a clusterized environment and scale easily when transaction volume is bigger than we expect. It can actually scale on demand, and it's easy to set up by joining a new cluster into an existing cluster. It performs well in this case.

We have 60,000 to 70,000 employees at the bank. About 10,000 people are using the services we create with the solution. They are mostly in the transaction back office and they monitor the day-to-day transactions from the channels. They monitor our mobile banking, trade, finance, and treasury transactions, as well as wealth management, corporate payments, and cash management. It's typically the wholesale, retail, and the micro-banking staff who heavily use this integration. For the back office, the upper-level user is a department head, while the junior level is staff that does the monitoring, day in and day out.

When we have issues that we have not encountered, we have access to their support teams. They need to have support which is close to the Asian region. Because of the time zones there are limitations on how they respond to our support. 

They do provide us with local partners that help us more quickly. There are several severity levels of support. For level-one they provide us with good partners in Indonesia.

Since we do the transformations, we do the initial setup from the bare metal server up to the setting up of the Integration Server. We can pretty much do that ourselves, with their guides. The first time, we needed to be guided by their engineers. The setup is fairly easy, but for optimal speed and performance, we definitely reach out to their support to evaluate the configurations that we have deployed.

When we installed the new version it took two or three days, depending on how many nodes we configured. Now, it takes a maximum of one day to establish a setup for normal configurations. For the complex ones, that have many nodes or Active-Active sites, it can take three or four days.

We have one engineer for Software AG, another on the network team, and another on the server team.

For the monitoring of day-to-day operations, we have support from our internal developers. We have deployed six or seven people because this is a huge implementation of Integration Server. They cover three shifts so that we have 24/7 monitoring, using the management console. We accompany that with third-party tools that help us to monitor the performance.

We have been using the solution's adapters and connectors for our new architecture on the integration inside of Integration Server, but with help. The product is a plain vanilla platform. You can do pretty much everything, but to exploit its capabilities, you need to use their consulting to help develop and utilize them. Those capabilities are something that our internal developer was not familiar with, so we needed to engage with the Software AG engineers to help us build those adapters. The built-in adapters do not suffice because they need customization to be implemented. Each organization has its own business processes and logic that differ from one to the next. It is good as a plain vanilla, but if you want to customize it further and exploit the capabilities, you need to have their engineers working closely with you to implement and utilize all of the capabilities. 

Our back-end is a legacy system that uses a different language, so we needed to customize it. The solution helped reduce the amount of work because at least the features were already there, but it needed the customization of the engineers from Software AG in conjunction with our internal developers as the experts in our core system. Combine forces and you create your own adapters.

Integration Server provides application integration, data integration, business-to-business communications, APIs, and microservices. Regarding the data adapters, we are not using their products for data integrations. The data integration space has come into the data warehouse area, and we are using other tools to do data integration. But for the transaction APIs, business processes, we are using built-in products from webMethods.

That range of features comes back to the use cases that apply to the business innovations that a business would like to implement, such as real-time transactions, asynchronous transactions, fire-and-forget. I'm sure the transactions will be successfully processed by our core systems, and that is the main goal. The other features go towards how we can enrich things, but that is a second priority. 

The tool helps us to streamline data integration. Its BPM is very strong and powerful. The solution helps us manage digital transformation. 

webMethods.io needs to incorporate ChatGPT to enhance user experience. It can offer a customized user experience. 

I have been working with the product for ten years. 

The solution is stable.

webMethods.io is scalable. 

webMethods.io's technical support is amazing. They have different mediums for communication, such as chatbots, emails, and phones. The response is based on the incident severity. They respond in a day even if the incident is of low severity. 

Positive

I have used IBM Message Broker and Apache. The product is much easier, and you do not need to have extensive knowledge. 

webMethods.io's deployment is not difficult and can be completed in a few hours. 

The tool is worth its money. 

webMethods.io is expensive. We have multiple components, and you need to pay for each of them. 

The product incorporates different layers of security, ranging from denial-of-service protection to IP denial and other features aimed at enhancing security. Given the importance of safeguarding information from exposure and unauthorized access, maintaining strong security measures is our key priority.

The solution focuses on low-code and zero-code approaches. This means users don't need extensive technical expertise. Instead, they can use drag-and-drop functionality.  I rate it an eight out of ten. 

We use the solution for application-to-application integration and B2B integration.

The synchronous and asynchronous messaging system the solution provides is very good.

Other products have been using AI and cloud enhancements, but webMethods Integration Server is still lagging in that key area. It's very good as a standalone integration server, but it has to come up with more features in the cloud.

The solution's API management is slightly lagging, and its API policies could be improved.

I have been using webMethods Integration Server for 13 years.

I rate the solution a six out of ten for stability.

I rate the solution a seven out of ten for scalability.

The solution's initial setup is easy for an experienced person, but a new person may find it difficult to set up everything. There are too many features and components. The setup could be easier if the solution could merge everything in one suit.

The solution’s pricing is too high.

The solution has impacted our system's scalability and ability because it is quite good and pretty fast.

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

We use the solution in the API gateway services. 

I like the tool's scalability. 

webMethods.io Integration's installation is complex. It should also improve integration and connectors. 

I have been working with the solution for more than ten years. 

The tool's support is good. 

Positive

I have used Apigee before webMethods.io Integration. 

The installation took about four to six weeks to complete. You don't need a big team to handle the deployment. We relied on one system architect to handle it. The tool's maintenance is also not difficult. 

webMethods.io Integration's pricing is high and has yearly subscription costs.  

This solution suits enterprises and I would rate it an eight out of ten.