webMethods.io Reviews

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. 

This solution is primarily used for protecting our APIs and web services. All of our APIs are exposed to the outside world, so our internal network is protected by the API gateway. Our landscape inside the company is also divided into different domains and if you go from one domain to another domain, we also want the APIs to be protected.

We have two servers with an API gateway and a load balancer in front of it.

We also use this solution for monitoring, to know how many transactions we have had and who is using our API. These are the runtime capabilities.

Another thing we use this product for is governance, to govern the lifecycle of our API services. It will tell us the state of the service, who is responsible for it, and what deliverables belong to that stage, and we also have some quality checkpoints inside the lifecycle.

With respect to the end-to-end lifecycle management of APIs, this product is very good, feature-wise. We have the ability to govern the end-to-end lifecycle; in the different states, we can do the necessary customization and add our own flavor. This helps us maintain it very well.

The API governance capabilities for enforcing standards and security policies are quite good. However, it is a new product that started a few years ago, and you can sometimes tell that it is new and still evolving. For example, there are some bugs and problems that are still being fixed as it is further developed. They are evolving the features and we are happy with the product, but there can be more issues that arise as things change.

These quality checkpoints allow us to have a central team that reviews the deliverables of the service. In the Design phase, for instance, we will review the REST API interface to see if it matches our standards.

This solution has enabled us to create new channels for growth because we can quickly introduce new APIs. Sometimes, you need to quickly set up a marketing campaign with an application that needs to happen fast. The API gateway allows us to introduce APIs that are still good and protected but in a fast way.

We have a good overview of all of our APIs, including who is providing them and who consuming them, which allows us to better work together to resolve issues before they emerge. For example, if there are changes made, we have a better view of the impact and the team can start discussing it. Also, if we are deprecating services and removing them, we know who is using these APIs and they can be contacted in advance.

Another important point is that when a new application wants to use an API, it can provide the necessary information such as the number of transactions. With this knowledge, the provider can adapt accordingly and it will be possible to add it.

Using the product has provided us with a structured API management program. Because we have governance and knowledge about all of the APIs, we have a better overview. Knowing who is using an API, or who is going to use it, means that it is easier to introduce new things.

This solution has given us a competitive advantage because we have better automation and insight. Without it, a lot of automation would not be possible, and doing it manually would take more time.

More generally, this API gateway has improved the way our organization functions because it allows us to enable more partner integrations. Until now, most of our business-to-business integrations were going over EDI. With API instead, it will allow us to onboard other partners. The reason for this is that EDI is a very heavy format, which is very expensive. As a retail company, EDI is affordable when you have a large vendor. But sometimes we have smaller vendors, and if we force them to use EDI, it will sometimes block the ability to sell products to us because they can't afford the complete functionality of sending invoices or receiving orders.

What we are now doing with API management is to make the order and invoicing systems available via API. These smaller vendors can then use these APIs to send an invoice or to receive an order.

The two most important features are the lifecycle and the protection of your APIs.

On the topic of protecting your APIs, every API management solution has that, which is the core business. Without it, you don't have an API gateway and it's the basic setup that every API management solution needs. Of course, protecting your APIs is very important.

With respect to the lifecycle, it is helpful because, in our business, we find it important to have an overview of all of our APIs and to guide our different roles, including architects and solution developers, in the necessary work for delivering a web service. Depending on the type of service, we also want to govern the quality. We don't do it for all APIs but for some categories, we find it very important that the quality is at a high level. This means that we want to govern that and review it.

In these aspects, this solution helps us.

In relation to the lifecycle features, the user interface and the performance can be improved. It is not the quickest application and the user interface is not the most up-to-date. It's a tool that has existed for quite some time, and there haven't been a lot of improvements.

With respect to the API gateway, the runtime component, and the stability after a new release is something that can be improved.

I have been working with the webMethods API Gateway for approximately five years.

Once the system is set up and configured properly, it's stable. We don't have outages and it runs very well.

There are two ways to scale this product, and both of them are easy to do. The first is to add another server to your cluster, and the second way is to add more CPU power.

I would rate the technical support medium-high. It is comparable with other companies; not worse, but not especially better.

In general, I am happy with the support but my complaints are about the timing. Specifically, if your issue can be handled by the first line then you get feedback quickly. However, if the issue is complex then it needs to go to R&D and it takes time. This is the same experience that I have with other companies.

Positive

We did not use another similar solution prior to this one.

The installation and initial setup are complex. It is not possible to just keep clicking the Next button during the setup. You need to configure the system such that it works best for your environment. You should plan for deployment over three to six months, at least.

My advice is to involve a consultant from Software AG to help you with the setup. Of course, this is an on-premises situation. In the cloud, I don't know how easy or difficult it is.

