Skip navigation
All Places > DevTest Community > Blog
1 2 3 Previous Next

DevTest Community

227 posts

CA Service Virtualization

Release Announcement

Release Date: 09/24/2018

Release Announcement for v10.4 

CA Service Virtualization v10.4 now GA!

We are pleased to announce the General Availability of CA Application Test and CA Service Virtualization versions 10.4. Three key items being released in this version are a new Jenkins Plugin, Open API 3.0 Support, Apache Kafka and other product enhancements.


Jenkins Plugin: A new Jenkins plugin lets you manage virtual services and provision tests from your Jenkins UI.  The Jenkins plug-in is compatible with CA Service Virtualization version 10.3 and greater.

         Learn more: Using Jenkins Plugin for CA Service Virtualization



CA Service Virtualization Jenkins Plugin


OpenAPI 3.0 Support: The OpenAPI 3.0 specifications are supported when creating virtual services and tests.


Apache Kafka: The Apache Kafka Transport Protocol supports the ability to create tests and virtual services.

         More on Apache Kafka.


Virtual Service Catalog Enhancements: Improvements to the Virtual Service Catalog include the ability to run the virtual service catalog as a service and the ability to view the response header details of a virtual service.

         Learn more from this short video: Using Virtual Service Catalog


CA Service Virtualization_Virtual Service Catalog


Identity and Access Manager Component: The Identity and Access Manager feature is now managing user creation, role creation, and component authentication for all of DevTest.

Important: Please check out our documentation to prepare for upgrading to this new component.


Enterprise Dashboard Authentication: Users are now required to login to view and use content in the Enterprise Dashboard.


Collection of Customer Experience Data: The telemetry feature is designed to help improve our product experience. Telemetry can be enabled directly from the DevTest installer to share product version and operating system information with CA.

         Learn More: Telemetry

A comprehensive list of the new and enhanced features can be found in the 10.4 Release Notes.



Before installing or upgrading to 10.4, you need to request a new license file (devtestlic.xml). Here’s how:

  • Step 1: Have a name and contact email address where the new license file will be sent.
  • Step 2: Contact the Customer Assistance Team for a new license. The process for contacting them can be found here.
  • Step 3: The team will create a new license file and send it to the email address you provide.


Once you have the new license file, you can download 10.4 directly from the Download Management section of the CA Support Site.


To prepare to upgrade to 10.4, please review our documentation.

We are proud to announce the new Jenkins plug-in for CA Service Virtualization available as of August 2018 and can be downloaded directly from the Jenkins Plugins Index []


This new plug-in allows CA Service Virtualization users to integrate directly with Jenkins. This Jenkins plug-in offers out-of-the-box ready-built steps that may be used to trigger actions directly in CA Service Virtualization (Version 10.3 and above), including:

  • Deploy virtual Services
  • Deploy test cases or test suites
  • Start, Stop or un-deploy virtual services
  • Display test result report as part of the completed Jenkins Build Report.


Using the Jenkins plug-in helps automate and control CA Service Virtualization directly from Jenkins without the need to manually call any HTTP API. Jenkins plug-in for CA Service Virtualization provides a simple UI screens to define all of the necessary attributes to perform particular actions in CA Service Virtualization.


This tight integration allows users to easily create automation flows to check-out artifacts from repository, deploy them, run them and act upon the results. This flow  brings CA Service Virtualization even closer to the Continuous Integration or Continuous Delivery flows built using what is now nearly an industry standard in Jenkins Automation.


In addition, Jenkins plug-in for CA Service Virtualization fully supports Jenkins Pipeline support with domain specific commands that can be used directly in Jenkins Pipeline scripts - there is no longer the need to script manual HTTP request and response handling in order to trigger actions on remote CA Service Virtualization systems.


Here is a quick overview video so you can see some of the functionality we are launching today. You can also replay the community webcast on the use of CA Service Virtualization Jenkins Plugin - here.


If you would like to read more about Jenkins Plug-in for CA Service Virtualization you can check out our DocOps page here [Using Jenkins Plugin for CA Service Virtualization]


In order to download your own Jenkins Plug-in for CA Service Virtualization visit the Jenkins Plugin Index page here []


If you have any questions or comments on the Plug-in for CA Service Virtualization make sure to tag your comment/suggestion with the appropriate “CA Service Virtualization Jenkins Plugin” tag on your CA DevTest Community post.


