webMethods.io Reviews

Clients choose webMethods.io API for its intuitive interface, promoting seamless interaction and quick communication between systems. The platform's focus on rapid deployment expedites time-to-market, while robust governance features ensure control and compliance. Particularly appealing to less mature clients in API management, it offers a strategic toolset for gradual integration advancement, providing both immediate benefits and a pathway for long-term growth.

A potential drawback of webMethods.io API is its adaptability to legacy systems, which can vary in compatibility. This becomes evident when dealing with diverse products within a client's portfolio, requiring significant time and resources for API integration. The challenge lies in the need for a robust team and cost optimization to bridge the gap between legacy systems and modern API standards. Additionally, the time and effort involved in transforming products into API-ready formats can be a limiting factor. While the platform offers comprehensive solutions, addressing these challenges requires careful consideration and a modular approach for optimal results.

I have been working with webMethods.io API for a year.

webMethods.io API is stable, but its maturity may not meet all customer expectations due to the challenges of dealing with large legacy systems. Achieving optimal results takes time and gradual refinement as the platform evolves to address these considerations. I would rate the stability as a seven out of ten.

Scalability is webMethods.io API's strong point. The solution is designed to scale seamlessly, offering flexibility from small to medium and up to enterprise-level clients.

The tech support from webMethods is solid, and I would rate it at nine out of ten.

Positive

The installation of webMethods.io API is flexible, offering options for both on-premise and cloud deployment. The customer has the capability to choose either based on their preferences and security requirements. However, a crucial condition for product ownership is having your own cloud infrastructure. Without this, selling the solution may face challenges due to country-specific regulations. It is not just a customer requirement but a regulatory necessity to align with the country's guidelines. The deployment time for webMethods.io API varies based on the scope. For upgrades, it typically takes six to eight months, while total implementations can range from 12 to 18 months. The number of engineers and architects needed depends on factors like chosen modules, domains, and the scale of customer service, ranging from thousands to millions. Once deployed, maintenance is relatively easy.

The solution is on the expensive side in terms of pricing. It follows a yearly licensing model. Clients typically pay for the license only if they have the internal capacity for implementation. However, for a more comprehensive approach, clients often opt for additional services, including implementation, maintenance, and support from the vendor's side, especially when the scale of the project requires a more hands-on approach.

Before choosing webMethods, it is crucial to assess your organization's skill set. The solution is powerful and scalable, especially for large enterprises, but smaller businesses might find it challenging both in terms of cost and resource availability. It is a robust choice for those with substantial needs and the capability to leverage its features effectively. Understanding your organization's scale and capabilities is key to making the most of what webMethods has to offer. Overall, I would rate webMethods.io API as a nine out of ten.

We use ActiveTransfer to call internal APIs and transfer files from a third party to the cloud for application purposes and from a third party to on-prem. We also send files to the third party sometimes. We have a payments system and transfer files across the system to make customer domains.

We have on-prem, cloud, and hybrid deployments and transfer files across all of them. We're working with webMethods cloud, AWS, and Azure. Our eight-member team is using webMethods MFT and other integrations, and we have a shared team to work on multi-technologies, like web issues, Snowflake, webMethods MFTs, etc. 

ActiveTransfer lets us maintain the file in the staging area before we transfer it. After that, we can remove the file to make sure that the reconciliation process is done. Sometimes we will zip and unzip the files, but if we have a GKB file, we often ignore it. 

Some things could be improved, especially how ActiveTransfer handles third-party file transfers. It would be nice to have a native file-watching mechanism for when you're scheduling jobs with a third-party scheduler. 

Currently, we are using an outside file watcher solution to check the files before the file transfer. It checks the location to see if the file is there. If the file is there, it will prepare it for transfer. If the file isn't available, it will send an email it can create a ticket send it now. We recommended adding this file watcher mechanism. 

Also, when we're dealing with massive files, ActiveTransfer requires huge amounts of RAM, but if would be helpful if we could customize the compression and encryption to squeeze that data and reduce the size to save on system resources.

We have been using ActiveTransfer for six or seven years.

ActiveTransfer is stable.

ActiveTransfer is easy to scale and use also, which is why we recommend it. We have a script-based file transfer, but we use it less compared to MFT.