We have seen ROI from this product and we are able to determine this because of our internal accounting. When a project starts, we always calculate what our benefits are with respect to the technology. Taking into account the number of web services and APIs that we have, we're pretty sure that considering the cost of governance, this solution is better than if we were not using one.

This is not a cheap solution but, compared to other products such as those offered by IBM, the pricing is similar.

We did evaluate other options including IBM API Connect and Apigee. Feature-wise, these products are comparable.

Given that we were already using webMethods, using the API gateway had some benefits. There is value in staying with a single vendor, with the advantage that it is easier to integrate with other products in the webMethods stack.

We did not consider using any open-source alternatives.

This solution provides a fully customizable portal that has built-in testing capabilities, although we haven't implemented it yet. This is something that we are planning to do within the next couple of months.

My advice for anybody who is implementing this product is to involve consultants who are familiar with it because they can help you to best set it up. Also, think about the process and steps in your governance because this is a workflow and you want to be sure that it follows the procedures that you have in place.

Overall, I'm happy with the product.

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

The tool helps with the integration between multiple entities at the same time.

webMethods Integration Server needs to add more adapters. 

The product is very stable. 

webMethods Integration Server is scalable. We use it daily. 

webMethods Integration Server's setup was straightforward. The tool's deployment took one to two hours to complete. 

I would rate webMethods Integration Server an eight 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. 

We use the solution for logistic purposes.

The solution's most valuable feature is its ability to integrate with various servers.

The solution could be more user-friendly. They should include proper documentation for easy understanding.

We have ten solution users in our company. It has good scalability. We plan to increase its usage.

The solution's customer service is good. We have support access. Thus, we write to them for the service request in case of any issues.

The complexity of the solution's initial setup process depends on the environment and specific project requirements.

We purchase a yearly basis license for the solution. I rate its pricing an eight. It is not that expensive. The price depends on the use cases, support, and resources for implementation.

It is a good solution. Also, it is easy to use compared to other integration solutions like Azure, SAP, etc. It has the highest resolution and is more secure as well. I rate it a nine.

The primary use case of the solution is for our digital sale tool.

I really appreciate the form and application that indicate the API. 

The performance is good.

I would like the solution to provide bi-weekly updates.

I have been using the solution for seven years.

The solution is sustainable and stable.

The solution is on the cloud therefore it is scalable.

I give the solution an eight out of ten.

I recommend the solution to others.

Most of our customers are real estate development companies, and they build many projects in Saudi Arabia. Most of their projects are about Smart Cities or Smart destinations. The use case was about integrating different Smart City technologies and enterprise applications. For government services, the use case was integrating webMethods.io Integration into different government systems serving residents. For example, the Ministry of Interior uses the solution for passport and ID services, so different government systems are integrated.

We used webMethods.io Integration as an integration platform. It accommodates Enterprise Service Bus, integration server and API gateway. We took the complete platform and the integration server as part of the platform to integrate or receive data from the API gateways, integrated with the Enterprise Service Bus.

The solution allowed us to integrate applications and IoT devices because it has an IoT event processing layer. It provides a flexible integration within the IoT systems because most of the applications we work with are related to the IoT and Smart City technologies. So, there's hardware, software and application integration, providing hosting flexibility.

Some platform providers host their applications in Amazon AWS or Microsoft Azure, which sometimes creates challenges for data governance because of regulations.

Any solution needs continuous development in integration and processing.

We used the solution for more than a year for different projects. We used the latest version and stopped using it four months ago. It was deployed on private cloud in the customer cloud infrastructure.

The solution is stable. If there were any minor problems, we resolved them.

It can be scaled up and support multi-tenancy. However, it is difficult to maintain.

I rate the technical support a six out of ten.

The initial setup was straightforward.

They don't have a fixed price, and the pricing model is transaction-based. I rate the pricing a seven out of ten, with one being the worst and ten being the best.

I rate this solution a seven out of ten. I recommend it, but it depends on the use case. I do not see any gaps with the platform.

We use it mainly for policy implementation and securitization when we're exposed outside the internet.

They should develop clear visibility for the onboarding. They could also improve the clustering.

We have been using this solution for three years.

it is a stable solution.

It is scalable and can adapt to third-party integration. We have more than 500 users.

I've worked with MuleSoft, and webMethods API Gateway is the most stabilized tool with a robust integration server. It's a good tool, and it has a stable messaging broker. In addition, from the infra point of view, it is always compliant and not complex. You can integrate everything with webMethods API Gateway.

The initial setup was straightforward and not complex. I rate the setup an eight out of ten.