Go ahead and build great things continuously together with CA Service Virtualization and Jenkins. And don’t forget to let us know what you think here on our community.

CA Service Virtualization

Release Announcement

Release Date: 03/30/2018

Release Announcement for v10.3

CA Service Virtualization v10.3 now GA!


We are pleased to announce the General Availability of CA Application Test and CA Service Virtualization versions 10.3. Three key items being released on this version are the Virtual Service Catalog, Enhanced Enterprise Dashboard, and ROI Calculator.


Virtual Service Catalog: We are proud to introduce CA Service Virtualization’s Virtual Service Catalog, which provides a central repository for viewing and sharing all virtual services that have been deployed to a Virtual Service Environments (VSEs) within the enterprise.


Customers can now from a single dashboard, quickly see the available services that are deployed to a VSE and accessible in any Enterprise Dashboard that is connected to the Virtual Service Catalog. This is important because it now allows for a much easier and faster way for teams to share existing virtual assets.   



Learn more from this short video:


Enterprise Dashboard Update: Provides the ability to view more granular transaction and virtual service data within the Enterprise Dashboard by viewing transactions running on specific VSE or virtual service.


Customers have a better understanding on their usage of CA Service Virtualization with much more detailed view of transaction consumption per VSE and by each virtual service.




ROI Calculator Enhancement: Improved the customization and usability of the built in ROI calculator.


Customers are now able to make more granular ROI calculations by:

·        Allowing manual insertion of their own organization’s rates (i.e. FTE Rate).

·        Allowing the exclusion of calculations that are unimportant or may not apply.

·        Allowing users to export ROI calculations, where multiple teams may have their own set of calculations apart from the tool itself.



SV Community Edition to SV Enterprise EditionProvides the ability to deploy a Virtual Service created in the free Community Edition to the SV Enterprise Edition. 







A few other highlights of this currently worth mentioning are:


·        API Functionality Update: Enhanced API Functionality in Test Execution and Reporting.


·        Additional Enhancements:

o   Certification for IBM MQ 9

o   Added support for Proxy servers when recording virtual services through Gateway mode

o   Platform update: Added support for SUSE 12 Enterprise Server SP3, Mac OSX 10.13, Linux RHEL 6.9, Linux RHEL 7.4

A comprehensive list of the new and enhanced features can be found in the 10.3 Release Notes.

Before installing or upgrading to 10.3, you need to request a new license file (devtestlic.xml). Here is the link that walks you through the process - License Administration - DevTest Solutions - 10.3 - CA Technologies Documentation 


Once you have the new license file, you can download 10.3 directly from the Download Management section of the CA Support Site.


Take this version for a spin and let us know what you think!

Business decisions are run by numbers, and these numbers are often compared over time. One of the most important values for making decisions is Return on Investment, or ROI, and it can be a very powerful tool to track value.


SV is valuable because it simulates unavailable systems and applications across the software development lifecycle, allowing developers and testers to work in parallel for faster application delivery, higher quality, and improved reliability. SV greatly reduces costs and accelerates time to market, thereby improving overall investment return. OK, so how do we prove the value of SV using numbers so we can make better business decisions?


Have you heard the phrase “back of the envelope” or “back of the napkin” before? Sure, you have. It’s a way of rounding out numbers and estimating so you can quickly determine a value. It’s useful because it’s fast, easy, and fairly accurate. We’ll use this method to calculate ROI for SV in our example below.


Engineering cost assumptions

Let’s start by calculating the average cost of one engineering hour. You can of course calculate separate software developer or QA engineer costs, but I’ll combine them for simplicity. We can assume their average salary combined is $100,000 and they work eight hours per day. We all know there are 365 days per a year, but excluding weekends and holidays there are only about 250 working days per year (don’t get me started with the Gregorian calendar, leap years, and working nights and weekends to launch a major release). The rest of the time you get to spend with friends and family, mowing the lawn, and ferrying your children from one game to the next. Done! Not too bad, huh?



So far, we have:

Hourly cost per full-time software or QA engineer


Bug fixing costs

OK, so, what about the average cost to fix a defect prior to release? How’d you get that number? Well, there’s no “right” answer. There are several studies and published reports and of course we have recent industry surveys. The numbers vary between sources but not by as much as you might expect.