webMethods' technical support is excellent. When we have issues with third parties, networks, corrupted files, etc. we send the logs and they take care of it.

The difference between webMethods and Control-M is that Control-M schedules automation tools and checks to see if the file is there. Our team is currently using Control-M. 

If you use MFT and you've cleared the MFT events, it has to schedule through Control-M because all the jobs running through the solution end to end. Control-M has an AMF advance remain file transfer, where you can create a source and target profile.

Setting up ActiveTransfer is straightforward. I rate it eight out of 10 for ease of setup. As for maintenance, we have a monitoring mechanism in place and an automated process for large-scale transfer. If the current available space at the target is less than 30 percent, we have an alert.

We do it all in-house based on the customer's request. We'll keep all the files in the staging for one week. If necessary, we will remove it or move it to some other location. This kind of housekeeping and maintenance we do.

I'm not aware of the exact cost. That product team at my company is responsible when we need any maintenance, new products, upgrades, etc. 

I rate webMethods ActiveTransfer eight out of 10. They only need to improve a few minor things to bring it to the current market standard. My recommendation to webMethods is to add more flexibility to the file-watching mechanism to reduce the load on the RAM and CPU to a minimum, which will help when we are dealing with large numbers of massive files, especially in the retail environment.

We used to deal with millions of small files. When you are dealing with these kinds of files, you need to ensure that there is an internal reconciliation process. When you're reading and transferring thousands of files, you use a parallel instead of sequential mechanism to ensure all the files reach a target and that the reconciliation process is done automatically.

The webMethods API Gateway is utilized to assist our banking clients in integrating with the bank via the API.

The solution has helped improve our organization by recommending APIs and providing easy-to-use security controls. Additionally, it identifies similarities between multiple cases, thereby avoiding redundant code and implementation.

The developer portal is a valuable feature.

The gateway server itself can improve the message queue implementation by considering the top ten web security controls.

I would like to request the integration of response caching into the memory database, which would eliminate the need to construct logic within the API itself, and instead implement it directly in the gateway.

The price has room for improvement.

I have been using webMethods API Gateway for a couple of years.

I give webMethods API Gateway a ten out of ten for stability.

I give webMethods API Gateway a seven out of ten for scalability. We can scale the solution, but it is a bit complicated since it is not saved in a Microsoft architecture, which would make scaling much simpler.

We previously used Open API and Google Apigee but our organization technically and commercially preferred to go with webMethods API Gateway.

I give the initial setup a seven out of ten. The deployment took a couple of weeks. The deployment required one solution architect and two technical consultants.

The implementation was completed by Software AG.

The price is high and I give it a five out of ten.

I give webMethods API Gateway a seven out of ten.

We currently have 40 people and four developers using webMethods API Gateway.

We plan to increase our usage tenfold within the next few years.

I would advise a POC to see if there is a business case. I suggest starting small and scaling out as required.

Today, we work with many financial organizations worldwide, and sometimes they have Legacy software, so we use webMethods Integration Server in those cases. 

We are not resellers, but we provide solutions to large financial institutions, and sometimes we have to work with a lot of legacy software. Sometimes we have webMethods Integration Server as part of the stack. Sometimes we do consulting, and sometimes we take ownership of parts of the projects that large financial institutions have.

webMethods Integration Server is very similar to every integration product in the world, and in the past, we used to write point-to-point connectors with the concept of ESB. We used hub and spoke architectures, and webMethods Integration Server would be used in that context.

Usually, the way large enterprises work is they acquire different licenses over time, so we check their internal IT asset management software in terms of their licenses. If they already have a webMethods Integration Server license, we use that as part of our solution.

Otherwise, we would make recommendations to them on what to acquire in the open market. If the solution is cloud-based, we recommend that they use cloud-based ESB software to integrate different components of their solution. We choose different software pieces, put them together, and ensure that they add value on top of the integration headaches that come when you work with enterprise software.

webMethods Integration Server benefited our organization. If it didn't, then we would not be using it.

What I like best about webMethods Integration Server is its portfolio of connectors. Every integration product has different components to interact with SAP, Salesforce CRM, etc. My organization includes the type of connectors a product has, apart from license availability, usage, and so on, as the criteria for choosing or recommending a solution.

