How to Adopt Service Virtualization Successfully
How to Adopt Service Virtualization Successfully
Check out the four stages of adopting service virtualization successfully.
Join the DZone community and get the full member experience.Join For Free
You may have heard about service virtualization and its power to simulate your test environment and generate synthetic test data, but how do you actually use service virtualization? It starts with being smart about how you adopt and deploy the technology.
You can't immediately jump into a fully-deployed successful service virtualization deployment unless you adopt the right things for the right reasons and at the right times. For more details, watch this video I made to help walk you through it:
It starts with our free service virtualization tool and scales you all the way up to a fully deployed DevOps ecosystem.
Stage 1: Exploration, Investigation, and On-Boarding
Every strategic project needs a starting point, and for service virtualization, that starting point is a free service virtualization tool. By utilizing free tooling at the beginning of your service virtualization rollout, you can focus on building internal expertise that will enable future growth.
By focusing here, the initial rollout of service virtualization can be targeted at an individual who is seeking to unblock themselves from the constraints of development or test environments while, at the same time, building a level of comfort with technology that will become vital as the initiative matures through the organization. These original incubation areas will serve as your most important resource as you move forward with service virtualization.
Stage 2: Targeting Key Areas for Growth
The second stage of your service virtualization rollout should be focused on solving real business challenges. In the initial stages, users will have learned how to build virtual services and familiarize themselves with tips and tricks. They will also now understand the potential traps that could come up when building a simulated service.
So, the second stage will start to manifest as an increase in the number of requests coming from external teams, looking to simulate more complicated technologies. Quite often, we see these as mainframes, databases, ESBs, and other complex stateful scenarios. This is where you will start to get a real return on investment because, quite often, these systems are expensive to replicate, are often shared by multiple teams, and most importantly, represent critical aspects of the business. Because of the work that was done up front to familiarize themselves with the technology, simulating these more complex use cases will be an incremental uplift to your users. It's at this stage that you generally need to upgrade from a free to paid license, to get all of that value.
Stage 3: Teaming, Management, and Maintenance
The third phase of your service virtualization maturity model is all about collaboration, sharing, and reuse. A key indicator that you have arrived here will be when you start hearing conversations about reusing and maintaining existing virtual services. A keyword that is prevalent in this stage is governance. Virtualization governance is all about establishing a center of excellence that can maintain virtualization "rules" (roles, responsibilities, policies, procedures, and SLAs). To learn more about this, view my previous blog about getting to a full-blown deployment of service virtualization as an enabler of DevOps.
Service virtualization can be a bit of a Dr. Jekyll/Mr. Hyde situation. At the very beginning, you want the solution to be very lightweight and flexible so that individual users can unblock themselves from challenges due to dependent systems being unavailable or evolving. In this early stage, service virtualization should not have a rigid governance structure because it can be difficult to simply use it without biting off a huge chunk of responsibility. But as more services are developed and shared, it is essential for the organization to have this rigidly-defined procedure so that you can understand who is responsible for what activities and how to fully own the virtualization initiative.
Stage 4: Integrating Service Virtualization Into Your DevOps Pipeline
Phase 4 is often what I hear as the first thing being targeted when a customer is looking to bring in service virtualization, but it is often one of the pitfalls that organizations fall into, trying to build the deploy-and-destroy dream too early on. Organizations will look at the accelerated delivery pipeline as a key enabler of their software delivery process, and they realize that service virtualization is a critical component in that. The temptation can be that you start with service virtualization by building it into your pipeline, but without building a library of virtual services that can be reused, or having a center of excellence that knows how to rapidly create and maintain those services, this initiative can fall flat.
The fully-deployed DevOps ecosystem is the end goal. Organizations should plan for this state at the very beginning by laying the foundations in the previous three stages. Once the groundwork is set, the realization of service virtualization as a part of your accelerated delivery pipeline simply becomes one of technical implementation. Key maturity indicators for this phase include an increased demand for stable test environments as a part of the continuous testing step of the CI pipeline, as well as an increased demand for test data as a function of service virtualization.
Service virtualization is both a technology and a discipline, and in order to maximize your ROI, your organization will go through a series of maturity phases as you roll out the solution. By understanding these critical phases upfront, you can plan ahead during your strategic initiative and be prepared for both the technical and cultural requirements needed to foster broad adoption and scaling of service virtualization across your enterprise.
Published at DZone with permission of Chris Colosimo , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.