Obviously, the cost of a bug goes up based on how far down the Software Development Lifecycle (SDLC) the bug is found since it must go back to the beginning to be fixed, hence the “shift left” saying that is all the rage these days. Interestingly, the cost per bug also goes up as quality improves since less bugs are found (but this is not a reason to skimp on quality!). And don’t forget that some bugs take longer or more people to fix than others, so you see this isn’t cut and dry.


OK, then. What do we know? Well, I’m glad you asked! There’s a widely-cited study from the Systems Sciences Institute at IBM claiming that errors cost about seven times as much to fix if found in production compared to pre-release testing (Dawson, Burrell, Rahim, & Brewster, 2010). Barry Boehm explains in his book Software Engineering Economics that an error in the wild is somewhere around 10 times costlier to fix than if found during testing (Boehm, 1981).

Furthermore, CA’s research into public sources has developed an industry average cost ratio per defect at each stage of testing.


This gives us an average of being eight times costlier to fix a bug in production than during testing.


Putting real money behind our example, if a bug found before release takes one engineer 10 hours to fix ($50/hr x 10 hours), the cost to fix the error is $500. If this same error were found at a customer site, it could cost $4,000 to fix. This is because troubleshooting takes time from customers and multiple technical support, development, and quality assurance engineers as it restarts the SDLC.



Let’s add this to our list:

Cost to fix a defect before release


Cost to fix a defect after release



Are you starting to see why testing early and often is so important? It’s more cost effective to test sooner rather than later!


Putting it all together

Now, after just two rough estimates, we can compile a simple ROI assessment! Let’s use SV to “shift left” and assume we found half the bugs reported in production before release when using SV compare to not using SV. We’ll add to our assumptions that we release a new software version quarterly and calculate the total savings per year. We might also say that we will find more bugs pre-release because of more thorough testing and increasing the number of test cases, coverage percentage, or otherwise, but we’re trying to be simplistic. Use your own numbers and try a few different iterations and see what you come up with! Are you with me?


Our assumptions:

Hourly cost per full-time software or QA engineer


Cost to fix a defect before release


Cost to fix a defect after release


Number of defects found before to release


Number of defects found after release





Wow!!! Can that be? We reduced costs in defect remediation due to shifting left, improved staff productivity due to accessibility, and reduced overall time to market due to earlier release!


Did we really save the company $175,000 last year?


YES! Yes, we did! Roughly. Now go show your manager and ask him or her to hire two more developers with the savings so you can improve your ROI even further. Multiply the savings by the number of years you’re using SV. Don’t forget to subtract hardware and third-party licensing costsHappy saving!


Please note, any ROI analysis is only as accurate as the data you put in. Check out our SV Benefits Calculator or use the ROI Tool in the DevTest Enterprise Dashboard to run your own ROI analysis. You can also contact your CA account representative for a more thorough analysis by our specialized team.



The numbers/percentages used to calculate savings are representative of data found across CA Service Virtualization customers and various industry studies/reports. The values expressed are not a guarantee of achievable results and will vary depending upon your current infrastructure, people, and processes.



Boehm, B. W. (1981). Software Engineering Economics. Prentice-Hall.

Dawson, M., Burrell, D., Rahim, E., & Brewster, S. (2010). Integrating Software Assurance into the Software Development Life Cycle (SDLC). Journal of Information Systems Technology and Planning (Vol. 3).

Please join us February 13, 2017 at 11am ET for an informative discussion on proven approaches that bring both the cloud experience and modern DevOps approaches to mainframe development. Hear from leading analyst Jason Bloomberg, Intellyx, and CA DevOps experts Serge Lucio and Jean-Louis Vignaud to learn how you can make your mainframe platform accessible to a new generation of developers, agile in speed of development and automated for faster time to market.

We at CA want to learn from you! 


We want to get insights from you on how mainframe and distributed systems and teams work together in your organization.


When you help us better understand your organization, we will send you a link to a series of educational videos that introduces you to virtualization and automated testing functionality for mainframe that has its roots in distributed systems.

Just click the link below to start the survey.  It should take no more than 5 minutes of your time to complete.


Thanks for your help!


Survey Link: Modern Software Delivery Including Mainframe


We are pleased to announce the General Availability of CA Application Test and CA Service Virtualization versions 10.2. The latest version can be downloaded directly from the CA Support Site, once logged in you will be able to select the latest version from Download Management.