I do not have details about the pricing. However, it is cheaper than APG.

I rate this solution an eight out of ten.

Our primary use case for webMethods Integration Server is for our internal application integration. We use it to expose REST and SOAP web services and to connect it with SAP.

We also use it as a bridge to transform web service calls. We'll use an ESB if we want to transform the protocol or the message. It's also used to connect our internal custom-written Java applications with products like SAP, which don't have an open standards interface.

We only use it on-premise. We are considering going to a hybrid setup but at the moment, we don't have it yet. Nevertheless, we still use the Integration Server to integrate our cloud applications. We only have cloud on-premise integrations and not cloud-to-cloud. That is also why we're not focusing on a hybrid setup.

Integration Server does our business-to-business integrations. It does all of our EDI integrations of passing over our Integration Server and our LAN connects to our internal applications.

Its adapters and connectors provide the fastest way to build an integration. We don't need to create our own implementations because we can use the adapters. We can immediately connect to the backend systems without creating a lot of our own custom code by using these adapters.

The vendor's full support for Integration Server's adapters and connectors brings long-term stability to our services because if something changes to the backend application, we don't need to bother with it. Software AG just adapts the adapter and we get a new version. It's much easier working this way.

Deploying a new application is rather easy. You need a deployer and to build a system. We have built something around it to add it to our continuous integration pipeline, but we have the necessary tools to test our production environments.

We use the same system to modify or redeploy these integrations. If we have a bug we'll adapt our codes and deploy a new version. The code changes need the most time. If it's a small code change, then it goes very quickly. If it's an important bug, it'll take more time. The deployment and build don't take a lot of time.

It's a visual tool, so our transformations can be quickly implemented without a lot of fuss. The fact that we have an easy way to expose REST services is also very interesting. It offers the possibility to connect over GMS to synchronize message brokers.

Using an adapter is quite easy. For example, the SAP adapter works very well, and connecting to custom applications is very easy.

We would use MQTT when we need to connect to IoT devices. For the other legacy apps, in most cases, we use the adapters. Acquiring an adapter is quite easy.

Integration Server provides us with application integration, data integration, business-to-business communications, APIs, and microservices. Internally we don't use it for data integration, but it is possible. We don't work with microservices but I know that it's also possible.

It is important to us that Integration Server offers us a broad range of features like application, data integration, and API. It's important to have that kind of broad setup because it's a service burst. It's in the middle of a lot of integrations. It has to be able to have a lot of features

In terms of improvement, it would be better if it adapted quicker to open standards. It took a while for API specification before the last version was available. The spec of version two was rather quick. 

With an integration platform, it sometimes needs to happen faster because you sometimes have clients or providers that already use new specifications.

I have been using webMethods Integration Server since 2011. 

I am very satisfied with stability. It's very stable, we haven't had any issues at all.

We had a lot of issues with our other solution but none with Integration Server.

There are many scalability options, it is possible to add core CPUs to your server or you can add additional servers. Both are possible, both are not complex. The only thing that you need to take into account is then the licensing, but there are no technical issues for scalability.

Technical support is okay. It's comparable with other companies. It of course depends on the kind of issue that you have, but I'm rather satisfied with their support.

We were using IBM before webMethods. We used a combination of the two. When we started we had both webMethods Integration Server only for B2B. We used WebSphere Enterprise Service Bus for internal application integration. It's easier to have only one. That is the reason that we chose one of both. The second reason was also that IBM was deprecating their product and asking to switch to another one. Instead of going through IBM, we figured we could do everything with webMethods which is why we completely switched over.

webMethods had a very good overview of all transactions. That was the main reason we went with them.

The initial setup was of medium complexity. It's new so you need to learn it. A tool like this is never easy. webMethods Integration Server was easier than a different solution that we were using. But it's not a walk in the park. You need to spend time on it. There are configuration settings that can't be avoided. It's a complex feature set. We have had more complex systems also in our landscape. It's not just "click, click, click, done."

I was not involved in the initial deployment. But I know that they upgraded to webMethods Integration Server in a month. It took a few months to learn everything in the system.

We worked with a consultant for the deployment. We worked with a consultant from Software AG which went well. We have also worked with other consultants from consultancy companies that were not directly linked to Software AG but work with a lot of Software AG products. They helped us to set up our webMethods products.

I don't think webMethods is the cheapest but I think the quality is worth it. But it's not cheap.

We're satisfied with our choice and the price is not a reason to look for something else.

It's wise to work with a consultant when you introduce Integration Server because you need to learn about the product. It's better to have advice from someone who already has experience with it.

I would rate webMethods Integration Server an eight out of ten. I'm quite happy and satisfied with it but nothing is perfect.