Summer vacation and Service Virtualization – what do they have in common?

Ah Summer!  Love the warm weather but it's not always conducive to blogging...  I’ve been meaning write about HP’s new Service Virtualization software release, version 3.0, which became available in June. Unfortunately, a combination of a long-planned summer vacation and now a very productive week at the Agile2013 conference delayed me (I know, excuses, excuses…). 

 

In between June and now,  HP has released Service Virtualization version 3.01, which adds some key protocol support, resource management and ease of administration capabilities on top of the array of new features in Service Virtualization 3.0.  This is good stuff for the SV user.

 

But before I get into what’s new in our latest Service Virtualization release, I want to take a step back and discuss why I think Service Virtualization is becoming a must-have tool in any Agile development and testing team’s toolkit.  To visualize this, let me start with my summer vacation story.  

 

July is actually a very busy time for me and my team, as we are gearing up for a number of activities in early fall, which require new strategies, content and solutions. This year, I found myself in a position of being on a critical path for a number of these activities.  I knew if I went off-line for three weeks, there would be several team members waiting on me. They would need me to provide the first draft, the outline or the approval of a budget.  Because this would both be wasteful and potentially risky to our fall plans, it became critical that I found people I could train up, provide guidance to before I left and have them do the work in my absence.  And, in most cases, it worked. There was one situation where a downstream system would not accept the “virtual me” to approve a budget ask.  In that one situation, we encountered a delay; but for the most part, work continued even without me being here. As a result of now having the ability to be in two places at once—we will hit our goals. All while I was basking on the beach in San Diego and hiking in the mountains of the Eastern Sierra with no cell coverage!

 

 avacation.png

 

Can you really be in two places at once?

 

Now, let’s apply this concept to the reality of today’s complex, composite application environment and the distributed teams who work in it. These teams are faced with short iterations to deliver new working software, enhancements, new integrations and more. 

 

Here are a few common scenarios. How often have you run into them?-- An Agile team is working on a user story where new functionality has to interact with data on an existing production system (think a new e-commerce app where the customer look-up function hits a production SAP server for instance).  But the SAP team cannot grant access to the SAP system for four days and then only for a two-hour period. This means a delay for the Agile team and presents a risk to their sprint schedule.

 

Let’s imagine I was the “production service” and my team had to wait for a two hour period on the fourth day of my vacation to get feedback or approval from me to move forward—very inefficient!

 

-- A team needs to test a new capability that makes a call to an API provided by a cloud service broker (think FedEX service for shipping or credit check service in the cloud).  How do they get access?  What if they also want to test load—meaning thousands of calls to that service?  How costly will that be?  This scenario means certain delays and costs or just not testing against the service at all—which is a huge risk to take.

 

 adelay.jpg

 

What happens when external organizations are involved?

 

A parallel example from my vacation pertained to external vendor project spend approval. I gave a member of my team delegate authority to approve new projects or spend with our external vendors. This meant that projects didn't have to wait until I came back.   If I hadn’t done that, any project that had a dependency on an external vendor would be stuck.

 

-- Let’s say another team needs to test their user story against a service being built by an adjacent Agile team that isn’t ready yet. They have a spec but the coding isn’t done. Once again this leads to delays.

Parallel to my vacation, I delegated some content creation to team members so that projects didn’t have to wait until I came back and did the writing myself. Ghost writing was an excellent proxy!

 

Service Virtualization addresses each of these challenges for Agile teams that need to deliver quickly without sacrificing quality. Here’s how:

 

-- Teams can create a virtual service of a constrained production system.   A virtual service can be created by record/replay, data model introspection, or IDL introspection. It can then be stood up, tested and adjusted as needed using a powerful, yet visual, developer environment. Once the virtual service is available, it can be published for use across many teams.  With HP Service Virtualization 3.01, we’ve added support for a number of SAP protocols and connectors and integrated Service Virtualization with HP ALM to manage publishing and access, not only within a team but across teams.

 

-- Teams can create virtual services that stand-in for Cloud and third-party services. This capability enables dev and test teams to perform functional and load tests that need responses from cloud services where costs or access is prohibited. Since a virtual service can be created from design documents as well as from actual record/replay, the team doesn’t even have to touch the actual cloud service API. Flip this around and Service Virtualization adds value to cloud service providers as well, by providing virtual versions of services for their consumers to use for testing, without disrupting the production version.

 

-- Teams can continue to progress even in aggressive sprint timelines. Now you can make progress without having to “get all the ducks lined up”.   If a team is dependent on another team’s code, the other team can set up a virtual service based-off of a design for dev/test, this no longer requires the “hurry up and wait” scenario.

 

With Agile teams running at sprint speed and the pace of new technologies and consumer expectations, it’s hard to imagine a working environment without the help of service virtualization. In a customer example, a large telecommunications firm was able to remove close to 100 percent of their dev/test wait time with Service Virtualization. Here their story in this short podcast.

 

Want to learn more?  Read about HP Service Virtualization here and download our latest version. And next time you go on vacation, rest easy, your virtual services will keep your dev/test teams on track.

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Kelly has over 20 years experience with enterprise systems and software in individual contributor and manager roles across product manageme...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.