Service Virtualization Implementation Strategies

(1)

Service Virtualization

Implementation Strategies

(2)

1

The Business Benefits of Service Virtualization

No matter what industry you're in, software is increasingly becoming the interface to your business. Organizations that are able to increase the speed and quality of innovative software releases will capitalize on differentiable competitive advantages; those that cannot will languish behind competitors.

Not surprisingly, many enterprises have begun flirting with the idea of accelerating the SDLC to drive innovation through software. However, it’s critical to realize that there's an optimal balance between speed and quality with software delivery—as with all engineered products. We're in an era in which leading organizations must reassess the true "cost of quality" for software. Remember: the cost of quality isn't the price of creating quality software—it’s the penalty or risk incurred by failing to

deliver quality software.

As organizations begin to accelerate the SDLC, process bottlenecks will become evident. One of the bottlenecks that continues to plague SDLC acceleration is testing. At best, testing has been considered inevitable overhead. At worst, organizations have deferred quality processes to their customers, delivering a “real-time user acceptance test.” Psychologically, the malleable nature of software has allowed organizations to defer investment in testing. This results in technical debt.

This is why the concept of service virtualization has become a hot topic. With service virtualization, organizations can access simulated test environments that allow developers, QA, and performance testers to test earlier, faster, and more completely.

Organizations that rely on interconnected systems must be able to validate system changes more effectively—not only for performance and reliability, but also to reduce risks associated with security, privacy, and business interruption. Service virtualization is the missing link that allows organizations to continuously test and validate business requirements. Ultimately, service virtualization brings higher quality functionality to the market faster and at a lower cost.

Implementation Approaches to Service Virtualization

A successful start to your service virtualization initiative can make or break its success. However, there is no magic answer to the question "Where should I start?" Below are several critical things to consider in order to develop the strategy that's best suited to your organization's specific needs.

General Decision Criteria

As you start planning your adoption strategy, it is important to consider the following:

Risk Tolerance

Independently, risk tolerance is a critical component for adoption consideration. The good thing about simulation technology is that it allows you to test applications in ways that were not feasible in the past.

(3)

2

Being able to use simulation to exercise performance behavior and network variations, as well as inject different faults (e.g., security vulnerabilities), enables you to really "shake out" the application. Risk tolerance comes into play when the potential failure of a business application brings severe impacts to the business.

Access to Dependent Systems

If a system or endpoint is difficult to access—due to either geographical or internal (political) boundaries—the results are traditionally either 1) scheduling constraints or 2) the introduction of business risk (when testers fail to complete tests that require access to the system in question).

Availability of Domain Experts

In the case of mainframes, large ERPs (SAP), or older legacy systems, the battle to obtain the assistance of knowledgeable resources can be a limiting factor in standing up a simulated test environment. If a mainframe, large ERP, etc. is in scope of your service virtualization project, the availability of key resources is a critical consideration for adoption.

Configuration Complexity

In a staged test environment or even a server virtualized instance, you still must configure a complete physical application. Although image control can assist with the configuration, it is nevertheless a difficult task to repeatedly perform the setup and teardown required for testing. Service virtualization offers the flexibility to configure the subset of the dependent applications required for the AUT and can dramatically reduce the time and complexity of configuration.

Cost (CapEx)

Some dependent applications will require access fees and/or chargebacks based on usage (time-based or volume-based). Although it is desirable to test against the most realistic system possible, a simulated test environment can dramatically reduce the costs associated with system access.

Overhead (OpEx)

Testing a typical AUT requires access to (and configuration of) multiple systems, and involves the arduous task of aggregating all the necessary variables and data. The knowledge required to set up and tear down these dependent systems is usually distributed across multiple divisions and individuals. The ability to use simulation technology to self-provision a complex test environment will dramatically cut OpEx.

Demand for Broader Test Environment Access

With software increasingly serving as the primary interface to the business—as well as a key business differentiator—the business risk associated with software failure rises dramatically. Testing an application in isolation elevates that risk. As such, organizations have been encouraged to execute broader end-to-end tests, which are traditionally constrained by test environment access. Service

(4)

3

virtualization technology will allow organizations to execute broader end-to-end test scenarios more frequently.

Focus (Environment, Project, Demand, Hybrid)

The best place to focus your initial service virtualization efforts really depends on what will deliver the greatest value in your specific environment. Getting a critical new project to market faster might be extremely valuable in one organization, but another might be better served by eliminating a constraint that routinely slows the progress of numerous groups throughout the organization.

Most service virtualization rollouts are driven by one of the following focuses:

 Risk-based

 Environment-based

 Demand-based

 Project-based

Risk-based

Identifies systems and transactions with the greatest security, privacy, or business-critical concerns, then replaces them with simulated artifacts using data that is known to be secure or privacy-sanitized. Although test data remains one of the greatest concerns, limiting the access point to a simulated artifact (rather than broader system network access) is also a major consideration of using a simulated artifact.

Environment-based

With an environment-based focus, you begin by simulating the lowest-hanging fruit in a particular staged environment, then expand out based on trade-off decisions between time and complexity. This approach can significantly impact CapEx as well as reduce wait time. However, simulating the lowest-hanging fruit might not always sell the organization on the value of service virtualization.

Demand-based

