The initial setup was more of an administrator task, so I did not participate in it directly. However, as far as I know, the software that comes with the installer is a complete package so we just needed to install it. It does require a bit of information which needs to be addressed prior to getting installed, though.

When it comes to code deployment, the code and packages that we work on go through the servers with CI/CD pipelines.

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.

It depends on what role you are playing. Are you working as a developer or are you working as an admin? For a developer, it's very simple. It's not very complex. You just need an Eclipse-based designer IDE and a browser installed on your machine. That's all. You are all set. However, as an admin, you have to install and maintain all the components. You have to install the patches, and updating these versions is not very smooth. The update manager that they have provided is not very accurate. Sometimes, it fails. If it fails in between, it is very difficult to recover from that failure. So, from an admin's point of view, it is a bit difficult, but from a developer's point of view, there is nothing much.

We generally have webMethods Integration Server on-prem. We are deploying it on-prem, and there is a deployer, and there is also a webMethods IO component, which is more cloud-based. The VM on which it is installed could be hosted somewhere on the cloud, which is a different story, but the product itself doesn't have any cloud capability where you can directly put it on a cloud provider host.

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.

The initial setup is easy. We deploy both on-prem and cloud, and both are straightforward taking less than 10 minutes. For on-prem implementation, there is a deployer and for the cloud, we use OpenShift. The deployment requires one person and the product doesn't require any specific follow-up maintenance. 

From an implementation perspective, it's a heavy component. From an installing perspective, it is faster. That's not a problem. Installation-wise, there are a lot of dependencies. You need to have a database first set up, and then you need to have all that storage-related things set up, and then you have to install Integration Server on top of it. It takes time.

The current deployment that we have, it's all provisioned, and the CI/CD pipelines are all there. With Integration Server, you may not need to redeploy every time, it's an existing item. We have only three or four people deploying packages, so not more than that. That's mainly not related to webMethods, that's due to the maturity of the pipeline, so we don't have a lot of people there. From a support perspective, there are specialists there. It's a team of around ten members.

Upgrades are complex. They typically take about five months from start to finish. There are many packages that plug into webMethods Integration Server, which is the central point for a vast majority of the transactions at my organization. Anytime we are upgrading that, there are complexities within each component that we must understand. That makes any upgrade very cumbersome and complicated. That has been my experience at this company. Because there are many different business units that we are touching, there are so many different components that we are touching. The amount of READMEs that you have to go through takes some time.

This is where we would need to look at an iPaaS solution or moving to work with microservices solutions. Obviously, the smaller you make the solution, the more you're able to in an agile fashion.

From a high-level implementation strategy, we do a waterfall approach. That is the approach that we have ended up following for upgrading this solution.

Deploying solutions is very easy. The biggest thing that any company has to look at, because we have had a couple of pitfalls in this, is you have to look at how you're rolling your solution out. So, if you end up stacking or creating common services in the solution, those solutions become very tricky as they start to age, as any development cycle would end up having. The smaller you create the solution, the easier it is to keep rolling out those solutions, and staying away from common services really allows you to continue to roll out with ease.

As new solutions roll out or there is a different way for these apps to integrate, it has been fairly easy for developers to make the modified changes needed. The biggest thing is always knowledge because there have been some integrations that haven't been touched for 15 years. Then, if someone needs to touch one of those integrations, there is a learning curve in understanding how that integration works and what they are looking at.

The tool's deployment is not straightforward. Indeed, the deployment duration hinges on the complexity of the organization's size. Certain components may facilitate swift upgrades, while others, such as the API gateway, often take longer.

The deployment process is smooth and doesn't come with any standardized guidelines. Developers can do it as per their approach. Six steps can be used to deploy the tool. You would need two to three resources to handle its deployment and maintenance. 

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.

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.

The initial setup is of medium complexity, although it depends on your scenario. If you have a simple use case to just integrate, it's easy. The actual installation is very straightforward but we had some complexity because of the zones.

