10 Reasons Why Service Virtualization Should Always Be Used

So, here we are in 2017. It’s time to make those resolution lists, put new plans into action, and if you’re a football fan, enjoy playoff time! In addition to being the year that the Dallas Cowboys may make it to the Super Bowl for the first time in 21 years, 2017 will mark the 10-year anniversary of iTKO (now CA) introducing service virtualization to the market. I’m not trying to age myself here, but I recall spending the first 30 minutes of customer meetings in the early days explaining the differences between hardware virtualization and service virtualization. At least that is one conversation I don’t have to have anymore!

Although service virtualization has become a widely understood capability in the software application development space (there are even books on the topic — my favorite is Service Virtualization: Reality Is Overrated), where and how to best leverage service virtualization remain questions for many clients. I find myself spending a fair amount of time talking with customers about how they can leverage service virtualization across the SDLC instead of having development build mocks and stubs and having QA leverage service virtualization later in the life cycle.

With the NFL playoffs in full swing, I started thinking: How do the best football teams train so that they can consistently perform at the top of their game? Okay, it’s a given that it starts with each individual on the team being in top shape and working hard in the off-season and in the film room — but as many underdogs have proven over the years (the Rams in ’02, the Giants in ’08, and, of course, the Jets in ’69 come to mind), just having a bunch of pro bowlers isn’t always enough to finish on top. In addition to individual talent, it takes collaboration, a shared vision, and a well thought-out set of plays that the team consistently executes.  

A one-handed diving catch for a touchdown is an exceptional individual play, but it does not form the foundation of consistent plays that a team executes week after week, improving and tweaking as they go, eventually leading them to the Super Bowl. Similarly, companies winning in the application economy have a great set of plays that they are consistently improving and continuously executing. No matter how great your developers are at stubbing and mocking, these are still just individual efforts that can’t be used as consistent plays for your team to leverage every day, week, or month to accelerate delivery and bring game-winning innovation to market faster. 

It’s not that you can’t build a mock or a stub to continue your development efforts, but why would you do it when better, faster tools exist that produce a higher quality output? If you’re using service virtualization anywhere in your SDLC, you should be using it (almost) everywhere in your SDLC.

One of the original uses for service virtualization was to enable parallel development and to let developers create new functionality for their applications to drive new revenue or competitive differentiation rather than wasting time coding mocks or stubs. Not only is developing a mock or stub a time suck — the bigger issue is that the benefit of that asset is minimal and fleeting. Service virtualization should be used at dev time, just as it should be used during the various test phases, and the asset created at dev time should be used at test time. It can be invoked as part of a continuous testing or CI process that leads to the consistent acceleration of applications.

“The alternative was good old mocking and stubbing. At the end, we ended up with CA Service Virtualization, due to its enterprise nature. It played a major role to have a centralized place for simulations where we can maintain, reuse, and extend them.” — IT Professional, Medium Enterprise Financial Services Company

Here are just a few benefits you will receive from using a service virtualization platform that you won’t receive from mocks and stubs.

1. Reuse of virtual services and collaboration across development and testing teams rather than every application team having to create their own mocks and stubs.
2. Multiple ways to automatically create virtual services (service recording, request-response pairs, data-driven virtual services, and Swagger).
3. Complete testing of application business logic.
4. Magic strings and dates rather than static information.
5. Better realism and quantity of performance tests.
6. Rich tools for editing and managing virtual services that cut down on maintenance time and development costs.
7. The enabling of continuous testing by automating the provisioning of virtual services for testing.
8. The ability to virtualize and desensitize test data in early-stage development and test efforts.   
9. The ability to simulate transactions and connections that mocks and stubs can’t: mainframes, databases, and third-party services.
10. Access to more systems and services by virtualizing things that are impossible, or very time-consuming, to mock or stub: complex systems, third-party APIs, and non-web services.

That is why companies serious about the faster delivery of higher-quality applications are adopting service virtualization across the SDLC. For many companies, service virtualization is no longer a technology decision but a business one.

The benefits of service virtualization that is initiated during development and leveraged throughout the life cycle are massive. Any benefit gained from a mock or stub is temporary at best. We have been using the term “continuous testing” for a while now at CA, and it makes sense when you consider how companies should be leveraging service virtualization. 

I may not be able to predict who will win this year’s Super Bowl, but I can predict with 100% confidence that adopting service virtualization will massively improve your ability to get better, quality applications to market faster!