What advice do you have for others considering webMethods Integration Server?

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.

Follow best practices,engage in their professional services to help build your messaging system and to be PR have some PR emphasis and and blue Bluegreen deployment You could take half your your clusters out, upgrade them, and put them back in so you have a quick callback. And also patch quarterly, we got we got downbound. And and at that point, it's a little hard to get into the cycle when you're releasing software every every week, and you're trying to, go through an upgrade seven fifty servers, it's a little hard to get into the upgrade flow when when you're running that tight. I rate the overall solution an eight out of ten.

People who want to use the product must request a trial. Overall, I rate the tool a nine out of ten.

I would rate webMethods Integration Server an eight out of ten.

I am using the latest version of the solution. My advice to product users depends on their organization's scale. If an organization is a medium to large enterprise, I would recommend the solution to them. If the organization is small, it should consider other solutions in the market. Overall, I rate the product a nine out of ten.

I recommend this solution and rate it nine out of 10.

I'd recommend the solution to others, depending on the use case. There are many factors that would be highly dependent on its success. I'd rate the solution ten out of ten.

I would recommend this solution to others. I rate webMethods Integration Server an eight out of ten.

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.

My company has a partnership with webMethods Integration Server. My main advice to anyone looking to implement webMethods Integration Server is to figure out the governance target. You also want to aim for a good implementation, so you'll need to know your target. My rating for webMethods Integration Server is seven out of ten because it could be more innovative and still needs more connectors or adapters.

I'm an end-user. Currently, I'm using the 10.3 version. Previously, I've used an 8.3 and as well as 9.5 as well. The version which I have been working on is deployed on the server. Recently, the organization is looking toward deploying it in the cloud as well. However, it's in the pipeline. If you are looking for a full-fledged ESB, then Integration Server is one of the best choices, as it is highly customizable. So if it's an ESB, then you should go for it. If you're looking for a microservice-based architecture, then it may not be a good choice since it is very heavy. It's not easily deployable and is not cloud-native. And it does not come with all the pipeline capabilities like the CI/CD pipeline. It's all right to scratch. As a new company that is trying to implement that, if they're looking for cloud-native, it is maybe not the best choice. If they're looking for a full-fledged service-oriented architecture, a full-fledged ESB, then webMethods is the best choice. I'd rate the solution seven out of ten.

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.

The solution has been doing the job for us, at least with respect to the landscape and the integrations we have in place. However, it is on a case-by-case basis. I rate webMethods Integration Server an eight out of ten.

webMethods Integration Server has a very good API gateway. It will help your development become easier, because most of the services, we do not have to make any extra changes. We can do it by the gateway. I recommend that the portal which is on the front-end be the gateway, and on the back-end is the integration service. I rate webMethods Integration Server an eight out of ten.

I'd warn potential users that, if you get into the ESB sort solution, once you get into it, coming out of it is very difficult. The dependencies are very high and you are running it in the middle of your architecture. It becomes something you have to budget for and allocate every year. I'd rate the solution a seven out of ten due to the complicated installation process.

I would rate it an eight out of ten.

We would advise others to at least give webMethods Integration Server a try. Based on the solution's usability and ease of use it is very good. You don't have to do a lot of coding, it is close to an out-of-the-box functioning solution. It makes life easier. I rate webMethods Integration Server a nine out of ten.

You just need to find the right skills. In our country, we don't have people with qualified webMethods skills, so that's a problem for us in terms of resources. Depending on where you are from and if you don't deal with resource scarcity, webMethods could be a good option for you. On a scale from one to ten, I would rate webMethods at eight.

I was the architect of it, and I wasn't personally the one who went deep into it. My advice would be to just partner with an implementation team and make sure that things are documented so that for upgrades, you're not married to them, and you don't have to use them all the time. I would rate it an eight out of 10.

I'm only a vendor for the customer that already has this operating. I'd rate the solution at a seven out of ten.