Among the many enhancements offered in our latest release, a few worth highlighting are listed here:

  • Improved Visibility of transaction usage and virtual service count across all VSE’s in the Enterprise Dashboard

  • Self-service high-level ROI calculator 

  • Improvements to Session Tracking and Inspection View.


A comprehensive list of the new and enhancement features can be found in the V10.2 release notes.


We also hope you can join us the DevTest Community Webcast to learn what is new and how to upgrade to 10.2.

Have you ever noticed that it’s the high-performing teams that ask the best questions of themselves? They challenge themselves, think ahead and consistently work to validate team direction and priorities by asking the right questions—frequently. 


For service virtualization (SV), perhaps the most important questions teams can ask are, “What does our organization want our SV solution to look like?” and “What changes should we pursue at key milestones along our SV journey?” Teams that don’t ask these questions early and frequently in their journey and that don’t consider various scenarios will lag behind teams and their organizations that pursue SV progress by openly debating these questions.


Roles and Responsibilities

In a previous post, I pointed to the need to establish a maturity model. Within this model lies the development of roles, templates, processes and procedures that drive the scale organizations desire. Organizations that recognize the importance of establishing rules for delivering SV capability adopt SV more quickly with better alignment to desired business outcomes. These organizations define strategies and establish processes and procedures that address questions such as:


  • Who owns a given service?
  • How is the service federated and supported?
  • What criteria determine whether a service is managed through the service catalog?
  • What is the governance and support model that best suits the way we deliver SV projects?
  • How are skills, infrastructure, knowledge, maintenance and support managed and by whom?



Most organizations create some form of SV federation, but few examine the extent to which they should federate versus manage centrally. Fewer still create a single factory concept that delivers all aspects of SV to other departments. Establishing a federated model is important because it combines strength and scale with the flexibility of autonomy by creating natural divisions of work that maximize organizational investment. Using the list of functions below, think about your organizations and whether federating these functions would provide new benefits:



One approach to defining the most appropriate federation model is to align the functions listed above into a RACI model that maps to the existing organization. For example, skill development and self-learning might be the responsibility of an education department, whereas SV project and program management activities align with project management office functions. The RACI model drives the conversation about role identification and results in development of a potential execution model depicting the best way to support the SV-related activities.


Communities of Practice

More organizations are beginning to understand the value of implementing an online community of practice (aka learning network, domain or practice area) for sharing ideas and improving performance. People need a forum where members can ask questions, exchange ideas, learn from others, and mine SV intelligence to solve issues specific to the organization’s use of SV. In a community that’s limited to your organization, you and your colleagues can share and reuse proprietary information, governance processes and procedures, and sample SV patterns. The community of practice is an integral element of federation and self-learning.


As always, questions and comments are welcome.


Learn more about how CA Services helps customers with their Service Virtualization implementations.


Prior series posts:  Maximizing Your DevTest Investment on Your Way to SV MaturityMaking the Most of Your Service Virtualization Assets; Change Management: A Key Element of Your SV Strategy; SV Requires Transformation at Scale to Drive Maturity; On the Path to Service Virtualization Maturity: Measure Outcomes, Not Output

Hello Continuous Delivery practitioners! As CA World ’17 fast approaches, excitement is building.

If you plan to attend, please visit my colleague krath05 at the Agility Zone, or attend his session on aligning Agile and DevOps initiatives (see below). Also on hand, practice leads for our Continuous Delivery Services, my colleague Raja_Chockalingam and I SummerWeisberg will be hosting customer meetings.

We’re in for a leading-edge conference that’s all about removing barriers between your ideas and your desired business outcomes. Luminaries will share fresh perspectives and show the powerful features of CA Continuous Delivery solutions.

If you’re attending #CAWorld, check out the session list and plan ahead to get into your preferred sessions. Below is a preview of some of the hot topics I recommend. If you have any questions please contact


Automation Tech Talk: Release Automation, Continuous Integration with an Eye on a Strategic DevOps Plan

Wellcare’s goal was to use CA Release Automation to automate software deployments. The company transformed release processes across 24,000 deployments by the end of 2017. This session covers Wellcare’s challenges and outcomes, including saving millions in release costs. An incremental, value-based roadmap and support from CA Services rewrote the way WellCare releases software.

Government in Your Hands: Using Digital to Reduce Costs and Improve the Citizen Experience

The GPM initiative was designed and developed by CA, based on challenges reported by citizens and governments in Brazil. GPM combines CA products and services to establish and provide a better connection between government agencies and their constituents, reducing costs and improving the user experience.