In terms of the feature set, any integration software you use will have to connect different components of enterprise software. Depending on the enterprise software a financial institution, such as a bank, will be using, my company first checks the available connectors in the product, product maturity, and what other solutions can be integrated with the product before making a recommendation to either reuse the product if you currently have a license for it, or purchase a license if you don't have the license yet.

For example, when an enterprise invests in SAP or Salesforce CRM software, that investment is very significant. When you need a form of interaction to exchange data, that's when you use an integration product, so I'm saying that the actual value of integration software, such as webMethods Integration Server, is its ability to connect with other enterprise software.

webMethods Integration Server is no longer that popular because the market has started moving towards cloud-based ESB solutions from Azure, AWS, and other vendors, so this is one area for improvement.

As I mentioned, the real value for any enterprise integration software, especially a proprietary platform such as webMethods Integration Server, will be in the number, quality, and stability of the connectors it has. That is the most critical aspect of every ESB product in the world. Sometimes, what happens is in case a particular connector is not available between a proprietary component within a bank or a financial institution. My organization would have to develop the software components, so what would be ideal is if there was a core set of software that's open source, which would make it easy for third-party vendors and individuals to build components to fill in the gap. This is what I would recommend.

The market webMethods Integration Server falls under is a very crowded market, so for the product to stand out, Software AG would need to get traction in the open source community by releasing a new version or a base version and open source it, so people can create new custom components and add it to the portfolio.

I would recommend looking at Apache ServiceMix or Apache Camel, ESB products, or enterprise software products for integration and looking into the open-source mechanism. MuleSoft is another example, as it has an open-source base version and an enterprise version sold to enterprises. Mulesoft has many open-source components but allows third-party vendors and ISPs to create custom components for customers.

This is the feature set I would suggest for webMethods Integration Server because it's what the product needs to survive in the integration space. Otherwise, other solutions, such as Apache Camel, will take over the world.

I've used the webMethods Integration Server on and off for a long time. The product has been around for quite a bit. I evaluated it once my friend sent me a copy of it a long time back and made me a beta tester for the product. I've used it on and off.

webMethods Integration Server has been around for quite some time, so it's a very stable solution. It's much more stable compared to newer entrants in the market.

For software to be stable, it has to be deployed. It has to be created, developed, tested, and deployed in production. Then, it'll be patched and versioned across multiple years, so the more versions a solution has, the more bugs have been removed in the core system, making it much more stable than newer competitors. Again, this is a case-to-case basis, but you can generally use this as a rule of thumb. The longer the software has been there, the more stable it is.

This is why the backend payment systems are written in COBOL in almost every top financial organization or bank you walk into. Even though COBOL is practically a dead language, it's very stable because it's been in production, and it's been tested, verified, and used; plus, its bugs have been fixed over a long period, so you have very, very stable systems that run on COBOL.

Different people view scalability differently, but with webMethods Integration Server, what's happening is that you have cloud-based tools that make the solution far more scalable.

From a webMethods Integration Server point of view, as long as there's a load balancer in front with clustered mechanism, then it should be good to go. Still, the real key is how much of the transformation occurs in integration scenarios, the volume of transactions, the number of transformations, and content-based routing, which affect performance and scalability.

A good example is when you must put a highway to handle the traffic load it is typically expected to serve. You don't need to make it very, very scalable. If you're integrating the product with internal components in SAP or the Salesforce CRM system, you find out how much traffic typically happens, and you double it. Then you create an integration solution, which you benchmark to see whether it can handle that particular load. If it's going to be a cloud-based solution, you again do something similar, but at a much grander scale. That's when you put a load balancer in front and do all your scalability tricks.

One of the senior persons in Software AG is an old colleague of mine, a junior, so whenever I need webMethods Integration Server support, he'll pass me the name of the chief programmer over there, and I'll talk with him on the phone. In general, the software is good. The service quality is also good, and I don't remember any significant instance or problem I faced regarding support.

The complexity of setting up webMethods Integration Server, or any other enterprise integration solution, lies in the data you connect between two enterprise applications.

For example, you have to ask if you have to link ten SAP modules to two Salesforce CRM modules because that's where the complexity comes in. It's not the fault of the webMethods Integration Server if the initial setup is easy or difficult.

The business context would make the setup more complex, and an ESB tool, such as webMethods Integration Server, is just one piece of that puzzle.

