More than a decade after Service Virtualization came onto the IT scene, after all the empirical results showing the huge cost savings, speed-to-market benefits and increased quality, voke analyst Theresa Lanowitz says large enterprises still find the leap to SV too intimidating.
In an excellent piece by Alex Handy over at SDTimes, Lanowitz says she finds, “There are many organizations that say ‘I am not ready for this type of thing.'”
Maybe it’s a lack-of-vision thing. Maybe the inertia of old methodology is just too hard to leave behind. Maybe there’s too much cultural resistance in old-style, siloed organizations. I’ve seen all of the above in the business world.
Here’s another theory, drawn from an old aphorism: You can’t eat an entire elephant in one bite.
For the uninitiated, here’s a quick definition of Service Virtualization: It’s software that manifests as a new server (or servers) in a company’s test environment. As such, it has a zillion possible uses and benefits. Foremost, it allows you to know with a high degree of certainty that your apps-in-development are going to work in any traffic environment and with any interfacing component, internally or externally.
That means a bank, for example, knows its new remote banking app will not crash on customers’ iPhones and that a retailer’s POS network will not crash when Black Friday sales bring in the hoped-for holiday hordes. Very simply, Service Virtualization replicates the any imaginable stream of information you want so you know your app will work before you release it into the wild. If you anticipate 10 million people might hit your app, you simply simulate that traffic and see what happens. As we say, it’s like a wind tunnel for your software.
It also allows you to test various components of the app long before completion — and more frequently along the way — because you no longer face the resource constraints long associated with software testing. Developers can test whenever and as much as they want. (Check out our quickie SV101 primer for more.)
With such an almost-too-good-to-believe premise, why aren’t all companies jumping in with both feet? Back to the elephant theory. Maybe the thought of such a radical departure from old-style standard practices is just too overwhelming.
It’s a little like cleaning out your cluttered mess of a garage. It’s easier to just shut the door and put off the task rather than diving in and getting the job done. You can’t imagine doing it all at once, so you do nothing.
But remember the answer to the old elephant maxim: The way to eat an elephant is one small bite at a time.
In the SDTimes piece, Lanowitz suggests that starting out small is a good way to get started.
“An easy way to start is by pinpointing what types of base components would benefit from virtualization. You could say, ‘For anything that is fee-based, we’re going to use service virtualization. What types of third-party assets do we use that we don’t own?’ Virtualize those third-party elements.”
Of course, the services don’t have to be external to warrant virtualization. Lanowitz said that an enterprise could also start out by virtualizing its core services—those that are used frequently across the organization. The more widely used the service, the more likely all the corners of the organization will come forward to take advantage of the virtualized version to test against.
Another way to get started is along your supply chain, said Lanowitz. “You could say, ‘We’re going to start with one project and work across our software supply chain and require everyone in the supply chain use service virtualization.’ ”
But, as CA Technologies’ Stefana Muller points out, starting out piecemeal is not the same as starting small. One good strategy in a large company is to make a splash. Instead of starting on a backwater, low-priority project, pick a project that is high-priority and might even be transformational for the company. That way, other people at the company are sure to notice it, and you end up speeding adoption throughout the organization. IT maven Gene Kim has been among those to advocate this approach for DevOps.
Says Muller, whose company is among the leaders in the field:
“What is your big transformational project? Find one project you can start with that can show you return on investment quickly. It will prove itself there. Customers are dealing with these constraints in other ways: by building throwaway code, wasting time waiting, and spending money to get things done quickly. The ways we help them achieve the benefit of service virtualization is we find the benefit that will change their business. Once you do that with one project, it’s very easy to expand to others.”