What is our primary use case?
We use it for everything. Three years or four years ago our company was bought. In our original company we used it for EDI, although that has pretty much gone away since the purchase. We do use it for EDI, but we use it for more free EAI, enterprise application integration. It allows us to have plant software talk to SAP. It allows us to interface with external parties through their MFT (managed file transfer) product called Active Transfer. We use it to connect all kinds of systems.
Also, in a company that's big, there are always acquisitions, and before the acquisition can be fully integrated there is always the challenge of getting data in and out of that acquisition. We use webMethods for that too, because we can either use internal network or external network.
It's hosted in Azure, on VMs.
How has it helped my organization?
Its adapters and connectors absolutely provide the fastest way to build an integration. An example of the effect of that speed of integration on our business is that when our company was acquired, the acquiring company didn't have webMethods and wasn't interested in it. We were able to build interfaces quickly and show that they didn't need constant babysitting. For example, you can build frameworks. We had built an error-handling framework that can notify people with meaningful error messages when they happen. It never crashes. It always tells people what happened. We were able to build solutions much faster than with the other tools.
Process orchestration is another benefit. Driving towards an event-driven architecture, and not a batch-oriented architecture—which introduces all kinds of time delays and doesn't give a true picture of the end-to-end process—we've used webMethods Designer to design process models that can orchestrate a process from beginning to end. For example, we can get data via SFTP, trigger an event in webMethods to process the data, and load it into a third-party data warehouse database such as Snowflake, which is a new up-and-comer. We can then trigger other processes to move that data and process it in Snowflake. We get responses back and, at the end, we can consume the processed data and send it to a different endpoint. All of that is orchestrated by webMethods. Process orchestration is a very strong point of the solution.
Modifying and troubleshooting are very easy. They have a nice debugging app interface. It's faster than anything else that we've ever used. For example, when we were acquired, we had to keep our legacy SAP system, which was still functioning for the legacy company, synchronized with the acquiring company's SAP system. This was a very complicated task and we were able to do it very quickly using webMethods Integration Server.
What is most valuable?
We use Active Transfer quite a bit. It's very convenient because it is integrated with Integration Server. That means you can deploy an event-driven architecture, based on SFTP, which most people can't pull off. Most of the time, with SFTP, there is file polling and it's not an event-driven architecture. But webMethods' solution allows you to plug into their integration server and have a totally end-to-end event-driven architecture.
The comprehensiveness and depth of Integration Servers' connectors to packaged apps and custom apps is unlimited. They have a connector for everything. If they don't, you can build it yourself. Or oftentimes, if there is value for other customers as well, you can talk with webMethods about creating a new adapter for you. That's particularly true of their cloud-based webMethods.io and their hybrid cloud solution. It's an on-prem plugin called CloudStreams. That allows you to connect your on-prem services with cloud-based things. The number-one example that everyone always gets is Salesforce.
That depth of comprehensiveness is similarly true for the solution’s connectors to SaaS apps, IoT devices, and legacy applications. That is the number-one strong point of webMethods. It can connect to anything. There are so many out-of-the-box connectors for SaaS things. There are JDBC adapters, SAP adapters. They have pretty much unlimited connectivity, or you can build it through their toolkits.
It provides a single hybrid-integration platform for all our needs.
What needs improvement?
Deploying is something we have found to be lacking with native webMethods tools, as is the ability to plug into a change management system, so we built our own deployment system. But again, we built it with webMethods' foundation tools and then interfaced with sub-version, version control, and our own home-built change management system. We used it to enforce that things can't go to prod unless they pass the QA stage and have had successful QA acceptance testing.
It would be nice if they had a change management system offering. We built our own deployer application because the one built into webMethods couldn't enforce change management rules. Integration into a change management system, along with the version control system, would be a good offering; it's something that they're lacking.
For how long have I used the solution?
I've been using webMethods Integration Server for 20 years.
What do I think about the stability of the solution?
Overall, it's very incredibly stable. I've never seen any other software platform that can run for so long without crashing. We've had servers run for over a year, and we have restarted them not because they were broken but because we were installing something. We've had servers run for over a year.
In terms of support for the solution’s adapters and connectors and long-term stability for your services or integrations, you build once and forget it.
What do I think about the scalability of the solution?
Scalability is another strong point. It's very scalable. It's very easy to stand up parallel machines, and add them to a cluster. We have two machine clusters because another strong point is that we've built everything in high-availability. We have two of everything; everything is clustered. But if we all of a sudden acquired 50 more companies, and had all kinds of additional business, we would just stand up a couple of more servers in the cluster, they would inherit the same exact code, and it would be simple very simple to scale.
It's used for all our North America integrations. It runs the gamut of a little bit of EDI, a lot of EAI, and some MFT. Anything where one system needs to talk to another system, and trade data, we use WebMethods for that.
We are always building new things in it. There are always new projects.
How are customer service and technical support?
We don't need a lot of vendor support. You get the platform and you get some people that know how to use it and you really don't need much support from the vendor. However, when we do need support, they do have a good support portal and we do get support from their personnel pretty quickly. Our experience with their support has been good, for the most part. Once in a while we get people who aren't quite as good. I would rate it at eight out of 10.
Which solution did I use previously and why did I switch?
We did not have a previous solution.
How was the initial setup?
When it comes to upgrades, 20 years ago, it was very hard. Ten years ago, it was hard. Today, it's fairly straightforward. They've gotten much better at their upgrades.
As for how long an upgrade takes, there are many factors involved. We had a struggle with our infrastructure team just getting us the vanilla boxes and Azure. Once you have your boxes in a network so that they can talk to each other, the installation of WebMethods is fairly simple.
Then there comes the complexity of importing your old code into it. And the hardest task of all is testing everything to make sure it still works. But the upgrades are pretty simple, they have apps that help out with that, and they work pretty well.
The upgrade we're doing right now has four people involved. I am the architect, and the other roles are developer/testers.
Day-to-day maintenance is almost zero. If there is a need for some maintenance, we have two people, me and another, who take care of system maintenance. But really, it's stand-it-up-and-forget-it. You do have to do certain things. webMethods is not in charge of your user databases. So if they fill up with data, and you haven't built in something to automatically purge them every so often, that's on you, not on webMethods. But as long as you have built in these types of maintenance routines, and schedule them, everything is pretty trouble-free.
What was our ROI?
I wish our company measured ROI. We're slowly getting there.
But webMethods Integration Server just saves time, especially development time. We can implement solutions that save repetitive user-time, often. Often, if a group comes to us and says, "Fred is spending two hours a day doing this stupid task where he's just uploading into a spreadsheet, and downloading here; can you help?" We can turn that type of thing around so fast, and eliminate Fred's two hours per day.
What's my experience with pricing, setup cost, and licensing?
Pricing is the number-one downfall. It's too expensive. They could make more money by dropping the price in half and getting more customers. It's the best product there is, but it's too expensive. It could be 10 out of 10 if they dropped the price. There are so many people who don't use it because it's so expensive.
Which other solutions did I evaluate?
It also provides application integration, data integration, business-to-business communications, APIs, and microservices. That range of features is very important because we can do anything with it. We tried Informatica, for example, which was portrayed as being an equal, and it wasn't. It can't do everything and then you have to go out to other products and combine them. webMethods can truly do everything within the webMethods environment. And you don't have to buy add-on products. In reality, a lot of the webMethods' plugins are add-on products that were acquired at some point. But they do pretty well when it comes to integrating their acquisitions into the main ecosystem.
The scope of abilities in Informatica is very limited. The scope of abilities for webMethods is pretty much unlimited.
We have also looked at SnapLogic, and again, it just doesn't have the breadth of abilities that webMethods does.
What other advice do I have?
The biggest lesson I've learned from using it is to never build a one-off. Always think "reusability." Everything in webMethods is reusable. Even if you think you will never use it again, and you build it hastily, without error-handling, you will get burned. Always build for reusability.
You should definitely build a couple of little reusable frameworks too. The first reusable framework I would build would be an error-handling framework. Once you build that, you add those service calls to every service you ever build. In that way, once things error, you always know. It knows how to send an email to the right people, it knows how to send a meaningful error message that someone can read and see what happened. Building a meaningful error-handling framework upfront will save you so much time when things break and people ask "How do we fix it?" It will also proactively let people know things errored out, instead of reactively. We also built a deployment framework. That's a little above and beyond. The webMethods' tools are not terrible in that regard, it just doesn't talk to a change management system.
Everything you build in webMethods is a microservice. It's been that way for 20 years. So even though the term wasn't coined back then, you can expose any service in webMethods to any other system you choose. Call it an API, call it a microservice, but it's all just built-in and it's already there.
They are focusing on their cloud offerings, as is everybody else, because everyone wants to go that way. Sometimes it's just for the sake of saying, "I have a cloud offering," but theirs seems to be pretty solid. Their cloud offering is webMethods.io. However, I haven't used that extensively. That'll be coming up this year. There is also a hybrid thing called CloudStreams and that is for on-prem webMethods, which is what we have, but it has canned connectors to SaaS solutions like Salesforce, whereas webMethods.io is entirely in the cloud. You would use that to connect one SaaS to another SaaS.
In terms of the solution's support for the latest standards making it possible to plug into modern tooling and third-party products, we've found no need. It's a pretty complete solution, unlike other solutions. And you really don't need to plug anything else into it.
Which version of this solution are you currently using?