Case Study: Building a Wall Around Sensitive Customer Data: Strategic Insights from Economical Insurance Using CA Test Data Manager and Services in a Guide Wire Environment

Economical Insurance introduced CA Test Data Manager to mask and protect customer data and improve data quality and quantity through automated synthetic data generation. The ability to create robust, on-demand, highly customizable data generated cost savings by minimizing time between request and consumption across the company’s continuous delivery pipeline. CA Services established a Test Data Management (TDM) Centre of Enablement and grew Economical’s TDM team to enable self-sufficiency.

Assess and Guide Your DevOps Journey Leveraging Industry-Leading DevOps Research

DORA, a group of preeminent DevOps researchers, scientists and experts, is the force behind the annual State of DevOps Report. CA has partnered with DORA to offer a unique assessment service for organizations in any stage of DevOps maturity. By leveraging DORA’s expertise and research, the assessment service can help you understand the strengths and weaknesses in your DevOps program, helping you craft a roadmap for achieving your DevOps objectives. You will gain an understanding of how the assessment works and how to create a roadmap to more fully integrate all levels of testing, including security, into your secure software development lifecycle.

Accelerate Your Plans to Become a Modern Software Factory by Aligning Agile and DevOps Initiatives

Initiatives dedicated to Agile and DevOps are largely run on different cadences with sometimes competing objectives. Each transformation needs the other to be successful, and neither transformation can meet its objectives without being aligned with the other. In this session we will share real experiences where we challenged customers to align these efforts and the business results that occurred.

Speaker: Thomas Krall


For related information, check out the #CASERVICES Continuous Delivery blog series featuring a number of posts from J_NeSmith.

I mentioned earlier in this blog series that not many organizations are able to avoid “the adoption chasm.” Even after initial service virtualization (SV) success, organizational progress on the SV journey can stall or regress as organizations undertake efforts to create scale and operationalize. As successes occur, organizations inevitably add governance and process-oriented tasks. High-performing teams are often asked to document more thoroughly. Status reports and deadlines receive more scrutiny. Teams are expected to follow a new set of good practices, and post-its listing tasks proliferate on Kanban boards. The list of expectations and commitments grows, which translates to longer task lists for team members. Leaders tend to generate reports and measure project success based on completion of outputs.

Please understand: I am not discounting the importance of identifying, managing and reporting on SV project commitments. I am proposing that we avoid quantifying SV value in these terms.

Keep Your Teams Focused on Outcomes

Distinguishing between outputs and outcomes may seem like semantics to some and be nebulous to others. A colleague of mine uses this analogy to distinguish the two:

If you wanted to improve your fitness (an outcome), you might purchase fitness gear, join a health club and schedule workouts (all outputs), but these outputs alone would not improve your fitness. On the other hand, if you engage a personal trainer, he or she would ask clarifying questions to define “fitness.” Do you want to improve strength and stamina? Do you want to get closer to your target body mass index? Are you interested in improving heart health and/or reducing cholesterol levels? Answers to these questions help the trainer design a regimen that helps you achieve your desired outcome—improving your fitness. Similarly, the trainer measures your achievements based on your desired outcome, not the number of stations you visit in each workout.

We must understand and communicate the business outcome(s) that SV helps us achieve. Organizations that successfully identify and measure SV’s production against business outcomes will have greater success than those reporting on outputs. We increase the level of stakeholder buy-in when we communicate how SV is helping the business achieve its desired outcomes. The graphic further illustrates outputs versus outcomes:

Look to Metrics for Help

Measuring outcomes can be difficult because it requires connecting SV with business-relevant data. IT teams should rely on their business counterparts to identify simple, trackable metrics that gauge value. However, the metrics must be more impactful than simply the number of virtual services delivered or the number of times a virtual service is used.

Key concepts to think about when defining metrics are:

  • Do not substantiate the value of SV only once. Do it for every SV project.
  • Express metrics as they relate to outcomes. You may have to answer the question “Why are we doing this?” many times to identify the outcome the business is seeking.
  • Use metrics to incentivize and/or create healthy competition among development teams.
  • As part of your decision-making process, measure the potential value of a virtualization against the cost of building the virtualization; SV may be prohibitively expensive in some circumstances.

Develop SV Project Selection Criteria

