Book excerpt: Success is ‘right there for the faking’ with Service Virtualization
Credit: pixabay.com
Credit: pixabay.com

This month, we’re featuring a few blogs focused on continuous delivery as uniquely enabled by Service Virtualization. (See this blog from last week.) As part of that effort, following is an excerpt from the seminal book on the topic, titled Service Virtualization: Reality is Overrated, that addresses how SV can speed up — and uncomplicate — your enterprise release strategy. (Note: We’ve arranged permission to excerpt the book from time to time, but you can buy the whole thing here.)

While reading this portion of Chapter 14, envision a scenario we’re all familiar with: A major third-party site that’s critical to serving your core business is undergoing a technology upgrade and you get almost no notice. What do you do? How do you test your own apps to make sure they’ll be compatible with the new system? How do you ensure you won’t lose business when the system is upgraded? If you could only virtualize the new service ahead of time … if only you had the ability to test your apps against a simulated environment before rollout …

But wait, there’s a way! Read on to find out how.

Enjoy!

Prepare to Revisit Your Enterprise Release Strategy

Let’s look at a story well-known by anyone in e-commerce and retail. Let’s say you accept credit cards on your site and connecting to that company’s system accounts for a huge portion of your customer transactions. You get a notice of an upcoming major upgrade at the credit card company, and soon after, access to a “test system” version of the new vendor network release that has certain limitations on traffic. You are only 45 DAYS from go-live. Your enterprise is now in a mad dash to adjust and test your own apps in less than 45 days, or your core business is in huge trouble.

But here’s the rub: many of these changes were known months ahead of time by the credit card company—they just weren’t implemented yet. Instead of having to wait to deliver a finished test environment, their thousands of customers could have been given three to four more months to do their critical adjustments to their apps, if the credit card provider had only delivered a Virtual Service based on all the known requirements and API changes to date.

This kind of story is not isolated. It happens in every extended enterprise. Enterprise-wide coordination was not demanded years ago. Application teams were their own islands; they enjoyed mostly independent architectures, and therefore did not have to synchronize changes with other applications. Oh, for those simpler days.

Today’s organizations aiming for the highest levels of cost avoidance, increased agility, and top-line revenue impact have targeted optimizing their entire Enterprise Release strategy. You know, the “big bang” release that drives everyone into an annual frenzy. By using SV across organizations and teams, they concurrently run several development teams in parallel, then bring those many development teams into one integration and test environment for a coordinated release to production.

But wait — Enterprise Releases might be the single most anti-Agile process change we could possibly have adopted! How many times will our development teams be able to deliver a business-critical change in a few weeks—while the next release train won’t be available for many months? Our agility disappears when we force coordination among dozens of applications that aren’t even involved in the task at hand to get each app change delivered.

Screen Shot 2016-07-19 at 10.35.28 PMIn time, even the largest organizations will find that many steps of an Enterprise Release can be optimized away with the effective use of Virtual Services. The next logical step is to enable many more application changes to occur outside the Enterprise Release schedule with pairwise integration testing, instead of building out an entire integration/test landscape for each team (see diagram).

Ultimately, we are convinced that by using SV, even wholesale enhancements to your applications will be safely delivered to production — without requiring massive coordination efforts among applications and teams that shouldn’t even need to be involved.

How many times in your career have you been asked to “get real”? How often have real-world boundaries crushed your best ideas? We happen to believe that Service Virtualization can indeed reset your expectations of reality, at least in the realm of software innovation. Success is right there for the faking. After all, reality is overrated.

CTA-datasheet