the global community for virtual software development and test environments
Events
-
Live webcast: Agile is Dead
June 5, 2013 from 1pm to 1:45pm – http://bit.ly/webinarAgile
0 Comments 0 Likes
Groups
Measuring Risks
What are the risk measurements when implementing a virtual service?
Tags: risk
Replies to This Discussion
-
Permalink Reply by Burt Klein on -
When IT organizations speak of risk from a Service Virtualization perspective, it is usually about the risk of doing nothing and the cost of continuing down the same constrained road they are currently on.
When first introduced to Service Virtualization, most companies want to know how complex it is, how it is implemented and how it’s going to affect their environment and processes.
When I explain how it works, most people realize that it’s not going to have a major disruptive impact. It will, however, give them the tools they need to be more effective in their jobs because they will finally have access to the environments, data and systems they need.
You have to look at risk from both sides of the equation. What is the risk of implementing a virtual service and what is the risk of not implementing it.
-
Permalink Reply by Scott King on -
What is the risk of not implementing it?
-
Permalink Reply by Burt Klein on
-
Without Service Virtualization companies continue to face the same common constraints I hear about from around the globe, regardless of the vertical: speed to market, increasing costs and less than optimal quality.
Those three parameters have been the problem with technology since the 1970s, and without Service Virtualization, they are not going to change. Doing nothing means you are going to stay exactly where you are.
-
Permalink Reply by Scott King on
-
If they hesitate, what are the options to address the constraints you mentioned?
-
Permalink Reply by Burt Klein on
-
The conventional, time-tested way to address constraint issues is to build more environments and buy more hardware, system software and licenses. Then hire enough people to support those environments and code deployments.
Handling data is another issue you will have to deal with. The traditional method is to roll out a huge data test suite, then find the data you need and refresh the records on a regular basis.
Managing the test data is, by itself, a very expensive proposition. I spoke with two companies recently and both of them said they spend over a million dollars a year just refreshing the data for their test environments. And that doesn’t include all the manual time searching for and trying to find good test data to meet the test requirements.
-
Permalink Reply by Manoj Philip Mathen on
-
Burt,
SV or not, doesnt it really depend on your service ecosystem ? Will there be situations , where you really need not invest in very expensive SV tools, instead code out a mock service ?
Are there any alternative to SV using market tools ? Do we have any comparitive study done on these lines ?
-
Permalink Reply by Burt Klein on
-
This is a very interesting question that i hear on a regular basis.
If the application you are trying to virtualize is STATELESS then you do have some options. In a prior role at a fairly large bank in the USA I had a team of developers that was creating and maintaining STATELESS mocs/stubs. These capabilities were the best that were available in 2005-2007 thus we had no choice. The issue was that as a bank we did not do STATELESS business transactions. Let me be very clear - your technical transaction may be STATELESS but we need to focus on the business transaction to be successful. We embraced the ability to purchase a tool to create and maintain our VS's. This reduced the overall headcount necessary to maintain the moc/stubs by 78% (sending the resources off to develop new capabilities rather than the moc/stubs).
Since changing careers to become an evangelist for Service Virtualization I have had the good fortune to meet with over 100 of the global fortune 1000 companies as well as several governmental organizations. In our discussions on Service Virtualization everyone of them has said that their business model are almost entirely made up of STATE-FULL business transactions. We have outlined in these discussions that there are some situations where basic moc/stubs will fill the void. As we talk thru those situations in greater detail it becomes clear very quickly that there are countless risk with doing this approach that can now be overcome with industry tools.
Lets use a basic banking example. We want to pay a bill thru the ecommerce site.
- navigate to the bill payment page
- select the company to pay
- enter the amount
- enter the payment date...
- Click "pay".
- You receive back a message such as "payment posted".
The fact that a "bill pay" transaction worked is good for the basic testing but in reality you should be testing the full business transaction to ensure that you are meeting your client needs/business requirements... Simple example - sign on, account overview, account detail, move some funds, pay some bills, back to account overview then sign-off... You must do this to validate that the bill payments are waiting to be released, funds moved between accounts, the account overview was updated with the new amounts prior to sign-off... THIS is a true business function test.
As to the performance and resiliency perspective you will not be able to predict, with any degree of confidence, the production behavior if you only do STATELESS transactions... Example... Threads being held onto thru the full business transaction... Memory in use between steps... Replication of production response times between steps to ensure SLA's are met...
Most large organizations have a basic mantra when developing systems... REUSE, BUY, BUILD... If you can reuse what you have - do it as you will save on many fronts. Buy a commodity if it is available and as a last resort build it from scratch...
I hope the above gives you the basic background as to the difference between a basic moc/stub and a true SV.
-
-
Thanks for the detailed explanation Burt.
© 2013 Created by Jason English.