Whereas environment-based looks for the low-hanging fruit in a single staged environment, demand-based looks across an organization for the high-reuse artifacts over many staged environments. From a cost and risk perspective, this might include the consideration of internal and external or business partner demands. The endpoints that are the most difficult and onerous to access across all environments are targeted first, then simulation proceeds down the "demand list."

This approach has the potential to deliver the greatest overall (across the organization) reduction of delays and test environment configuration efforts. However, it is likely that no single team would have access to a complete simulated environment. The demand-based approach tries to do something for everyone, but in the end no single group is completely satisfied. It becomes the jack of all trades but master of none.

(5)

4

Project-based

Here, the focus is on eliminating constraints associated with a particular application under test in order to test more completely. This is the route you want to take if you have a critical project where

accelerating time to market is critical. What you need to simulate is clear since the scope of the dependencies is well-defined within the context of the application under test. The advantage of this approach is that all resources involved in that project gain access to a complete test environment. However, you could run into issues with expansion. If the implementation is architected expressly to meet the needs of a specific team or project, rework might be required to make the resulting virtual assets valuable to the rest of the organization.

Hybrid

A hybrid approach mixes and matches elements from two or more of the above focuses. For instance, an organization with an extremely complex new project might take a demand-based approach to simulating dependencies associated with that project.

Team Structure

Team structure is another important—but often overlooked—consideration. You want to ensure that the way you structure your team and the focus of your implementation are complementary. You'll want to look at what works in your organization, whether you have a high or low propensity for collaboration, and whether there is a balance (or imbalance) of power among teams.

Distributed Team Structure

In a distributed team structure, you have multiple autonomous teams separated by geographical (and

sometimes "political") divisions. Virtual asset reuse/access is controlled on a by-request basis.

Best Focus Fit:

(6)

5

Strengths Weaknesses

 Centralized focus on individual teams' constraints

 Opportunity to invest in more detailed scenarios

 Faster value recognition due to scope limits

 Variable success

 Limited reuse

 Risk of variable deployed architectures

 Risk of break down in downstream processes

 Risk of each independent team testing against their own assumptions

 Limited value to parallel development efforts

Center of Excellence Team Structure

There are multiple "flavors" of Center of Excellence roles. Whereas some take an advisory approach to promoting best practices, others assume more active control over all aspects of the implementation. If the organization is not used to following the recommendations of this CoE, allowing them to drive adoption will be an uphill battle.

Best Focus Fit:

 Risk-based

 Demand-based

 Opportunity to execute pre-determined best practices

 Can best address organization risk factors

 Harmonized approach to process

 Can enable continuous improvement

 Can blend approach with broader test environment automation technologies

 Change and version management easier

 Enables the risk and demand based approach

 Limits simulation depth and might not offer incremental value

 Limits simulation breadth and might not remove constraints

 Can hamper value, adoption and ROI

 Must have more “governance” and process defined up front in order to foster adoption (rules of engagement)

(7)

6

Hybrid Team Structure

Hybrid teams blend the above two models. They tend to have centralized version control of virtual assets, but still allow distributed control over granular behavior. For example, if the team needs a shared virtual asset to cover an additional use case, they have the freedom to augment the virtual asset to meet that testing need—without altering the asset's

behavioral integrity. This "structured freedom" promotes a central management of core functionality, yet allows the team to expand their test coverage to mitigate specific business risks that are associated with their application. Best Focus Fit:

 Any

 Flexibility

 Gives teams a layer of control on top of defined best practices

 Teams can be “laboratories of

experiment” for the evolution of internal best practices

 Potential for erosion

 Potential for entropy

 Weaken CoE authority

 Potential for extra management burden

About Parasoft

Parasoft researches and develops software solutions that help organizations deliver defect-free software efficiently. We reduce the time, effort, and cost of delivering secure, reliable, and compliant software. Parasoft's enterprise and embedded development solutions are the industry's most

comprehensive—including static analysis, unit testing, requirements traceability, coverage analysis, functional & load testing, dev/test environment management, and more. The majority of Fortune 500 companies rely on Parasoft in order to produce top-quality software consistently and efficiently as they pursue agile, lean, DevOps, compliance, and safety-critical development initiatives.

Contacting Parasoft

USA Phone: (888) 305-0041 Email: [email protected]

NORDICS Phone: +31-70-3922000 Email: [email protected]

GERMANY Phone: +49 731 880309-0 Email: [email protected]

POLAND Phone: +48 12 290 91 01 Email: [email protected]

UK Phone: +44 (0)208 263 6005 Email: [email protected]

FRANCE Phone: (33 1) 64 89 26 00, Email: [email protected]

ITALY Phone: (+39) 06 96 03 86 74 Email: [email protected]

OTHER See http://www.parasoft.com/contacts

Author Information

This paper was written by:

 Wayne Ariola ([email protected]), Chief Strategy Officer at Parasoft

 Cynthia Dunlop ([email protected]), Lead Technical Writer at Parasoft

All rights reserved. Parasoft and all Parasoft products and services listed within are trademarks or registered trademarks of Parasoft Corporation. All other products, services, and companies are trademarks, registered trademarks, or servicemarks of their respective holders in the US and/or other countries.

Service Virtualization Implementation Strategies