OpenText Service Virtualization Reviews

We implement this product for companies in the banking industry. We use virtualization to simulate and validate data models of the core banking system for the purpose of testing. When one application is implemented and accesses the testing phase, the test environment needed to connect to external/legacy system to fulfill test coverage. Test cases might cover both functionality and performance which sometimes external system faces the limitation to support.  

It is difficult to make test environments connect to the mainframe with required test data already in place, so we planned to use virtualization in this situation. Another use case for us has to do with performance testing. Many banking systems (public ones) facing performance issues in production have been identified that as impactful is not in the application itself. That means the test hasn’t been done well enough during the integration, most of them cause by limitation on test environment. Service virtualization with a performance model feature can help solve this situation.

When a test is covered, the risks in the production system are surely controlled.

The feature which is most valuable in this solution is the ease of use. The product is
very easy to use and implement. Another thing is that we can adjust the performance
level. We can make the model simulate the best service, normal services or bad
situations in many possible ways.

Some of the valuable features that I found in the tool is: we’re a big TIBCO shop so there’s a lot around TIBCO that has been very valuable for us, TIBCO EMS Virtualization. We have a little MQ, MSMQ so that was enticing, haven’t really dabbled in that much yet. The ability of bringing down net services, have it stand up all the virtual endpoints pretty quick and put it into a learning mode to where I can turn it on, let the functional testers test against real services all day, take that snapshot, turn it over to my performance test team, minor tweaks, and now I’m running a full performance test with faked out third parties with minimal development effort on my side, that’s awesome. Another feature that, it’s still in beta but it’s coming up that’s, I’m already starting to leverage is the scripted role that they put out there. It’s Javascript and C#, we’re a heavy C# shop. So I have my choice of developers. I go around and say, hey help me develop something that’s a little smarter, a smarter, server-virtualized service and, you know it’s easy ‘cause I just show it to ‘em, they get it and stand it up, and it’s good.

So some other benefits I actually think I made the tool do something it wasn’t really meant to do but it worked perfect for my environment. So we had a big project to tokenize credit cards. We wanted to get out of the business of hanging on to credit card numbers because of the inherit risk. So we had a massive project to come in tokenize those credit cards. One problem is the vendor much like any other third party comes back and says, well we don’t have a performance environment for this so… And if you performance test against our environment we’re gonna cut your access off because that’s gonna impact other people. So naturally the team turned to me and said, hey what do we have, can we virtualize this? I reviewed what they were doing and it was not a service call, it was actually a website form post. So I turned the call into rest call, slid it into the config file, told it to point to my service virtualization, and it worked just like an HTML post call and it worked perfectly. We were up and running probably within a day with this virtualized uh, endpoint. I couldn’t believe it ‘cause that’s not what the tool was made for, but it worked perfect. So that was one of those added benefits, undocumented features, right?

My customers use it to replace the mainframe of each system that's difficult to provide in a test environment. We use virtualization or intelligent mockup.

It is easy to use. This is what I tell my customers. The coding is easier to develop as well.

The most valuable feature is that it reduces the dependency so that the down time of the environment is not a major cost. That cost can be used for something else like the cloud.

The important is thing is that Service Virtualization allows you, each and every individual, and each and every system, to be up at any time throughout the cycle.

That indirect cost impact is in the millions of dollars for any IT organization. The direct cause may be that the environment is down and that the tester is sitting for ten hours.

However, the indirect cost is that the end product is not achieving its release date. That is the business impact. If you look at the broader picture, the silos may be the Service Virtualization, but the end-to-end picture is that there is a huge impact, and that impact is actually priceless.

I cannot go and say that, "Okay, tomorrow I'm a mobile service. My apps are not going on mobile." So, I cannot calculate it, and I cannot write that particular dollar value, because I never know what it is.

For example, a sales platform may have the features that I have added, to give me a million dollar sale, or it may not. However, Service Virtualization allows you to release on time at least, so you can align with the strategy of your business.

It gives you granularity and transformation. My personal point of view is that Service Virtualization plays a major role in transforming your development, testing, and operating engineer into a business engineer.