Selecting the wrong projects can affect team morale and diminish SV ROI. Organizations can avoid many problems by establishing clear SV project selection criteria and adjusting them as needed. Consider these criteria:

  • A well-articulated business problem or challenge
  • Stakeholder sponsorship and commitment
  • The existence of before-and-after metrics for developing value statements
  • A good understanding of complexity and data dependencies
  • Availability of skills and project team willingess to support SV

SV adoption and transformation are personally significant for people involved in these projects. The above tactics can help teams focus on delivering long-term success.

My next blog will peek into federation and communities of practice. Your comments and questions are always welcome.


Maximizing Your DevTest Investment

Making the Most of Your Service Virtualization Assets

SV Requires Transformation at Scale

Change Management: A Key Element in Your SV Strategy

To make genuine, transformative progress through Service Virtualization (SV), organizations should adopt a 360-degree view that connects four critical elements: the technical SV solution, people, process and measurable business outcomes. By explicitly focusing on these elements and how they intersect, teams can develop effective tactics to improve SV maturity, increase scale and derive greater value from their SV investment. Additionally, when teams map the value of SV to business outcomes, they connect SV to business priorities, help validate and demonstrate SV contributions and establish measures for ongoing improvement.

Start with People—Your Most Important Asset

Organizational and individual resistance to change can impede the best plans and greatest opportunities for SV adoption. Organizations can beat this inertia by helping people answer the question: “Why change?” To be convincing, the answers must connect to business outcomes and their value. Some tactics to employ include:

  • Showing how SV aligns to executive priorities
  • Educating line-of-business and IT leaders on ways to communicate SV’s importance and relevance in achieving business outcomes
  • Developing an accountable core team of knowledge experts and deploying them on campaigns that support the use of SV on high-impact projects
  • Identifying processes and methods that impede change within the organization—and eliminating them
  • Allocating resource time to integrate SV into application lifecycle methods and processes
  • Communicating business outcomes facilitated by SV via lunch-and-learn sessions, internal demos and communications.

Process, Process, Process to Drive Scale

The absence of process-related artifacts, templates, and metrics that report value can inhibit organizational success. By creating reusable patterns and templates, SV can be operationalized at scale, thus delivering the greatest value and exposing new opportunities for SV adoption. Formalizing the following activities helps in developing scale:

  • SV discovery processes
  • SV project backlogs and pipelines
  • SV support processes
  • SV skills, learning and self-enablement processes
  • SV asset management and support processes
  • SV utilization metrics, socialization and consumer advocacy processes

Be Driven by Outcomes, Not Outputs

Organizations often find themselves trapped in the paradigm of socializing the value of SV by expressing value in terms of output, not outcomes. Whenever possible, don’t use an output metric to describe an outcome. Consider the impact of project value statements for the same project communicated by the PM in two different ways:

  • Example A: “The team had a virtual service with 900+ million hits and other virtual services with 500+ million hits.”
  • Example B: “We used SV to build better applications faster by ensuring that customer-facing applications could handle expected transaction volumes without experiencing outages and by providing a platform that enables daily performance tests rather than monthly or quarterly tests. Our approach resulted in reducing volume-related outages by 80%, completing performance testing 97% sooner in the application lifecycle and reducing infrastructure costs by $100K per quarter.


In example A, the numbers are measures of output; they don’t quantify or qualify how SV contributed to achieving a business outcome. We can only assume that the results had an impact on the business.


In example B, I can hear executives asking, “How did you do that? Can we replicate these outcomes?” It’s easy to feel the pride and excitement of everyone who contributed to these outcomes and to wonder if the focus on business outcomes motivated them to raise the bar for SV scale and value even higher!


I welcome your comments and questions below.


Links to previous posts:

Maximizing Your DevTest Investment on Your Way to SV Maturity

Making the Most of Your Service Virtualization Assets

Change Management: A Key Element of Your SV Strategy

To sustain progress and achieve substantial business value, organizations should aggressively integrate Service 

Virtualization (SV) into their software development lifecycle (SDLC). In fact, this may be your most important move in driving meaningful change that leads to increasing IT value.


Although this type of change is critical, it can also be overwhelming for many organizations, given the pressures on IT regarding time, budgets, competing priorities, staff availability, etc. Fortunately, metrics demonstrate the value of SV, and these metrics can be convincing when presented to business leaders.


Given the availability of metrics, why do many organizations miss the opportunity to leverage SV to drive change - specifically to transform processes?