Comparing webMethods Integration Server pricing with other solutions depends on the context. The cheapest will always be open-source ESB solutions, such as Apache ServiceMix and Apache Camel. Still, when you compare the quality of support of enterprise software, such as webMethods Integration Server, with open source software, enterprise software usually provides better support quality and higher level solutions versus open source software that typically doesn't have a real support model.

If you're lucky, you'll get someone who will immediately give you support for your open-source solution, but if not, you'll wait for months without any real support. webMethods Integration Server, on the other hand, as it's under Software AG and has an enterprise behind it, can create one-tier, two-tier, and three-tier support mechanisms, apart from providing you with timely support. Hence, you can use the product as part of an ongoing, much bigger integration project. That's where the differentiation and the value come in.

From an enterprise context, the price of webMethods Integration Server isn't that high because Software AG enters a relationship with companies and provides webMethods Integration Server as part of a much larger solution.

I've been in the IT industry for about thirty-two years now. In 1999 or 2000, a Dutch colleague and I created the entire concept of ESB (Enterprise Service Bus), so I have a long history in this particular space, and I've used all ESB products in the past. Right now, I'm the principal architect of a company that provides multiple solutions to financial institutions worldwide. I use ESBs, such as webMethods Integration Server, as part of the solution whenever there's a need.

webMethods Integration Server can be deployed either on-premises or on the cloud. The cloud is a big misnomer, as it's just a server elsewhere. As long as it's connected over a PCP software network, you can take advantage of it.

I'd tell anyone looking into using webMethods Integration Server to talk to the people in Software AG as the vendor has a portfolio of products. webMethods Integration Server is just one offering, so if you can get good value across a portfolio, go for it. However, you need to do the due diligence and create a pro and a con list for different software solutions available in the market. If you're rejecting open-source solutions, you need to have clear business reasons why. For example, maybe you need immediate support, your timeline is short, or your integration project requires a quick turnaround time. My organization is located in Germany, so it's much easier for it and the customers to work with Software AG and webMethods Integration Server, for example.

webMethods Integration Server is as good and bad as other enterprise products I previously worked with in Europe. No significant problems stood out, so my rating for the solution is seven 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.

One of our clients is a chain management company. They have many APIs which do a lot of integrations, including B2B integrations. For that particular client, our APIs are on APIs check and handing the deals and restock. Everything is hosted on our API gateway. They can use a scan and access those APIs and do operations for sales orders and invoices.

The most valuable aspect of this solution for me has been the configuration-based UI. Once you get the hang of it, it enables you to easily develop an API. In addition, it has many in-built policies that are quite handy. We are also able to write our custom policies. I also like the daily logging option. Another handy feature is Kibana with the dashboard, which outlines the day-to-day operations in great detail.

There are things that could be improved with the webMethods API gateway. One thing is that it's too attached to the integration service and we'd like it to be a little bit more independent. We would like for them to separate operations so that it doesn't rely on the bulky integration server and so that it can be used everywhere. I would like for this to be included in the features since the client I work with always tends to avoid the solution. And if the client does not have existing interfaces with it, they choose not to proceed. 

I have been using this solution for more than 30 years.

I would rate the stability of this solution a 10, on a scale from one to 10, with one being the worst and 10 being the best.

My impression is that this solution is scalable. I wouldn't say auto-scalable because of the on-premises part.

I would rate their technical support a seven, on a scale from one to 10, with one being the worst and 10 being the best. The reason for this rating is that they are good, but they could still be improved. There is no premium support, and the regular support responds within a day or so.

Neutral

I would rate the initial setup process a six, on a scale from one to 10, with one being the worst and 10 being the best. I would say it's not too easy, but also not too difficult. It can be complex if you don't have experience with it and, in that case, you will not find the setup easy. 

For us, the deployment was fast; it took maybe a couple of minutes. One person can do the deployment on their own. The maintenance is done I think quarterly or every six months through patching.

Our model of deployment is on-premises.

I would rate the pricing plan of this solution a seven, on a scale from one to 10, with one being the worst and 10 being the best. The licensing is on a yearly basis.

This solution is a good fit for small, medium, and larger enterprise companies.

I would advise other people looking into this solution to get it because it adds an additional feature to the capabilities of your web method templates. Also, it uses existing web flow services to enable you to leverage your existing services that are already paired on your on-premises system or into the traditional system of your work method.