The industry is moving towards Agile and DevOps. The most important thing is that each and every individual in your company is not thinking of themselves as individuals, but rather as if they are the end consumer, or running the business themselves.

Certain products have their own monopoly and they really don't want to share their market share. Service Virtualization enables you to share everything in terms of the protocol tier.

With a CRM system, you have all other systems integrated. You can virtualize and then the core system is CRM. And if you never virtualize, your own virtualization falls down. This is how it works.

I can use functional performer automation everywhere. However, the questions still remain of when and how I need to use it.

If I run a load test and I need a Service Virtualization, I can use the same asset. But when I'm using the same asset against the functional test, do I need to use it as is, or do I need to modify the workflow?

They must have that pace, but the product itself is up and coming as a new product in the market. Companies themselves are struggling to find out how they can align the technology with testing and developing practices, or where they can fit it into functional automation of performers or integration.

At the same time, there are a lot of emerging technologies coming onto the market. These other companies are saying that Service Virtualization leads to the first step, and then they realize that protocol leads to the fifth step.

The problem is that there is too much around. I hope that the company who manufactures a product will be more focused on how they can reduce this timeline distance by utilizing Service Virtualization.

If I have an in-house application in place, it allows me to pull information. If I can create an in-house environment manager, then I can go and buy some of the off-the-shelf products from the industry, and then I can do it.

This allows me to have that control of each Service Virtualization asset. It also tells me if somebody has done some sort of ideological testing, or ideological test flow. It will let me know how I can adopt that work flow and add my ideas. Alternatively, I can really go on his idea and tell the developer that the idea sounds great, but it should have been done another way.

Service Virtualization cuts down dependency across dev as well as any third party components. We have saved a lot of round-trip time going back and forth trying to look for environments, trying to look for APIs that might have not even been built, so we already understand what the requirement is trying to build our own simulate and API and try to integrate them.

A lot of technology, a lot of Microsoft services, a lot of support to the functionality aspect of it - they need to mature a lot.

They need to catch-up, as for about four years they did not invest a lot of money on newer toolsets, adapting newer technologies, etc. There have been a bunch of companies that evolved during that time, like CA products and the Parasoft suite of products. These guys have already matured, so now HP is trying to play catch-up. They need to mature and move forward. The technology is always evolving, so they need to move towards that.

• Being able to look at my entire infrastructure from a hardware standpoint, load on top of it, and virtualize the entire infrastructure.
• Manage it with a single pane of glass.

The concept's almost identical on that topic with respect to the old methodologies or legacy practices. You go in and actually install bare metal machines, put a virtualization engine on top of it, and try to do a P2V move. Where today with the new infrastructure, with basically the new HPE 380 or the similar models of HPE solutions, we're able to virtualize a customer's environments in minutes, not hours and days. That's been able to reduce our services cost and improve our customer retention, as well as the customer end-user experience. We've been able to take their environment and bring it online, and then virtualize the environment very fast.

The whole service virtualization concept works on integration patterns, so the service virtualization should be supporting the regular RESTful services. However, it should also support services that listen and reply to MQs, generic JMS, SAP WebMethods integration server, universal messaging, or SAP virtualization database (or whatever virtualization you have, e.g., Java virtualization).

The support for these integration patterns and the ease of use to wizard-based utility is what I would consider the most important features for service virtualization platforms.

It has improve our organization a lot. For example, one of our very recent client's implementations that our Patson USA team did, we saved more than $15 million. This is in confirmed savings. In the past three and a half years of our implementation there, it helps you avoid the environment, get your software to production a lot faster, and reduces the wait times. That means it improves the productivity of your pre-production community. It also helps you in finding defects earlier if you can shift your testing left and integrate your application under test with virtual services.

It is a scalable solution, capable of handling ~3,000 TPS. It supports a wide variety of message formats and transports.

• Shift-Left by enabling Build and QA teams to conduct Development Integration/ API / Performance / System Integration Testing
• Remove wait times for constrained services and speed delivery
• Reduce infrastructure costs
• Eliminate expenses from dev/test access to third-party services
• Reduce downtime risk