On the topic of development time, this product can save you time but it depends on what you're comparing it to. For example, if you are comparing it to having no platform, where all of the integrations have to be developed from scratch, then this product will definitely save you a lot of time. The undertaking would be massive. If instead, you are comparing it to another product such as MultSoft, then it will be a different answer. It is tricky to estimate because it depends on the tool. This is a product that the vendor keeps adding things to. Sometimes, we have to wait until the next version comes out before there is support for what we want to do, but there hasn't been anything major. My advice for anyone who is implementing this solution is to spend some time thinking about how it will be used. I have seen instances where the product was being used and didn't work properly. If it is designed nicely then it will work wonders, so spend some time thinking about the design and how it will be used and it's never going to have any issues. I would rate this solution a nine out of ten.

I am a user, so I'm not entirely familiar with everything this solution has to offer. I am utilizing one of the technologies that they provide. Using this solution is dependant upon each area's perspective. I can't exactly say, if you had only one user that it's only for this solution or that solution, but it actually depends upon each other's perspectives. WebMethods is the recommended solution if you want a stable integration, an ESB platform, and a B2B. I am unfamiliar with cloud-based solutions or their environment. We are exploring their options and services. I would rate webMethods Integration Server a nine out of ten.

I think anybody who is implementing this product should learn about the balancing and the API portal that is going to be used. You should have a good developer that is able to use the platform and understands most of the capabilities that it provides. Overall, it's a really good product. I would rate webMethods Integration Server a nine out of ten.

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.

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.

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.

The solution pays for itself, but it is complicated as it stands today. Make sure that you are using it for exactly what you have architected it for. Don't try to fit a square peg into a round hole. We have been moving away from data integration for webMethods Integration Server. So, it's becoming less of a priority for us. Software AG has been moving in the direction of trying to make their tool as modern as possible. It has plugins for Docker today as well as ways to integrate into webMethods Integration Cloud. While these integrations are available, we don't use them. I would rate webMethods Integration Server as a seven (out of 10). For what the solution can do, it does it extremely well. The upgrades are very cumbersome; they are very long and disruptive. You have to do them at least every three years. It's not a fun time for any company. If upgrades were a 100 times easier, it would get a much higher score.

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.

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.

My advice to anybody who is considering this product is that it is a very powerful tool that will empower the development of services. If there is a proper plan then it can be achieved within a short period of time. After a service has been developed and tested, it is moved to the staging environment. Once it is tested, we move it to production. Moving it will not take more than a few minutes. It is definitely a product I recommend to people who have the money to pay for it. I would rate this solution an eight out of ten.

I have found that the home-grown products from this vendor always do pretty well, but when they acquire new products from third-parties, there has been some disappointment. Overall, this is a pretty good product. In fact, my only real complaint is about support. I would rate this solution an eight out of ten.

Overall, it's a great product. I would rate this solution a seven out of ten.

I would rate this product as an 8 or a 9 out of ten.

My advice is to put more focus on implementation rather than on the platform itself. This is more important than the platform because finding someone that knows how to fit the components is more important than having very good components that no one knows how to use. I would rate this as eight out of ten, because of the scope we have already implemented. We didn't face many complex issues or troubles.

Look at the stability of the company, and also take a close look at the pricing. Lower pricing doesn't necessarily mean it's a better product. Most important criteria when selecting a vendor: * Price * Features * Support.

I have to say that all SoftwareAG products are tightly proprietary, which means you can't just download and install for study purposes or to play around with them. You have to call their partner/product representative just to download the trial, which is quite different from their competitors. That makes the product unfamiliar to mid-low enterprises. Also, their products are "componentized" in terms of licensing and tightly coupled, which means that some components may be licensed while some are a prerequisite to other components. So it could be that you have to buy two to get one and a half (pretty amazing isn't). But overall it is a great product. Another thing is that made me bit upset was that the certification/training in South East Asia (which is my region) is not "individual friendly," meaning that if you want to get developer certified, you have to join to one of their partner companies or bulk order.