Overall, I would rate this solution an eight, on a scale from one to 10, with one being the worst and 10 being the best.

I'm using the product every day, and I'm working on many different projects. Most use cases are for using webMethods Integration Server as a middleware software or a middleware platform that is connecting to at least two different endpoints. It can be from one side, for example, database, web service, SAP, or any kind of connection, including Salesforce, and the other side can be the same. We are just establishing connections between these systems and doing some transformations and modifications of data in the Integration Server so it can be sent from one side to another.

Clients are mostly using it in order to connect some of their internal systems or to connect to some external systems and some other partner companies. Its benefit is that it's really useful for monitoring and tracking all the activities. And it's important, due to all the flows, all the data, go through this ESB, Enterprise Service Bus. 

The most important thing when using it is that there is a really good community from the producers, Software AG, and the Empower platform, where you can find almost every kind of error or problem that you face. You can find a solution right there in the community.

There is also typical support where you can create a ticket if you are not able to find the issue on your own. If it's something new, then they will approach you and help you in resolving it. 

The best features are these adapters. Software AG developed many different adapters for the usual databases, et cetera. I was not using Salesforce much. However, it's really handy that you have an adapter for these popular platforms. It's just plug-and-play.

When it comes to the user interface, I'm already really used to it. I cannot say anything against it. For me, it's easy to use.

When there is some issue or bug, they work on the development of that. And then, in the next release, they just fix it. I had a few situations when I faced some issues, and then I had to report them. Within the next three weeks, typically, it just gets fixed.

For code version control, you need to use some external software. It would be good to have it just built into the product so that you don't have to use anything external.

The interface could be modernized. 

I've been using the solution for about five years. 

If it's set up properly and if you do it in a good way in large-scale organizations, you need to have a maintenance team that is doing the maintenance and support. If it's working properly and updated properly with the latest versions of updates, then there should be no issues with using it. It is reliable. One of the main benefits of Integration Server is that it is reliable.

Our entire company uses the solution. There might be 100 people using it on a daily basis. 

Scalability is one of the main purposes of the product - scalability meaning that it can adapt to small customers, clients, and even to bigger systems and clients with a lot of data going through the Integration Server. 

Technical support is really good. They are replying really quickly. In a day or two, you can get a response for your issue, or probably even quicker if you mark it as urgent. 

For me, it's fine. I had some contact with Software AG support. They wrote really helpful. And a few times we even had some meetings with screen-sharing sessions so they could help and see the issue. It was really nice. 

I know there are a few really great options on the market; however, I do not have experience with them. 

When it comes to deploying the Integration Server, you just need to follow the documentation, which is really good. The documentation created by Software AG for using and working with each of the products is really nice, and I'm satisfied with that. For the first time you use it, you need to install the Integration Server on Windows or Linux machine or whatever, and if you follow the steps via the documentation, it should not create any issues.

The deployment can be done by one person. It might take an hour or two.

If you are installing many Integration Servers in a cluster, then these things take time to configure the clusters and all other setups related to the network. That said, for the basic product, if you want to use it just for your own purposes, if it's just one instance, it does not take much of your time to get it up and running.

There isn't much maintenance needed after the solution is live. 

The solution was deployed in-house. It's not rocket science. It's easy, and you can do it just by following the instructions. It's a really user-friendly installation.

I'm working in the development part of the company. I'm not aware of the prices.

I would say it's an affordable product. When it comes to big organizations, it's for sure affordable.

We are a Software AG partner.

I'm mostly using the latest version. I was using version 9.9 when I started. Then I was going through all the versions, including 10.1, 10.3, 10.5, and 10.7. Now, 10.11 is the latest one. However, I'm not sure that I started working on that one in any of my projects. 

We are a partner company of Software AG, the producer of webMethods.

New users should look for a list of references and companies that are using this product. 

For a large-scale organization, this is a must-have product. When it comes to Integration Server and the Enterprise Service Bus as the product which needs to be implemented in an organization, it has many benefits like properly monitoring, tracking, and controlling all the flows in the company and outside the company. It's a great product to have.

I'd rate the solution eight out of ten.

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

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

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

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

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

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

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

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

It has been very stable.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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