Perhaps the reason is that change requires change.


Change is perpetual in IT, which may explain why the industry isn’t short on change management methodologies and practices. It seems that most standards bodies assume that process improvement is a technical challenge rather than a social and cultural challenge. Another perspective is that automation will compel needed change.


A change management function must focus on developing principles, practices and processes that enable organizations to improve software development outcomes by paying attention to the cultural and social aspects of change. Some key questions addressed in change management are:


  • How are data-rich SV metrics used to obtain buy-in at all levels of the organization?
  • How do organizational process changes related to SV mitigate IT risk?
  • Which SV-related change initiatives bring about the greatest organizational value?
  • What process improvement metrics aid in evaluating the success of change?


SV activities and maturity strategies such as business process alignment, staffing and organizational alignment, and initiative identification and measurement intersect with change management. Organizations benefit by identifying a skilled practitioner who understands these intersection points and defines and facilitates the necessary cultural and social changes. Change management activities that focus on the following questions can help:


  • How does change management drive executive and stakeholder understanding of value?
  • How does SV alignment with executive initiatives increase business value and outcomes?
  • What assessment approaches best measure the impact of behavioral changes?


Focusing on these areas helps teams develop a change management ethos that can be socialized across stakeholders at all levels and connects directly to desired business outcomes for SV. One of the best places to start is by identifying a talented SV practitioner or team who can step beyond the technology to link process and cultural/social changes to benefits the organization will experience due to change. In doing so, the SV conversation and its value is elevated to the enterprise. When organizations elevate the conversation, the discussion shifts from a focus on technical outputs to SV’s impact on desired business outcomes.


Stay tuned. The next blog examines people and process changes that help drive the value of SV. In the meantime, your comments and questions are always welcome. 


Previous posts:

Maximizing Your DevTest Investment

Making the Most of Your Service Virtualization Assets

When IT organizations don’t integrate SV into their culture and IT decision-making processes, they under-utilize the potential of service virtualization (SV). When SV is integrated in a holistic manner, SV maturity increases and the organization begins to develop the muscle and flexibility necessary to deliver the requisite scale, speed, velocity, and value that business leaders expect.


In his book, Digitally Remastered: Building Software into Your Business DNA, Otto Berkes identifies IT’s optimization of continuous development and delivery capabilities as important ingredients for building a Modern Software Factory. He notes that robust Agile and DevOps capabilities are essential to driving speed of innovation and responsiveness to deliver real customer value. In the Modern Software Factory era, IT teams—with support from business stakeholders—must:

  • Foster environments where continuous improvement, led or influenced by IT, is always top of mind
  • Create and operate software, and focus on its business value as a core capability—or better—a competitive differentiator
  • Operate in the mindset of developing muscle and flexibility through software
  • Figuratively put software at the center of the business.

The Importance of Defining an SV Maturity Model

Organizations that develop a robust SV maturity model or roadmap and integrate SV into their software development lifecycle (SDLC) are generally more successful. These organizations target low-effort/high-value virtualizations, demonstrate business value using SV, create standardized processes and methods for delivering SV, integrate SV into the SDLC, and find ways to federate SV delivery to move faster and generate greater business value. On the other hand, organizations that under-invest in continuous improvement of people and SV processes miss the mark and undermine the value-generating ability of their SV assets.


Airplane pilots carefully plan flights by incorporating frequent checkpoints to gauge progress and enable course correction. Similarly, organizations should to plan the milestones and activities necessary to continuously improve SV maturity, monitor progress, and correct course as needed. CA’s approach to adoption and maturity establishes a model with customizable sequenced activities that help organizations create scale. This crawl®walk®run approach separates activities into a logical focus areas.


Early-stage activities in the adoption model drive business value, increase knowledge of SV, and create reference implementations of SV artifacts. Middle-stage activities increase utilization and streamline SV delivery; many of these activities focus on people and process. Final-stage activities optimize and deliver SV at scale in the application lifecycle ecosystem. This graphic illustrates some of the activities and focus areas in the maturity model:



SV Integration into the SDLC is Critical

When presented with the model above, customers sometimes ask which activities are most important for developing a maturity model. While they’re all important, failing to integrate SV with SDLC processes and people will impede maturity. Integrating SV into the SDLC enables organizations to identify the points in the lifecycle processes where SV generates maximum value. This enables the constituent teams (business and product owners, architects, developers, managers, quality assurance, etc.) to understand where SV is expected to provide value. Without this understanding, teams are less effective in driving business outcomes.


