What is our primary use case?
It interfaces between applications, as well as between the cloud and our existing on-prem applications.
We primarily utilize packaged applications; we don't really have a lot of custom applications. We do have a few custom interfaces, and some vendors may have created a custom interface on their own, but we present a standard integration, a standard enterprise service bus, to connect to.
How has it helped my organization?
We're able to secure our front-end website away from our back-end systems using Integration Server. It acts as a go-between. That way, whether we're requesting things from our website or our IBR or our IPT, we can have multiple interfaces. They're secured in their own ways, and they don't have direct access to our back-end databases.
We're a utility company and before we got this application we would actually send out people to the meters to read them. Sometimes they had handheld devices, but sometimes they had to walk up to the meters. When we switched to AMI meters, we leveraged the ability of the solution to talk to each of the meters on a daily basis, as well as to turn a meter on and off in real time.
Additionally, we use the same application to process payments. Before this solution, we primarily had walk-in centers and a lot of manual processes for receiving payments. Very few payments were done online or via eCheck. Now we can have a whole host of payment options, as well as enable different payment vendors to connect. It has automated a lot of our manual processes.
webMethods Integration Server provides a single hybrid integration platform for all our needs. It provides reusability. We don't have to worry about taking each and every point-to-point integration. Now we are hosting a true enterprise service bus, by having a set of APIs that can really be leveraged and reused by multiple vendors and multiple connectors.
Its adapters and connectors provide the fastest way for us to build an integration. We're able to turn things around pretty quickly. I'm sure there are other faster ways that other people have done, but this meets our needs.
It's helped us to become more modern. It's allowed us to service our customers in the ways that they want. They can now use on-the-phone payments or website payments or whatever way they want to do it.
Internally, it provides a standard way for us to be able to interface with things. Now, we don't have to have unique ways to do so and much more code and numerous ideas on how to do things. We just end up having a standard.
It provides us with ease of modifying and redeploying integrations. We have been able to do that very successfully. It just makes it easier. We were able to put in an Agile framework, which means that as requirements come up and changes are made, we're able to schedule them on a regular basis. But we were doing that for the long-term before, as well.
Its support for the latest standards make it possible to plug in modern tooling. We've used that in several places, especially for IoT integrations. The result has been reduced costs and improved customer satisfaction.
What is most valuable?
The most valuable feature is its ability to quickly spin up connections between the real-time interfaces, as well as being able to regulate how much traffic moves back and forth between applications. This is important because one of the things that we utilize it for is payments from our customers. We can have multiple customers utilizing the same set of APIs and they can make real-time payments into our system, which is really useful. We don't have to worry about people making duplicate payments or providing incorrect information. And we get that information right away.
Also, the solution has a very comprehensive and versatile set of connectors. I've been able to utilize it for multiple, different mechanisms. We do a lot of SaaS and we do have IoT devices and the solution is comprehensive in those areas. There's a standard utility protocol for talking and several of the applications we have utilize that utility. It's a standard set of APIs, and Integration Server adapted to that right away. For our website we're utilizing standard Wisdom APIs and we were able to create that. The solution is very versatile with all its capabilities and is able to do what we need to do. We even use it for Salesforce.
It provides us application integration, data integration, business-to-business communications, and APIs. We haven't used it for microservices. That range of features is very important to us. It conducts our real-time payment applications, as well as our real-time integrations between our internal applications.
What needs improvement?
The logging capability has room for improvement. That way, we could keep a history of all the transactions. It would be helpful to be able to get to that without having to build a standalone solution to do so.
For how long have I used the solution?
I have used webMethods Integration Server for about 12 years.
What do I think about the stability of the solution?
We haven't had any issues. Everything has been working. We like the new version, the new upgrades. It seems they keep improving upon things. We've put in high-availability and fault tolerant solutions so we have had zero downtime due to the system itself.
What do I think about the scalability of the solution?
We haven't run into any limitations up until now. We utilize it for a lot of different things, but we haven't run into any speed issues or other problems.
We end up talking to our customers using the solution and we have over 250,000 customers. Our internal users don't really even notice it. They just see that everything is up and running and available in real time.
How are customer service and technical support?
We haven't run into an issue requiring technical support from their side. It's usually something that we have to adapt to or modify. It's usually something internal.
Which solution did I use previously and why did I switch?
We used eCheck. It was website-based for point to point integrations. We switched to Integration Server to improve speed to market and have a quicker way to turn things around. We also wanted to put in some newer interfaces that would talk to all of our customers.
How was the initial setup?
The initial setup was pretty straightforward. We were able to quickly utilize some templates, things that they already had, to get it up to speed.
We took our time. We developed and deployed our first product in eight months. Then, over the course of time, we were able to add more and more until we had a robust solution.
Our implementation strategy was to look at business needs to prioritize things.
In terms of maintenance, it only requires oversight, nothing too obtrusive. We've got one integration engineer dedicated to all of our integrations and we haven't had any issues yet.
What about the implementation team?
webMethods provided the name of a third-party and then we reached out to them and we got them onboard. The company's name was Kellton Tech and they did a very good job. They're still with us.
What was our ROI?
We were able to realize ROI fairly quickly because we were able to reduce a lot of the manual work and point-to-point integrations. If you think of truck costs and the amount of gas expense, we don't have to worry about those on a daily basis anymore. Those alone would justify it.
What's my experience with pricing, setup cost, and licensing?
It's a good deal for the money that we pay.
Which other solutions did I evaluate?
We went through evaluation criteria with three or four vendors and we found this one to be the best. The primary advantages of this solution were the supportability and ease of use. Also, the deployment time was reduced and development was more Java-based.
What other advice do I have?
Start with proofs of concept. Create a few good proofs of concept and get it up and running and you'll be able to escalate things. Make them achievable.
The biggest lesson I have learned from using the solution is that I should have envisioned it a little bit bigger. We had a lot of point-to-point solutions that we could have considered and I think we still have a lot more to go. Also, if the back-end is not available, we should build in some logic that says, "Okay, now that I'm not getting a valid response or any response, I should be able to quickly use a default or turn off some features." We're trying to redesign and re-engineer it for that to happen.
As an overall product and solution, it has met our needs.
Which deployment model are you using for this solution?