We had multiple DMZ zones and we have a PCI zone. This meant that there were a lot of firewall rules that needed to be created. It was a greenfield project, so we had to build everything in addition to the webMethods aspect. The project was definitely complex. However, the webMethods setup in isolation was very straightforward. If you just focused on, "Okay, this is the one that you have to install." It's straightforward. If you know what you're doing, it's easy.

Upgrading is something that we can't do in a very fast manner. It's not like we are going to upgrade every six months. We have to wait a while. On the other hand, that's where the microservices architecture is good because anytime something new is released, we can upgrade to the latest.

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 initial setup of the webMethods Integration Server is not easy but it gets easier once you know it. It is tiresome but not difficult.

We deployed webMethods Integration Server for our development and staging, and then we moved on to production. Regarding development and staging, there are single servers for production and we have multiple nodes for each.

It's easy to deploy. It has its own deployment tool, which makes it very fast. We can use it both on the cloud and on-premises. 

We have a 13 to 17-member team of developers that can handle the deployment. 

The installation is straightforward. It's easy.

It can take thirty minutes to deploy depending on the number of components.

It can be installed both on-premises and in the cloud. It has been migrated to the cloud, and we also use it on-premise.

The initial setup for webMethods Integration Server is straightforward. It's just a normal process, so on a scale of one to five, I'd give the setup a rating of four.

The initial setup was straightforward.

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. 

I would rate the initial setup of this solution a three and a half out of five. 

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.

Significant topics with bespoke programming model (FLOW language), difficult to find experts and if, they are expensive. Wouldn't do it again.

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

Some parts were straightforward, but installing the platform was a little complex, especially since we use Linux instead of Windows. Opening ports, network restrictions, managing the network, and managing the users and components were all a little bit complex.

Quite complex in setting up the BPM environment, the UDDI service (Centrasite), and also the API Management. But nonetheless there's documentation for each product 

The initial setup was straightforward.

The initial setup is not difficult for me. I rate the ease of setup a seven or eight out of ten.

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

The initial setup is very simple and very straightforward. 

That said, open-source solutions are easier. However, we like to have a contractor come in and take care of everything.  

Everything to be set up must be done carefully and properly. Certain changes cannot be incorporated so easily. There might be certain dependencies across certain applications. We take a pretty careful approach every time we are migrating.

The installation of the webMethods Integration Server is straightforward.

The length of time it takes for the implementation depends on the architecture and how many instances we need to install for the client. However, it typically takes a couple of days.

The implementation process starts with downloading a load that connects to the software. A server takes on the needed components, such as an integration server or universal messaging. You need to follow the integration steps.

The initial setup is not complex. I would say that it is straightforward.

The initial setup is hard for an early learner like me. It's quite difficult as we were presented with too many features and we didn't really know what was going to be installed.

For example, when we tried to install Integration servers, we had so many other features that needed to be installed, and we don't really know what that was about. By the time we try to install, we forgot to install some other items, such as JDBC for the database. At that point, we needed to install it again. Overall, it's kind of hard for us to use the initial setup.

The installation process should be improved for first time users, as it is quite difficult, and it should be made more user-friendly. 

Complex, regarding previous architecture and full SOA stack deployment.

The setup was well-documented.

The product is easy to implement. We help our customers to implement the solution.

There was an implementation issue, i.e., some of the preconditions were not clearly mentioned, so we had to dig through multiple options to troubleshoot and find the right steps.

Complex. Lots of configuration parameters have to be set to guarantee a solid platform. Some of these parameters are not mentioned in the product documentation!

I was in the company when they only started with webMethods. It used to be a very simple solution used for a few integrations. Now, it is much more complex. We've got many more frameworks, multiple countries, much more services, etc.

The installation process is very complex, there being many products, each having its own. The deployment should be simplified. Other than this, I feel it to be a good tool.