A related issue is that many organizations have the initial SV conversation in the lifecycle’s development phase—too late to allow time for SV to generate positive impact. SV should be discussed when service needs are initially identified. At the latest, SV should be discussed during the analysis phase, when the service contract is being created or reviewed by an architect.


With the advent of Agile, test-driven, and behavior-driven development methodologies, organizations are striving to shift left. As they do, alignment between SV and the SDLC becomes even more critical. SV touch points must shift as developers and quality assurance personnel work side by side to iteratively deliver features.


While creating a roadmap to maturity and aligning SV with the SDLC are critical, they aren’t the only elements an organization must address to build SV muscle and flexibility. In a future blog, we’ll focus on change management as a key element of SV strategy.


I welcome your comments and questions below.


Related posts:

Maximize Your DevTest Investment

This blog is based on the recent and past request on how to get the Transaction Count by Virtual Service Operation.

PFB the steps required to get the Transaction Count by Virtual Service/VSI Operation.


1. Connectivity to Database to Query a Table which provides the Transaction Count. Database tool or Script to fetch the data.

2. Admin user to modify DevTest property files.


Before the configuration the database table will have the below information:

Transaction as seen on Portal


Steps to Get VS Operations:

1. Shutdown all the DevTest Services.

2. Open and add the following line and save the file:

   lisa.vse.metrics.txn.counts.level=operation[Options available are operation service (the default), operation, or arguments]

This will turn on transaction counts at an operation level. Please make sure that no space gets added at the end of the line.

3. Once the file is saved restart all the DevTest Services. Consume the VS and the transaction count can be seen in the database as shown below: 

In his highly-regarded book, “Crossing the Chasm”, Geoffrey Moore presents a model for broad commercial adoption of new technologies. Moore’s macro-view of the technology adoption lifecycle and the chasm created by new or disruptive technologies has been a guide to many in the IT industry.  Moore’s crossing-the-chasm concept can be loosely applied at a micro-level to customers hoping to drive adoption of technologies such as CA DevTest©. While few (or no?) customers avoid Moore’s adoption chasm altogether, many use fast-track techniques that reduce time, cost, effort and frustration. This series of blogs will share insights and best practices from customers and CA Services – focusing on CA Service Virtualization (SV).


Consider the graphic:

Generally, CA Service Virtualization projects start well and make genuine progress in a short timeframe. Successes in this initial phase cause expectations to track upward. However, when CA Services disengages, some customer teams begin to slide down a slippery slope and find themselves in “the adoption chasm.” Some of the challenges that manifest are:

  • Early successes have caused adopters to prematurely declare victory or shift critical attention away from further developing adoption strategies.
  • Unjustified hope that superior technology results in strong adoption
  • Setbacks after the CA Services engagement ends cause projects to be de-resourced or de-prioritized.
  • Organizations postpone SV training, integration and business process changes
  • Good practices are not engrained
  • Effort and budget expended on implementation and early deployment leaves insufficient resources for high value integrations, solution architecture improvements, business process transformation
  • Metrics describing business outcomes are not developed and reported
  • Operations teams are tasked with both running an ‘adequate’ implementation and discovering, recommending and applying improvements to the deployment


These challenges, and more, result in higher long term costs and greater near-term frustration within the organization.  When one or more of these challenges slows the pace of adoption, a gap, as seen in the following graphics, develops between expectations and delivered value.

Organizations that successfully address these challenges do so by implementing tactics, good practices, and strategies that shorten the trip through the chasm (or avoid the chasm altogether) and produce measurable business outcomes.   


I have observed that through our own transformation and hundreds of successful SV engagements, CA has accrued and developed insights and strategies that help organizations build robust and mature SV capabilities. So in this series of blogs, we’ll share some of these maturity strategies. The blogs will highlight key activities for developing SV maturity and building the scale necessary to consistently deliver the right business outcomes. The series will include topics such as:

  • Making the Most of Your Service Virtualization Assets
  • Change Management: A Key Element of Your Service Virtualization Strategy
  • What Type of Adoption Models Support SV Expansion
  • SV Requires Transformation to Drive Maturity
  • Common Pitfalls on the Path to SV Maturity
  • What Do Federation and Communities of Practice Look Like


Stay tuned for more very soon.  In the meantime, I welcome your comments and questions below.