The ITKO Blog: Service Virtualization and Application Lifecycle Optimization - CA Technologies

Addressing a Lack of Capacity in the Performance Lab - Webinar 6/24

If there ever was an easy reason to adopt Service Virtualization techniques, it would be the performance lab. We are seeing customers reckoning with this problem over and over: highly skilled performance testers, with expensive lab infrastructure and software, WAITING around to access needed resources to do their job and ensure expected software performance levels.

In a couple weeks we are doing a big webinar on IT Briefcase with our partners Accenture: "Addressing a Lack of Capacity: Virtualizing the Performance Lab for Optimal Results."

The free session is June 24, 2010 1:00 - 2:00 pm, Central Time (2-3PM Eastern)

I am presenting with Accenture Partner Scott Gilliland, who runs the Global Performance Engineering practice for the firm, with experts who have already implemented these tactics to some incredible results at our joint customer sites - we are talking increasing the amount of performance testing done to go well beyond 6-Sigma reliability, at less 25% of the existing labor and infrastructure cost.

Today's applications are more distributed and complex than ever - and that makes for an entirely new economy around needing high performance that can't be ignored. Fail to perform, and you will certainly lose customers. Scott will expertly describe the financial reasons for eliminating constraints from performance testing.

What's interesting to note is that we usually find that performance labs are acutely aware they have idle time waiting for assets to run their load tests against, and wasted effort on coding simulations. But they don't know what these inefficiencies actually cost the business - until now.

Short of building a copy of the whole enterprise's software infrastructure for each test lab (which can cost millions for a typical F1000 enterprise), and manually coding all of the dependencies (such as mainframes owned by other divisions or partners, SaaS providers, Cloud-based services) needed to respond to the performance tests, there is another way to achieve a realistic environment that is truly elastic.

Service Virtualization captures and creates a realistic, highly scalable and responsive version of virtually any system the Performance Lab needs to connect to, using whatever tools they currently use for load testing - whether that is HP Performance Center (LoadRunner), IBM Rational platforms, Micro Focus' Segue tools, or some of our own system-wide or Web 2.0 test & validation apps.

These virtual services become assets that look and act exactly like the real thing - but they are very lightweight, low cost simulations, with very stable data scenarios, adjustable or variable response times, and the ability to be ready for reuse 24/7 at a moment's notice. The resulting virtual performance lab allows these software to be continuously performance tested at a component level, ensuring that when the pieces come together, they exceed SLA expectations.

Let's define a goal together: No more constraints on capacity in the performance lab. Hope you join us June 24 and find out how to get there.

News Today: iTKO Teams with IBM for Application Virtualization in the Cloud

News flash (5/6/2010) - today from IMPACT 2010 we announced a new solution offering with our partners at IBM. Known as IBM Application Virtualization Services (or "AV"), this solution takes what LISA does well (Virtualization, Validation, Testing, Defect Resolution), wraps it with IBM services and technology, and makes this offering available on premise, or through an IBM Cloud platform, to solve critical customer needs.

• Press Release: "iTKO Teams with IBM on New Cloud Service to Help Clients Rapidly Deploy Applications"
• Download the Datasheet: "iTKO/IBM Application Virtualization"
• For more, see our Solution page for Application Virtualization

AV presents a highly differentiated solution to our joint customers, a solution that will revolutionize the way companies with distributed teams and technology components can build their applications. It's all part of a vision that goes beyond considering where software is deployed, to solving the root challenges of first successfully doing Development and Testing of that enterprise software where it will live in the Cloud.

Cloudy Chalk Talk 2: Dev & Test Clouds in Pre-Production

To continue our series on Cloud Application Chalk Talks, our "chief geek" John will cover Development and Test Clouds. After the move toward commoditizing some hardware and capacity in Public clouds, we find that the next logical step is using Clouds to level off Pre-Production costs throughout the software lifecycle.

Capacity in Production is fairly easy to predict, but it is hard to predict in Pre-production. You can plan to make capacity for spikes and volume and provision your infrastructure if you are an eCommerce vendor getting ready for the next Christmas rush. But what if you could eliminate 80% of the unpredictability of the Pre-Production environment that hundreds of skilled developers and testers use, and therefore not need to buy all that capacity up front? Private/Public Clouds are a great way for our partners to pool together computing resources into Private Clouds, use Public Clouds for overages, and try to regulate their infrastructure costs (compare oh, $.06-.12 a CPU hour of private/public capacity vs. $2.00 for each team using dedicated systems - and you see the economics).

So what happens next? We'll cover how companies are dealing with those "spikes" in capacity and cost, as well as the hidden costs that you don't usually hear about in the standard arguments for employing Cloud Computing and Virtualization in pre-production.

Employing Virtual Environments for Manual Testers: It Still Doesn't Suck

Here's a brand new article in Virtualization Journal: Employing Virtual Environments for Manual Testers from one of our expert architects, Andy Nguyen.

Here at iTKO, we evangelize virtualizing and automating the entire software development lifecycle. While manual testing is a topic we don't cover as often - Virtualization of Manual Testing labs is a really cool thing that can add a lot of value in any large IT organization. For every development and test automation expert in an enterprise, there can be a whole team of on-site, partner, outsourced and seasonal testers sitting idle - waiting for access to a valid, configured test environment to run their scenarios against.

This article contained a cartoon - you might remember our distant history when we advertised the claim that "Your Testing Sucks" - and nobody ever disagreed with us. So here's the comic by Sal Monella:

Service Virtualization is the best way to solve the above constraint for Larry Lamprey, not buying more hardware or conducting laborious, expensive custom setups of a multi-tier environment behind the UI for testers.

Manual testing is never going to disappear, as someone will always be expected to test application UIs for user experience, etc. However, to eliminate downtime from testing, and conflicts over limited available test environments, ALL testers can use a Virtual Service Environment (VSE) to stay productive. Virtualization of those setups and data scenarios also delivers a huge productivity boost.

Why Stubs Don’t Work: Part 2 – Performance & Virtual Services

[This is the 2nd Part of John's article on "Why Stubs Don't Work." For "Part 1: Producers & Consumers" read here.]

The last (but certainly not least important) audience that must weigh Stubs versus Virtual Services, is the Performance profiling team – the folks charged with measuring and tuning an application to meet customer expectations or SLAs in production.

Of course, a developer creating a stub “responder” would write that simple object to return a given response as quickly as possible. Yet, many of the most complex scenarios that would want to consume that stub are in the performance lab – so the team can do capacity planning, and get a feel for how the targeted application will perform or behave, before it’s all fully assembled and delivered to production.

You need a pretty sophisticated instrument to vary the responsiveness and handle all the variety of performance profiles that are needed to support tuning.

For example, I may have “What-if” scenarios -- where I want to performance test my system, with all the back-end services stubbed out. Now, I want to see what happens if those back-end systems respond 20% faster, or, 20% slower than they are supposed to be. With a stub, I can only get an immediate response about as fast as the network can deliver it, which is unfortunately not how the live downstream system is going to perform. 

And I certainly don’t have the ability to vary that performance in an “adjust the slider” kind of way – not without, again, building a pretty sophisticated framework for that simulation. And this creates – you guessed it – a whole group of people charged with coding stubs to respond at certain times or with certain payloads. There must be a better way.

Thus the need for LISA Virtualize, and Virtual Services.

Virtual Services are the technology we built on top of the LISA Virtualize framework to bring dynamic behavior to this functionality. LISA Virtualize allows Virtual Services to be automatically modeled or captured from live traffic, flat files or definitions, and then quickly adjusted for data or performance characteristics without coding. Here's a basic picture of how that happens:

Virtual Services have proven, time and time again, that development teams can get out of the stubbing business, and that consumers of these services can take control of their own destiny, and produce their own Virtual Services instead of waiting for a stub.

That’s important, because the producer or Developer of a given service should not be responsible for infinitely providing stubs to Consumers -- every Consumer is going to have their own requirements, and need to validate different scenarios for how they use the service. If there is only one stub available, then consumers will be missing the responsiveness they need.

From the other side of the equation, if Consumers are responsible for building their own Virtual Service models from downstream services, they will understand the kinds of performance levels, data scenarios and business processes they need to validate. And, they would know better how that service would need to integrate for their required scenarios with other downstream systems that are available.

Conclusion: The Tipping Point for Virtual Services is here…

Just like the “roll your own” database I used to make years ago, the requirements for this functionality have reached a tipping point. Once the requirements for stubbing or mocking reach the point where they become an item in your project plan, with an associated timeline and resource cost, you need to think about productizing and looking for solutions rather than building one.

One of the largest telecoms in the world, and a company I respect greatly, was talking about this in their Architecture Review meeting a few weeks ago. I was there, and one of their resources said “I hear where you are coming from - we thought of stubbing and mocking as a simple activity, but we have now evolved an entire career path out of people becoming simulation developers!”

There were literally scores of people whose work function was architecting, developing and maintaining simulation artifacts, or “stubs.” Think about it – what company (other than a couple software vendors) would split off an entire category of developers to go build their own database? The person who runs technology for this entire telecom would not make that kind of investment, without serious scrutiny for finding a better solution off the shelf.

So this is the awkward tipping point we find ourselves in today, moving from stubs and mocks to Virtual Services. People who have been building stubs for a long time out of necessity, are finding it harder and harder to keep this up. Our LISA Virtualize happens to be the first (and, without exaggeration, the only) solution on the market to handle this particular challenge.

Now customers are doing the math -- and rationalizing how we used to do it versus this new paradigm with Virtualize. By no means will Virtual Services create a career problem for so-called “simulation developers” either – I have yet to encounter a profitable enterprise that is seeking to do LESS development, or deliver LESS functionality to the business.  What ends up happening is better aligned development to the business needs, both within the company, and with partners. That is of course the goal of any healthy IT organization.

Long story short: I hope this provided some useful perspectives you can apply when thinking about using Virtual Services versus stubbing and mocking in your software development going forward.

Why Stubs Don’t Work: Part 1 – Developers & Consumers

I’m frequently asked what the difference is between what we call a Virtual Service, and what developers have done for years, which is “stubbing” and/or “mocking out” a particular service. There are a number of ways I can address this, depending on who I’m talking to.

 First, for the Developer, I’m going down the path that Virtualization is now taking on the task of industrializing or productizing the practice of stubbing itself. Some 20 years ago, when I first started development, I wrote my own database, wrote my own development tools, my own middleware to get components to talk to each other – in fact, I used to code all kinds of things that today, I would never even dream of building anymore.

The requirements for proper databases and middleware became advanced, so that it was no longer feasible for developers to roll their own. Instead, those requirements became a category of software, and vendors started delivering solutions for that space, thus we saw the rise of a database market, and a middleware market, and so on. We see that the requirements for simulating components have become too steep to roll your own. So in that light, we see Service Virtualization as essentially the “space” that is coming out of the requirements of stubbing and mocking.

The second answer I would give, more often to the Consumer of a stub or mock is just how brittle these stubs or mocks have to be in order to be efficient. The whole reason why a team would construct their own stub is summarized as: “I don’t need a product for that, because it is something I can make quickly and easily by myself.”

Well if the goal is to do something quick and easy, the best you will be able to do with this artifact, is do a “round trip” to the stub, to prove connectivity of a particular application to that stub. In reality, there is so much more detail needed by the consumer of a service, that calling it “something you can mock up quickly” means you don’t understand the true nature of the problem.

Let me explain: If every customer response for a stub has the exact same profile, and the exact same address, account balance, etc. all with hard coded values and dates, then that may help the consumer of that stub with ONE data scenario. But, what about customers with high account balances? What about old invoices? What about transactions that occurred yesterday – and will they work the same tomorrow when that date becomes 2 days ago?

The problem with a stub that has static data, is that it won’t support the real variety of scenarios that are needed for a real world application. And you can’t just randomize the data – that would be even worse!  Consumers need predictability and control over the data they’re seeing. And they need to integrate that data not only from the simulated application, but from all the other services that might be associated with that particular application they are building.

A simple example: Say you have customer lookup in one service, while you have account management in another service. So if you have Account IDs and Product Codes and Balances that are not aligned properly between the two systems, you will have an application that fails, either at the consumer level, or somewhere in the downstream systems.

When you think about data required to support development in this scenario, stubbing a system simply doesn’t hold up. Considering all the things you would have to do to make that stub more real, you would need a pretty sophisticated framework to build those stubs. So you might start out building stubs, thinking “it’ll only take a few hours,” but you end up taxing your whole project plan with the hidden cost of building the first generation of a stub, and then modifying it over and over again. And by the way, they don’t even work very effectively.

This is part one of John's discussion on "Why Stubs Don't Work." Read part 2 of the blog, where he will discuss Performance Lab uses of stubs, and the "Tipping Point" for moving from stubs to Virtual Services.

Question: Are Pre-Prod Environments Balooning while Production Infrastructure Shrinks?

I recently posed a question to eBizQ and got some good answers, both reasonable and unexpected perspectives. See my eBizQ SOA forum question here: Are Servers Bloating in Pre-Production, but Shrinking in Production due to SOA?

K. Scott Morrison and Joe McKendrick discussed how Virtualization is a tester's best friend in reducing this phenomenon - and yes we have seen virtualization of hardware reducing some infrastructure needs. What about the ones you can't virtualize? I vote the best answer (received by 5:00PM CST) goes to Avi Rosenthal, whose comments highlight why this phenomenon is happening:

"In distributed Service Based, Virtualized and Cloud based environments the number of other environment servers is skyrocketing vs. the number of Production servers. This is true as well for virtualized server instances. The reason for that phenomenon is that Production environments are more controlled because no one can allow uncontrolled Production. The risks of non controlled Development or Test environments are less obvious. As the number of instances grows the number of servers in the non-controlled environments grows more rapidly than the number of servers included in the controlled environment. However, logically the number could be reduced at least to a ratio of 1:3 or 1:4 and not 1:20 if the non-Production environments will be managed and virtualized similar to the Production environment."

Really good point Avi.

However HP's Kelly Emo then came up with the gist of an issue I wanted to address further: the huge rift between measuring costs and effort for Production vs. Pre-production environments. It seems these activities are usually owned by two completely different departments and cost centers within the enterprise as she notes:

"In a majority of customers I speak with, their organization, culture and funding models are no where near having this happen... different silos are managing hardware and software resources and different SLAs are associated with them. In fact, in some cases, SOX compliance keeps organizations from being able to mix and mingle their networks and data between pre-production and operations. That said, I see one place where this can happen.. in the cloud..."

That's a next-generation view. Indeed the cloud is a big piece of the puzzle. However, many of the companies who get excited about the value of deployment savings using VMs and Cloud-based infrastructure to replace servers, simply do not have a reason to care about the number of groups maintaining and consuming dev, test and integration environments.

 The same goes vice-versa for pre-production - when you break up development into smaller, agile dev & test teams, those teams each provision and set up their own hardware and software environments in a largely unregulated fashion - and often find out that there are many dependencies they can't copy or replicate via conventional means. This leaves a lot of cost and effort unaccounted for in the wash of the software lifecycle, or as a cost of per-employee infrastructure or support.

You will see a lot more on this topic from us - while we aren't in the business of virtualizing servers and hardware, we are particularly curious about why companies aren't recognizing the value they get by optimizing Production vs. optimizing their infrastructure at every step along pre-production. Is a ballooning number of servers a side-effect of distributed, agile approaches, or is the symptom we are reporting simply a matter of perception? We'll keep you posted as we do more research in this area.

Webinar: No "free beer" in Service-Oriented and Cloud-based Applications?

We have harnessed the flexibility of readily available services, which can be assembled into business processes, and provisioned on Cloud-based, pay-as-you-need infrastructure. But despite our best expectations, there still is no "free beer" available in service-oriented and cloud-based applications for the enterprise.

What's raining on our parade? Someone has to pay to make sure that as we increase the number of distributed software components and processes, that the combined slurry of services will perform and function as expected by the business.

Face it, we are caught in a conundrum. While we can develop and assemble new business processes faster than ever from components, we also must deal with the fact that the rate of change and complexity of business software is only increasing. Every new service we connect to has the potential for failure. With that, the quality assurance effort and infrastructure cost of assuring reliable delivery of enterprise applications is also ballooning exponentially.

Let's turn the lights on, and discuss why the advent of SOA, BPM and Cloud Computing approaches, while a good thing on so many levels, also increases risk and cost. And maybe along the way, we will find some practices like robust automation and Service Virtualization that may get us closer to AFB (Almost Free Beer) -- readily available Virtual Test Environments, and increased reuse, so we can improve performance and quality with a much smaller incremental cost.

We are excited to present an upcoming "dual continent" webinar March 3rd for Europe and North America, featuring our partner Accenture's John McEvoy, head of EMEA testing, and our founder and Chief Geek, John Michelsen.

Webinar: "No Free Beer" in Modern and Cloud-Based Application Performance and Quality - http://www.itko.com/resources/webinar_accenture_mar2010.jsp.

Hope to see you on the webinar, and bring your questions for John and John.

Chalk Talk: Service Virtualization 101

Time for the next installment of our iTKO Chalk Talk Series. What is Service Virtualization and how is it unique from existing forms of hardware virtualization? iTKO's John Michelsen provides an updated primer on the practice of virtualizing the behavior of constrained systems.

iTKO Chalk Talk - Service Virtualization 101 - John Michelsen (3:30)

We have found a greater understanding in the IT community over the last year of how Service Virtualization is a next logical step after the value companies already achieve with Hardware and OS Virtualization. Service Virtualization solves for the kinds of applications you can't easily replicate and drop on a VM for use while developing your own apps - they could be third party Services that you don't have control or access to, "big iron" systems like mainframes and systems of record, and even components that are under development.

 

News Today: iTKO's LISA is Ready for Rational

[Official news commentary] -- This morning we put out a press release regarding how we are extending LISA’s value and capabilities to IBM customers. You can read the news here:

iTKO Press Release January 19, 2010: iTKO Achieves Ready for IBM Rational Software Validation

LISA achieved a “Ready for IBM Rational” validation with a Best Practices designation, meaning that LISA integrates seamlessly with IBM Rational Quality Manager. In the press release we talk about how LISA complements the IBM Rational platform, and that our IBM partner status got upgraded to Advanced due to increased customer engagements and wins.

The progress is significant - over the last 2 -3 years we have experienced a lot of interest from the Quality Management space for using LISA Virtualize and Validate to eliminate constraints from testing, by virtualizing the behavior of services, middle tiers, web portals, databases and other components in modern architectures.

Today's applications have many components that are too large, or not accessible for copying onto new test lab hardware, or conventionally replicating via a virtual machine. For joint customers, this makes Quality Management solutions like Rational even more productive, while increasing efficiency in the hardware-based test lab environments that support them. The benefits of Virtual Services are even more evident in Cloud-based development and test environments.

Read further information about iTKO's other LISA Solutions for IBM's enterprise integration and development platforms, such as WebSphere, WMB, MQ-series messaging, DB2 and more.

Insurance Case Study: Managing a Virtual Performance Budget

We just published a new case study from a leading Insurance (Property & Casualty) provider, which we think neatly outlines the advantages of using Service Virtualization to help manage performance of a complex, multi-tier application.

In this example, the company basically breaks apart an application-wide Performance Test into all of the steps that make it up, and assigns a target time for each step that makes up that application workflow. The decomposed target time for each step makes up a "Performance Budget" that contributes to the overall performance time.

Without decomposing the performance budget, you get no visibility into which element of the application is causing the hit on response time - you only know the End-to-End response time is not up to snuff (4.0 seconds here vs. expected 2.1 second response time for customers).

Given that, the first impulse of the performance tester is often throwing more hardware at the test lab, trying to get that speed up. This may help a little but it usually misses the mark in pinpointing the real time hog underneath the surface.

This is where we apply Service Virtualization - to virtualize the Behaviors of each of the component services in the end-to-end workflow. Behaviors in this sense are not functional, but they are the realistic response times of each component when subjected to load. By virtualizing the components around your component under test, you can figure out which one needs tuning, and which ones aren't creating performance problems in the overall application. We think this customer employed the practice, with the assistance of our LISA Virtualize product, with a high level of success.

This topic was covered for starters in a paper I worked on with Ken Ahrens called "Virtualizing Over-Utilized Systems" and a series of blog posts on the topic last year. Look for a next installment on virtualizing performance testing from us this year - I hope we can cover some new ground for you "application speed freaks" out there.

The discipline of Performance Testing is sometimes also called Non-Functional Testing (or NFT), but the lines for NFT are blurry when you are also performance testing with the realistic use cases and variable data required to get a true snapshot of real-world performance levels.

We're thankful for IT change and complexity in the 00's.

The challenges of change and complexity are what we are thankful for this season here at iTKO - because without them, we frankly wouldn't have much to talk about. Likely, if you are reading this blog, I wager that these two factors might be keeping you up at night. But the source of this change and complexity might not be what you expect.

Simplicity and agility in development, is quite literally becoming the cause of change and complexity in IT, especially in ensuring that a reliably functioning software environment is delivered on time. We have been covering this theme for years - but for some reason it has really turned on the light bulb for IT listeners this year, when pressures to deliver more functionality with less resources have been at their greatest. 

Enterprises tried to reduce release cycles and costs by focusing on one part of the lifecycle: development. They've brought in new development tools, techniques, methodologies, to make software development more agile, done in smaller, reusable units, more distributed, more iterative, with ever-shortening release cycles.

Companies have spent billions, in fact, on buying platforms to enable SOA, BPM, ESB, and legacy modernization approaches. It created a new problem however... development is getting faster, but the time and cost savings is more than eaten up by QA and maintenance -- and the overall release timeline is getting longer. This imbalance has continued to grow, and organizations can not afford to keep going down this path.

To resolve it, you have to focus on test AND delivery, to wit: How do I optimize the larger lifecycle to keep up with Complexity and Change in my software? We can't afford the support nightmare of software failures in production, but if we throw resources and infrastructure at testing to keep up with all the changes, our costs and timelines, will balloon.

This is why companies are turning to Service Virtualization as a way to alleviate the huge cost of having a valid system environment available for testing, validation and performance purposes. We are thankful to be here, working to solve this problem, at a time of so much change and complexity.

Hear what some other musing friends feel thankful for on the eBizQ forum here. I personally have also been thankful to see less top 10 predictions, and more things to be thankful for, as we finally head out of what has been a tough decade for many businesses. Here's to a very successful 10's!

iTKO Chalk Talk - Test Data Management

Here's a new feature of the iTKO Blog we hope you enjoy - a series of educational "Chalk Talk" short videos covering topics like Software Quality, SOA Governance, BPM Validation, Testing, Cloud Computing and more. This first one features our founder and Chief Geek, John Michelsen. He has a way of pushing a marker that really makes gritty enterprise software topics seem very approachable, so here's his first installment on the challenges of Test Data Management:

One topic that has been on the tip of most of our discussions and recent posts these days is that of virtualization as a solution for Test Data Management (or, "vDTM" as I like to call it...). This form of vTDM is important because it allows your test and development teams to virtually manage test data outside of the system of record.

We hope you find our new Chalk Talks engaging and informative, and look for more video from iTKO soon. If you have any topics you'd like us to cover in the future, send us a note at info@itko.com.

Finding Hidden Value in Test Data Virtualization

As you've seen in recent posts here, most of our discussions around Service Virtualization center around the lack of availability of systems, environments, etc. -– i.e. the "Over-utilized" problem. A Virtual Service Environment (VSE) is a solution that helps eliminate these constraints and therefore can dramatically reduce the time to market, and/or infrastructure costs. Also, once these constraints are removed, testing (functional and performance) can be done much earlier, and therefore greatly improve the quality of the released software.

We also talk about the use of VSE to enable parallel development. Being able to simulate dependencies that don't exist, and allowing testing and development activities to happen in parallel. Again, this can greatly reduce time to market, costs and improve overall quality.

However, there is a value of VSE that we don't talk as much about. An issue that has applicability in almost every enterprise environment, is one related to Test Data challenges. Let me explain.

There are at least 4 Test Data related challenges that Service Virtualization helps solve or assuage:

1. Data Scenarios are difficult to create. In the modern application, data required to support scenarios will have to be synchronized across multiple systems. Not only is that highly time consuming, but due to access constraints, or skill constraints, or various other reasons, creating and synchronizing that data could become a near impossible task. This may either elongate the testing cycle or, even worse, encourage the testers to reduce the number of scenarios that the system is tested under.
2. Data is Volatile. This is partially related to (1). In a lot of cases, the systems being tested go directly against systems that are either in-production or are being shared by other teams. This causes the data to be volatile (changing randomly and often). This makes the testing process impossible, because any results of the testing against these volatile systems cannot be validated.
3. Data needs to be Desensitized. In a lot of cases, data challenges could be reduced by using production data. However, production data may have sensitive information like credit card numbers, social security numbers, etc. Not only is this a problem for the direct employees, the challenge is greatly magnified when offshore or outsourcing contractors are used.
4. Data should not impact production systems. Some test scenarios result in transactions being created that can mess up a production system. For instance, if a test scenario requires a new order getting placed, the order once generated will have to be traced and deleted from the production systems. This is a major pain for the testers, and for the operations personnel.

As you can see from the above examples, Test Data Management challenges represent a huge constraint on the productivity of almost any enterprise software development project of significant scope.

Here's how we have found customers can approach these challenges using Service Virtualization:

• Reduce the number of points that need to be synchronized, by capturing relevant transactions, chaining them together into scenarios, and creating a virtual model that can be manipulated without programming.
• Stabilize the data so that the test results are actually valid, for instance, maintaining the relevance of variables like changing dates and varying types of customer data entry.
• Desensitize the data so it does not violate security and privacy policies.
• Substitute a Virtual Service for the production system, so there is no need to impact the critical live system of record to retrieve data. This can be done alongside ALM tools and Service Registries for SOA - essentially routing a known test data request to the VSE instead of the real thing.

In this arena of virtualization, we have been amazed by how widespread these shortcomings are in test data management, with little recognition of any available solution for them. We believe our LISA Virtualize uniquely supports these practices, with automation for capturing, modeling, desensitizing and maintaining virtual test data.

Virtualizing Over-Utilized Systems: Part 6 - Customer Examples & Conclusion

This is the sixth post in our series based on the new whitepaper "The Next Frontier for Virtualization: Over-Utilized Systems" by iTKO (Ahrens, English). In this issue we cover how companies are applying Service Virtualization to solve for over-utilization of core systems and services needed for testing and development.

Examples of how SV Answers the Challenges of Over-Utilized Systems:

Solving a Common Bottleneck – When each team can get their own replicated test environment and data provided as a Virtual Service at minimal cost, there is no longer a need to compete for testing time during a small availability window, much less secure a capital expenditure just to get access to a hosted service-based system.

Customer Example: A leading US airline replicated much of the functionality of a partner’s reservation system that charged high per-use fees when used for testing purposes, as well as restrictions on usage due to the fact that millions of transactions needed to be handled on the system daily. Switching to a virtual service model of the system allowed multiple teams to have their own stable environment and data for test scenarios, as well as saving millions of dollars annually (up to $12M)  in non-revenue-generating access fees for the live service.

Solving Improper Capacity – Trying to pinpoint the reason for functional errors and performance problems in a modern distributed software architecture is becoming increasingly difficult. IT departments can seek to throw more hardware and software at the problem, but that cannot solve the costly and time consuming software setup and configuration effort of enabling test and pre-production environments for multiple distributed teams to use.

Customer Example: A leading bank which has grown by acquisition found that they could not effectively load test middleware which tied more than 70 acquired systems together using their existing tools. They had several developers attempting to hand-code “stubs” and “responders” to replicate the environment for 2 years, with little success. Using Service Virtualization techniques, two test engineers configured realistic models of the current bank middleware systems.  They replaced the multi-year “stub” project in a few months and grew the practice to include another half-dozen teams across the bank. They have avoided up to $30M in costs for provisioning new environments over the course of a year.

Solving Inefficiency – Every business faces increased pressure to meet customer and regulatory demands with greater agility, and leveraging distributed software components and integration frameworks can add agility to our ability to deliver expected business outcomes. At the same time, the service-oriented approach to delivering software makes it harder to ensure service level performance and quality, due to an increased rate of change in the environment.

Customer Example: A US Federal agency needed to prove that their technology selections and architecture elements were performance ready, before they were put in place in the live environment. By virtualizing the rest of the environment and its expected response times and load variability, they were able to compare benchmarks and select the appropriate technology for their architecture, without needing to “bang” on critical live systems used for weather, air traffic and defense purposes.

Summary

Hardware virtualization is becoming ubiquitous in large enterprises, offering immediate cost savings and efficiency. While the concept of desktop and server virtualization has great value for optimizing less utilized systems, it is challenged in replicating heavily utilized or constrained systems such as mainframes, incomplete components, or third-party services.

Consider how much you invest in “under-utilized” hardware and desktop OS infrastructure, versus the high cost of integrating and maintaining traditional software test environments. There's a high probability that the development and integration cost of those traditional test environments exceeds your hardware costs by several orders of magnitude. The prohibitive expense of software test environments means applications are not tested early or often enough, which leads to even costlier failures in production. Virtualization of the behaviors of over-utilized systems can address this serious shortcoming.

Instead of copying the contents of a hard drive or replicating a piece of software running in an OS, Service Virtualization focuses on modeling the communication paths “between the boxes” – components such as web services, databases, RESTful services and asynchronous messaging. This lets teams break their dependencies on the bottlenecks which are preventing them from getting their jobs accomplished.

Development and testing teams need access to an ever-increasing number of services and systems of record that are not readily available. Service Virtualization is a strategy for letting teams take the principles of virtualization beyond the data center, simulating more distributed, complex environments, where significant value remains to be realized.

This concludes our series on SV and Over-Utilization. I'd like to thank Ken Ahrens for coming up with this unique way of looking at virtualization. We hope you find parallels of over-taxed and unavailable systems within your own environment that offer similar opportunities for efficiency improvement.

Virtualizing Over-Utilized Systems: Part 5 - Virtualize the Behavior

This is the fifth post in our series based on the new whitepaper "The Next Frontier for Virtualization: Over-Utilized Systems" by iTKO (Ahrens, English). In this issue we cover how the practice of Service Virtualization provides solutions for over-utilization of core systems and services needed for testing and development.

Hardware Virtualization Can’t Solve Bottlenecks of Over-Utilized Systems

We’ve reviewed why systems are becoming over-utilized, as compared to under-utilized. The problem is that the hardware and desktop/OS virtualization tools we have at our disposal are great for optimizing under-utilized resources, but they are often incapable of virtualizing the behavior of over-utilized systems.

Even the largest virtual server deployment and centralized management of VMs may not allow for the virtualization of 3^rd party cloud services or mainframe assets.  However, these same concepts of virtualization can be applied in new ways to eliminate bottlenecks in our overtaxed core services.

A Solution: Service Virtualization (or, "SV")

Service virtualization involves the simulation of software service behavior and the modeling of a virtual service to stand in for the actual system during development and testing. Think of it like a “stunt double” for your most constrained, critical applications. Service virtualization addresses each of the aforementioned hardware virtualization limitations such as:

• Providing 24/7, on-demand access to ready test environments managed on your terms
• Removing capacity constraints of over-utilized systems
• Addressing test data volatility across distributed systems and conflicts among teams
• Reducing or eliminating the cost of invoking 3^rd party systems for non-production use

While Hardware Virtualization focuses improvements on the systems an IT team can control, such as servers in the data center and desktop, the complementary practice of Service Virtualization is geared toward optimizing the distributed and shared types of applications that are resistant to being imaged as a hard drive in a hypervisor: the over-utilized systems such as mainframes, partner-managed services and components under development by other teams.

 Let’s look at a sample enterprise with 3 downstream dependencies after applying SV techniques (from the bottom up): 

• Mainframe access problem eliminated:  During an instance when the key transaction system is available, it is captured and reproduced as a sophisticated model of that behavior, which is then hosted as a virtual service and accessible 24/7 in a virtual service environment.
• Database access and data volatility eliminated: Rather than having to negotiate set up and removal of test data sets from multiple sources and partner systems, the team can get a stable set of data to validate scenarios without impacting the live systems or other teams’ test data.
• Mitigated an unavailable or incomplete system exposed through a Web Service: Construct a Virtual Service from a WSDL, SOAP documents, XML samples, and other artifacts, whether or not the service, or the back-end system is available for testing. If desired, the Virtual Service could be accessed as a “pass thru” to intercept test transactions, while allowing live transactions to continue through to the real service and legacy application.

Coming up: 6th and final issue in this Series: Customer Examples of SV in practice, and Conclusion.

Virtualizing Over-Utilized Systems: Part 4 - Limited Capacity & Inefficiency

This is the fourth post in our series based on the new whitepaper "The Next Frontier for Virtualization: Over-Utilized Systems" by iTKO (Ahrens, English). In this installment, we discuss 2 of the big 3 challenges of Over-Utilization: Limited Capacity and Inefficient Systems.

Over-Utilization Due to Limited Capacity:

With the low cost of hardware, you would assume that having environments that were just too small would be a thing of the past.  But there are reasons why some key systems may continue to be under-sized:

• Unexpected Growth – It's great when a new core service gains popularity and adoption across the enterprise.  Perhaps it is an indication that well thought-out designs are being adopted.  But the downside is that too much interest can drown a new service under a deluge of transactions.  Or many parties may need to jockey for position to get their test data loaded into the new service.
• IT Re-alignment – In some cases, companies (and their entire IT infrastructures) have been acquired, or hardware was only partially upgraded.  For instance, the production environment is fully built, but pre-production is scaled down. This can be a problem when multiple teams are trying to integrate their systems to a common environment that is a moving target.  Common strategies of dealing with this problem are to schedule the execution of tests across all teams, so they are not all hitting the constrained resource at the same time, which limits the new company's ability to take new functionality to market.
• Expensive to Duplicate–Today's composite apps can involve a dozen components with the overall application no longer in one team's full control, so virtualizing one system doesn't make much of a difference, because of the interdependent nature of the application.  Who cares about saving a few thousand dollars in hardware costs, when the software and maintenance effort of a complex system can cost millions?

Over-Utilization Due to Inefficient Applications
As much as we'd like enterprise applications to run smoothly, it's more common for systems to run slowly. This problem is exacerbated when your application might be performing poorly, and to improve this metric you depend on testing against other services/systems that are also running slowly.

• COTS Products – Vendors have to write "one size fits all" types of applications. The result is that without investment in customization, these apps will run more slowly than if your exact use case was coded by hand.  As the shift goes from developers writing nearly all the code in the past (e..g legacy COBOL) to focusing more on just writing the business logic (e.g. BPM), the amount of third-party code is skyrocketing.  Unfortunately there isn't much that can be done to optimize third-party code in the short run, which may drastically affect testing and analysis of the code that your team *does* write.
  
• Older Technology – Despite earlier predictions, the mainframe does not seem to be going away anytime soon. If your mainframe has a large partition for development and test then consider yourself lucky.  Most IT shops have to deal with very small LPARs resulting in scheduling conflicts or adjustments that must be made to test strategy.

Customer Example: A large financial services company was unable to properly load test applications going to production. While they had dedicated environments and test cases, their small test mainframe was at CPU capacity while the non-mainframe apps were only at 30%. They never learned the breaking points of their system until they actually pushed code to production, a risky proposition.  Eventually they found out the hard way when they had an outage that took out all transactions for their largest customer.

• Popularity Reduces Flexibility – Being popular can be a curse.  If you change something fundamental about your service, lots of other teams may need to be involved.  Those other teams may have more clout, and could try to block your code changes from being made.  This can result in possible efficiencies never making it into your core services, so they grow slower over time.
  
• Compliance – Implementing features such as robust logging, audit trails, governance, monitoring, security, etc. can significantly slow your app.  We typically think on the positive side that these features bring to visibility, but early in your development cycle you may not care too much about these benefits.

Next installment - Employing Service Virtualization practices in addition to your existing hardware virtualization approaches.

Virtualizing Over-Utilized Systems: Part 3 - Common Bottlenecks

This is the third post in our series based on the new whitepaper "The Next Frontier for Virtualization: Over-Utilized Systems" by iTKO (Ahrens, English). In this installment, we will break off one of the big 3 challenges of Over-Utilization: the "Common Bottleneck" that constrains multiple teams attempting to develop, test and integrate enterprise software. Conventional virtualization can break under the strain of attempting to eliminate these bottlenecks, as they are often too large or too complex to be replicated on a given VM.

[Nifty picture I took in Tierra del Fuego, Argentina - constant 50mph west wind]
Well-respected enterprise application design patterns are actually causing software development lifecycle bottlenecks where numerous teams rely on a key system or technology.  These systems become new constraints to development and testing, and push the original goal of time and cost savings further out of reach. Here's the key points where we find Common Bottlenecks:

Design of Core Services – In some Enterprise IT organizations, a few key services are so fundamental that they are used in a majority of projects.  From the standpoint of re-use this is exactly what we were looking for, but while designing, testing, and running our applications, these core services create dependencies which slow teams down, because unlimited access for software teams is often considered too risky.

Examples of core services include:

o        Customer/Account – An example of one of the most commonly created core services, so there is a single place to get customer records.

o        Billing – Customers don’t want to receive multiple bills from the same vendor, so this is also a common core service to create.

o        ERP System – Especially for internal purposes (HR, Financials, etc.) companies adopt a single platform and require everyone to integrate.

Customer Example:

A large North American Telco had issues in replicating their core SAP system across a myriad of environments.  Only 3 of 7 non-production environments have an SAP instance they can use. Also the training system does not have a copy of SAP, so they cannot train their Customer Service Reps on applications that integrate with SAP until they are rolled into production. The result is that bugs are not found until it is too late to repair them and still deliver projects on time.

Data Warehouse – Numerous services depend upon the same set of data, especially for account information. In order to make data available for development purposes, this data usually comes from a production “refresh” as needed, and is put into pre-production.

• Data setup & teardown – Managing relevant, stable and secure data in the environment can become a huge drain on team productivity, sometimes consuming 60% or more of testing time.
  
• Data volatility - When data is treated as community resource for multiple development and test teams, other teams can pollute the test data (for instance deleting a key user required for your regression test suite).
• Secure data - In addition, live data must be suitably scrubbed or “desensitized” to protect unauthorized tester access to account information, which is a time-consuming process.

Cloud Services – Saving money by using external service vendors on a pay-per-use basis is great, but not when they get in the way of being able to do testing and development. This means we have another team we need to coordinate with from a data standpoint (test accounts, etc.) and potentially we are charged a usage fee when calling on these services.

Incremental fees are fine if they are a part of a revenue-generating customer activity in the live application, but they are a problem when they become a development cost to the business. For instance, how can we avoid skyrocketing fees for load tests that include a cloud service, or analyze negative ramifications if the cloud service doesn’t meet their SLA?

Customer Example: Insurance in the Cloud

A regional insurance company needed to be cautious about how they run their performance tests for adding new auto insurance customers. Among other things, the new client application performs a credit check and runs an automobile history report.  During one of their routine load tests against the new app, they sent actual requests for automobile history reports to a third party, resulted in a $15,000 access charge. After this unexpected charge they simply chose not to test any third-party service calls until they reach production.

Next installment: Limited Capacity and Other Inefficiencies

 

Virtualizing Over-Utilized Systems: Part 2 - Under vs. Over Defined

Here's an introduction to the concept of "Over-Utilization" in terms of Virtualization of software and services. This and 4 more posts in this series will cover concepts detailed in a recent whitepaper by Ken Ahrens and Jason English, "The Next Frontier for Virtualization: Over-Utilized Systems", downloadable on iTKO's site.

Are we Virtualizing the Path of Least Resistance?

Hardware virtualization technology is now par for the course in enterprise IT infrastructures. Enterprises can realize rapid cost savings through the use of hardware virtualization to reduce server proliferation, consolidate desktop environments, and run numerous apps with a smaller combined hardware footprint. The key value espoused by leading virtualization vendors (such as VMware, Microsoft, Citrix, etc.) is making better use of “under-utilized” servers that do not require dedicated system resources.

But what are we supposed to do about the kinds of systems that are not good candidates for hardware virtualization?  What about the critical over-utilized applications that create bottlenecks among teams that need access throughout the software development and testing lifecycle?  Hardware virtualization has a much less compelling value proposition in this scenario. 

A strategy to apply in this case is the use of Service Virtualization (SV) to reduce multiple team dependencies on over-utilized systems, allowing them to work in parallel. Let's take a look at the utilization patterns encountered in enterprise IT environments, and which type of Virtualization (Hardware virtualization, Service virtualization, or a combination of both) should be applied to receive the greatest value.

Defining Utilization Patterns

For simplicity, we’ll just categorize enterprise systems into one of 3 categories of utilization and figure out what this means from the standpoint of virtualization:

• Under-Utilized systems have low CPU/memory/disk usage, or otherwise there is significant capacity on the system to run additional applications.
  
  
• Over-Utilized systems may have high CPU/memory/disk usage (for instance a transaction mainframe or multi-terabyte system of record), or perhaps they are services outside of the control of the Enterprise, with usage limitations or per-use costs (such as third-party services, cloud computing, SAAS, etc.).
  
  
• Properly Utilized systems, which are working optimally, and can be left alone.

Causes of Under-Utilized Systems:

• Infrequently Used – Low usage does not necessarily equate with low business value (as a rarely used service could process very expensive orders), but it does usually mean that the system could get by with less processing power during those hours when it is not used.
• Excess Capacity – For teams that didn’t have the time or resources to do significant capacity planning tests, many architects hedge on the safe side of providing too much capacity rather than too little.  At some enterprises this creates a capacity glut of servers and bandwidth.
• More Efficient Software – Let's give developers and testers some credit, they can build very robust software, or perhaps optimize the software performance and use of system resources over time, to get their services to run very efficiently.
  

In many of the above cases of under-utilization, conventional Hardware Virtualization approaches have proven successful in eliminating excess capacity by consolidating servers and applications. Performance testing and benchmarking can help identify good targets for hardware virtualization, but do these under-utilized systems represent the greatest cost and risk to IT?

Causes of Over-Utilized Systems:

Why would systems end up over-utilized and unable to handle ongoing transactions, particularly in supporting software test and delivery teams?

• Common Bottlenecks – Literally this means that many teams depend upon access to the same constrained system or service.  Usually this is due to a design decision early on, but in shared environments, the usage pattern is hard to predict when a service is called upon by many customers, and other teams’ services in unplanned ways.
• Limited Capacity – More likely for services that have been in production for some time, it’s not hard to imagine that new technology teams get hardware upgrades, while older technology gets left in the dust. Or the production environment may be re-built, but pre-production servers needed by development and testing may not get the same upgrade due to budget constraints.
• Inefficient or Unscalable – Unfortunately, technologies and platforms may not provide the scalability initially advertised.

While we hope that responsible architecture, integration and deployment strategies will result in proper system utilization, it typically doesn’t work out that way in today’s heterogeneous, distributed application environments. There are simply too many variations in how the systems are connected and used, and too many components in the environment that aren’t under one team’s control.

Next post in this series: Outlining the Challenges created by Over-Utilization of key systems.

Virtualizing Over-Utilized Systems: Part 1 - A new concept

One of our really savvy Architects Ken Ahrens recently had an Aha! moment while visiting a financial institution. The customer was asking how our definition of virtualization was different than the more commonly known types of hardware and desktop virtualization already happening in most IT shops.

That's when it hit him: You are already familiar with virtualizing under-utilized systems -- servers and specific desktop OS configurations that don't need as much dedicated hardware and capacity as expected. That's certainly useful for trimming some IT costs.

But what about the over-utilized systems -- those critical and costly applications, services and mainframes that are just too big, or too remote to be replicated on a VM? The over-utilized systems represent a lot of cost, and big constraints for our ability to deliver and test software. Surely there must be a way to virtualize these too?

Well after a lot more analysis on this topic with Ken, we have a new iTKO whitepaper, "The Next Frontier for Virtualization: Over-Utilized Systems," that addresses how companies can identify and start to virtualize these over-utilized systems.

We'll be posting some additional notes and excerpts from the paper explaining the concept here in the future as well.

HP to Resell LISA Virtualize - The News

iTKO and HP recently signed an agreement which created a significant piece of news: "iTKO's LISA Virtualize Software to Be Resold by HP to Reduce Testing Costs and Accelerate Time to Market for Modern Applications"

There is a lot of value to capture here. In every major enterprise IT shop we go into, we find that there are a growing number of constraints to testing created by what the industry is calling "modern apps" -- highly distributed, componentized, loosely coupled applications that no longer reside within a company's four walls. Call it SOA, SaaS, Cloud, pull in BPM, legacy migration, etc. and you have a recipe for quality chaos.

Many of the systems we need for software development are supporting live transactions, contain critical customer data, are inaccessible to the team, and perhaps even charge significant fees for each access. IT shops can literally spend 40-60% of their development time trying to configure test beds, code "test responders" or stubs of needed services, and massaging data into and out of the system before and after each functional and performance test. Faced with these constraints, companies simply do not test as early or often as they should, and quality and performance suffers.

We are familiar with virtualizing servers and desktop apps, but what about the above highly constrained pieces that make up a modern app? These systems are resistant to hardware virtualization, but they can definitely be virtualized behaviorally with LISA, so now HP test and development team members can get access to them on their terms.

This functionality is complementary, but very different from the well-known practice of hardware-based virtualization, in that it is not imaging a hard drive or desktop OS as a VM. Instead it is an automated software-based solution to virtualize the behavior of downstream dependent systems, services, data and components that may not be under a team's control. There are huge benefits to be gained in terms of faster delivery cycles, fewer production errors, and much lower cost and effort of managing test environments, coding stubs and managing test data.

It's a fact that there are more performance and functional testers with HP's testing software installed than any enterprise solution on the planet. And every one of them could stand to benefit from having robust test environments that are readily available to work with. We think this is great news for the software lifecycle when the world's largest technology companies are working to solve some of the largest problems out there.

Stay tuned for more news about this partnership here.

Recent coverage of the announcement (in progress):

• Dana Gardner in ZDnet: HP Partners with iTKO on LISA Services Testing Suite for SOA, BPM
• Virtualization Journal: We particularly liked an article from Maureen O'Gara: "HP's Got a New Girlfriend Called LISA"
• Vance McCarthy in IDevNews: "HP To Sell iTKO LISA for Virtualized SOA, Apps Testing"
• eBizQ "iTKO's Virtualize Software to be Resold by HP"
• StickyMinds.com News
• Official iTKO release on BusinessWire.

How the Recession Affects CIO Budgets

Interesting article in a recent Forbes magazine. In "IT After the Recession," Ed Sperling interviews Gartner's Mark McDonald about research conducted with a sample of corporate CIOs about the economic impact of the global downturn on their budgets. Not surprisingly, 90% of the answers did say they had reduced budgets this year.

The report points out a couple interesting trends that call for virtualization on a greater scale in my opinion. The first is in the management of server environments, an area that is only becoming more constrained. The survey notes that budgetary cuts are focused on reducing third-party and contractor support, or renegotiating support contracts.

That is a good sign compared to knee-jerk layoffs to meet budget goals, but it still will call for a lot more automation and reduction of costs wherever they are available. Hardware virtualization will remain a top priority for CIOs, given the need to "do more with less" with every technology asset, as well as the ballooning amount of storage and processor power required to handle complex workflows.

Second, in the article McDonald points out a discontinuous trend that calls for more innovation: "There traditionally was a relationship between transaction volume and revenues. As revenues grew, so did transaction volume. Starting about four-and-a-half months ago, CIOs began reporting that relationship is broken. Transactions continue to grow even though revenues are flat to down. In banking, for example, balance inquiries are one of the fastest-growing transaction types. It doesn't generate any revenue, but it does generate a lot of work."

That is a stunning report, and one that we have seen corroborated in banking/insurance, travel, defense and other industries - more transactions no longer means more revenue. Today, both customers and business partners expect 24/7 any where, real time data from the enterprise -- in fact a companies' ability to provide good real-time data such as order status, tracking, pricing, balance, etc. are key differentiators in customers' minds.

The same also applies to development and testing transaction volumes -- non-revenue generating  transaction fees, bandwidth, and data setup while working to build functionality, can increase much faster than the revenue the business functionality supports. In these cases, Service Virtualization is a valid approach, since you have systems that are either unavailable or not under the teams' control for Hardware Virtualization.

We hope as the CIOs start to employ these leaner practices during the downturn, they will come out stronger in the years to come.

Keeping Development Close in the Cloud with ZDNet's Gardner

Continuing our discussion on "Personal Cloud" technology from last week, I had a chance to catch up with ZDNet/BriefingsDirect analyst Dana Gardner, whom we also ran into at the most recent HP Software Universe event in Las Vegas.

In his latest blog: "The Cloud Gets Up Close and Personal," Dana was particularly interested in virtualization and Cloud Computing in terms of freeing up developers from dependencies and costs by replicating the target environment on their local workstation, a capability which is entirely possible today:

"The confluence of SaaS and cloud with application development and the test phase is changing rapidly..." he observed. "Compressing the test phase into the development and production becomes more feasible. And as virtualization becomes more common, building an application or service in its own runtime stack bubble from inception to sunset starts to make sense..."

Indeed, we feel that ANYTHING you can do to eliminate waiting on incomplete environments, unavailable systems, unexpected costs and fees, all of those things are what we need to solve if we are going to really see the value we expect from today's distributed, flexible kinds of apps -- which will likely lean heavily on the Cloud as a deployment strategy.

Having a personal-size development environment is almost as popular with developers as say, a personal-size pizza. And in terms of the costs IT departments currently must spend to enable robust test environments, the cost to the business can now seem as small as adding one topping to that personal pizza. He quoted me from the briefing:

"First, the developer working on a cloud application is free to work anywhere, anytime regardless of whether the real cloud services are available or accessible. If a cloud service for a shopping cart is down for some reason, developers are not impacted since their version of the service is on their laptop. They can also code when they are on a plane, or in another environment with no access to the cloud.

Second, although this is probably first in the minds of budget conscious IT managers, the developer is not running up charges for accessing the cloud services..." [Chris Kraus, iTKO]

Now, this sounds great. But what are the unaddressed frontiers of such an approach? Well, for one thing, Dana is looking for the whole package coming out of it:

"...while we’re combining all the elements of an application and platform from cradle to grave, why not tune the whole package before, during and after development too … then load the entire package as a portable cloud-supported production unit?

Now, that’s a “personal” cloud (I prefer cloud service nodule), but with high service performance output, and far less time in cost in the total lifecycle. Higher overall quality too. What do you think?"

We like it - however with critical deployed systems, even if they are very well tested before they are packaged and deployed by the developer, you still MUST test continuously in deployment, as all of the components and usage patterns the developer needed to have stable on the desktop, may not be so stable or used in known ways in Cloud deployment. We can get most of the way there, but probably not 100% there, as much as I'd like to be proven wrong someday.

In addition we will still see these efforts put into Public and Private Cloud environments, due to the ease of administration and economy of scale benefits of provisioning shared "anytime/anywhere" environments for the software lifecycle.

I do believe we will continue to see innovation in this realm - the personal cloud or "local virtualized" environment enabling multiple individuals and teams to work in parallel - married to next-generation application packaging and deployment options. Indeed there are already some nice technologies out there, which we will discuss with partners in future posts.

Whitepaper: Demystifying Cloud-Based Testing and the Related Benefits

You might have noticed a lot of commentary about Cloud Computing recently on this blog, and it is not a coincidence. In our conversations with analysts, peers and of course customers in the field, we are frequently asked about how this approach can add value to the testing and virtualization practices we support.

We have just put out an iTKO whitepaper on this topic, titled "Demystifying Cloud-Based Testing and the Related Benefits." The PDF is free to download.

There are many hard lessons and new techniques learned from industry-wide attempts to decouple and flexibly assemble enterprise software around key business processes. In order to reduce risk as we move into Cloud environments, we need systematic testing that gets around the roadblocks of inaccessibility and unexpected costs. We need to make use of automation and virtualization of the extended environment as much as possible. Cloud-based services need to be governed and validated as part of a continuous business process.

At this stage of the Cloud's development, there are many vendors and service providers that can contribute value to a comprehensive deployment and development environment solution. This short paper does not seek to recommend a comprehensive solution set, rather it focuses on gaining value within the software testing lifecycle. It outlines the key challenges and the top 4 strategies in play - first steps for virtualizing and testing distributed assets in the Cloud. We hope you find the information useful, and invite your feedback.

Podcast: Virtual Strategy Magazine on VSE Benefits

Virtual Strategy Magazine's Carryl Roy recently recorded a podcast briefing with iTKO about the new features of LISA 4.6, with a special emphasis on the Virtual Service Environment (VSE) capability of the product, and why a more expansive vision of Virtualization is needed for today's heterogeneous, ever-changing software environments.

Virtual Strategy: "iTKO Rolls with the Punches, Releases New Version"

Virtualization of hardware has already made great strides in reducing costs and increasing flexibility in the staging and deployment of software in the data center, but there is much more work to be done in optimizing the software lifecycle before production.

We are seeing companies pressured to keep IT budgets down, while the complexity and volume of data accounted for in applications keeps growing exponentially. There is a need to prune away many of the costly dependencies that can drag down the productivity of software development and testing teams. You can listen to or download the 15-minute podcast here.

Talk about Service Virtualization at HP Software Universe '09

At this year's HP Software Universe we're thrilled to be talking about a quality practice where we've seen incredible strides made over the last two years. The concept sounds simple enough: Virtualize away my upstream constraints and dependencies so that the test lab (for instance HP LoadRunner and Unified Functional Testing) solutions have a self-contained environment for testing.

However when you look at how complex and interdependent today's applications are, you begin to understand why replicating these complex behaviors -- such as unavailable or secured systems, third-party Services and components that are still under development -- has been resistant to replicating via conventional hardware virtualization means.

What is really cool is how we've seen customers of HP and iTKO bring this particular challenge under control. If you are planning on being in Las Vegas for this year's HPSU 2009 - June 15-19 - we invite you to take an hour to join HP Senior Product Manager Jeffrey Meyers, and iTKO Founder/Chief Geek John Michelsen to find out how these Virtual Test Environments can eliminate constraints (and costs) in a big way.

Session 1497: Thursday, June 18 - 10:30am - 11:30am
"Eliminate testing constraints and test earlier in the lifecycle: using service virtualization to drive testing momentum"

Here's the abstract of the session:
If your IT team is struggling with obstacles outside your organization, then join HP and iTKO and find out how HP testing solutions, combined with the iTKO LISA Virtualize platform, can minimize external dependencies and help you test earlier in the development cycle, before a complete test environment is ready to meet your testing objectives. You’ll hear how the combined HP and iTKO solution works in complex shared environments of modern applications, agile development techniques, and volatile data sources to make your testing efforts constraint free.

If you are planning on being there, look us up on Twitter as well: http://twitter.com/itko and drop us a note or feedback on your thoughts.

It seems in June we really catch the "last gasp" of interesting IT events, and this month is no exception - besides attending this excellent summit, we are bringing in the summer next week presenting sessions in Chicago at Technology Executives Club and a Federal roundtable at GTRA in Virginia. Hope we see you at one of these key events soon.

How to be Fast and Agile with Increasing Services Complexity Without Falling on your Face

Agile development is spreading in the SOA world to rapidly decrease development times, but if testing is not done properly, you might lose all the efficiency gains through having to conduct a massive cleanup effort afterwards. Like building bridges, fix it as you go is a much better approach than fix it later with massive traffic flowing over the structure. InfoWorld's Eric Knorr writes about this in his recent Modernizing IT article, "How to be agile without falling on your face."

Eric reports on a conversation with iTKO’s Derick Townsend. Derick said that companies within an M&A cyclone -- particularly in times of high volatility like we are seeing today in financial services markets -- are desperate to accelerate application development projects.

"They get 80 percent through a project, and they think the end is in sight, but the last 20 percent really stymies them, and that has to do with the test and delivery part. They're dealing with so much complexity. Telcos are experiencing this too. The components and underlying systems are changing constantly underneath," Townsend said.

Eric goes on to write about how iTKO provides what we call Service Virtualization, which is different than traditional hardware virtualization. Instead, iTKO LISA absorbs the behavior of all relevant components, services and data in an extended IT environment and simulates them, This capability allows developers to determine how an application based on those services will behave under various circumstances in the real world. Developers can become more agile using Virtualization practices to support increases in complexity, without a corresponding increase in testing and development risks and cost.  

Green SOA is Good

We have covered SOA’s role in green IT before on this blog, (see Making IT More Green and Saving Money at the Same Time Through SOA). Loraine Lawson provides an useful addition to the conversation with her post, SOA's Green ROI.

Lorraine sets the stage with the fact that today, over 70 percent of the SOA adoption rationale is business driven, versus only 30 percent in 2006. She adds that technology may never again be the driving force in the corporate decision process, but in SOA, it will always be the implementation mechanism. We have written that with SOA and many other tech efforts, going green and getting a better ROI are interconnected.

Lorraine goes on to cover the opinion of Deborah Grove, a green IT specialist, who has long been of the opinion that SOA is key to the long-term definition of Green IT. “Right now, we are picking up the 'low hanging fruit' by addressing the PUE (power usage effectiveness) of data centers’ power consumption.  However, looking at the entire IT food chain, ensuring that ecosystems of suppliers, partners, and customers are moving to an online collaborative style with less paper and less independent development of customized applications through the use of SOA means that fewer hardware pieces will be needed for dev and app servers.”

I certainly agree and automated testing and virtualization can play a significant role in reducing waste from the IT food chain. Lorraine points out that Verizon Wireless used SOA to green its IT infrastructure, reducing its hardware footprint by 95 percent. The company measured its ROI by reduced tonnage of hardware in the data center. However, the green of virtualization is not limited to hardware, as we have discussed here (see Guide to Service Virtualization in Enterprise Application Development – Part One of Six.) It is nice to see an increasing awareness of the green potential of SOA.

 

Dan Woods on Brick Walls Of Virtualization

Brick Walls Of Virtualization is the title of a recent post by Dan Woods at Forbes.com. The subtitle is, "Without automation, creating and managing system images will slow adoption." I could not agree more.

The "brick walls" refer to the burdens of virtualization that come along with the benefits. On the benefits side Dan mentions the cost savings of less physical servers; increased flexibility to provision systems or change configurations; and better access to resources in the cloud. This latter benefit outsources complexity and shifts capital expenditures to operational expenditures.

You would be hard-pressed to find a large company not already leveraging some mix of hardware and software virtualization. Especially in a down economy, it has obvious value.

However, Dan then brings up the burdens of brick walls. The good news is that the number of physical servers may drop due to support cost and energy pressures. And, the potential bad news: the number of virtualized servers and devices can skyrocket without the physical constraints, and each of these virtualized devices still needs to be managed. We are seeing this all of the time in our major enterprise client engagements - virtual instances can proliferate quite rapidly if not managed carefully.

Here's another, deeper challenge of virtualization in enterprise IT: for all of those virtual servers, you still have dependencies or "wires hanging off" of those, leading to big iron mainframes, SaaS applications, 3rd party services, what have you. These dependencies are resistant to hardware virtualization, so they need to be simulated with behavioral virtualization.

I personally like to compare this phenomenon to unmarked leftovers in a shared refrigerator... [whose food is this, and without opening it up, can I figure out how long it has been here?]

Dan adds that a "whole new class of IT systems-management software and techniques is needed to create a virtual data center operating system." Part of the increased requirements for systems development and administration involves testing and continuous validation, and part of this involves better management of both VMs and Virtual Services, a topic we will discuss in further detail on this blog.

There is much more in Dan's post and I recommend going to Forbes.com to read it. I liked his concluding remark, "The upshot is that IT, which is dedicated to automating the rest of the business, must start spending more time automating itself." Well said.

Showing some ERP mettle for SOA with SAP

So many of our customers have large-scale ERP packages like SAP or Oracle that form the IT foundation of the enterprise.  While at the outset this sounds like a simple architecture, given that you are working with a single vendor over a longer timeframe, in fact these systems are themselves rife with complexity and heterogeneity.  And so many applications now connect into the ERP via various forms of adapters and message buses, that you end up with the classic alphabet soup of technologies at play.

"iTKO/SAP Whitepaper: Validation & Virtualization of SAP Enterprise SOA Applications with iTKO LISA"

This new paper iTKO co-authored with SAP, after working with them in their labs, helps customers see just how valuable a service validation and virtualization offering can be in these environments.  By SAP’s own calculations, customers spend millions of dollars every year standing up and maintaining development and test labs for SAP, even when running on virtual hardware.  And when they need to perform complex integration and load tests with other systems, millions can become $10s of millions to support these environments.  

Our strategy of virtualizing the services layers of these complex applications in a VSE (Virtual Service Environment) like LISA offers is a great way to eliminate those costly constraints, and make it practically zero cost to stand up. This approach is great for our software partners like SAP, and especially for the end customer. After all, we all want to focus IT budgets and especially our integration and innovation efforts toward technologies that contribute revenue to the bottom line, and not manual support and configuration costs that aren't repeatable.

Yes, even big ERP is getting nimble for SOA. We expect even more collaboration with SAP and other software partners to better improve quality and agility for customers with Virtualized Services. You can also find the paper posted by co-author Joerg Nalik Ph.D. on SAP's Developer Network and COIL blog here: https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/14083.

Meeting the Business User’s Expectations with Cloud computing, SaaS

Neil Ward-Dutton recently posted a comprehensive piece on Cloud computing, SaaS and SOA - the universal service network. He wrote that "Regardless of where services come from (and indeed because they will come from multiple places, creating cross-enterprise service networks), it's increasingly the case that in order to deliver effective IT capabilities in the 21st Century, you need to understand SOA principles and build technology and management structures that really support the principles of service orientation."

He then goes on to discuss two sets of business user expectations. First they expect flexibility. Neil writes, "when business teams that are using SaaS-based offerings learn about the infrastructure side of the story - how easy they can be to customise, extend, and integrate with - and ask why internally-developed systems don't exhibit the same qualities? Another slab of SOA pressure, that's what." The business will demand a high level of flexibility and control in how service-based offerings are composed and consumed.

Later Neil brings up the second expectation. He refers to Todd Biske, on ITIL and SOA, and states how it's "crucial to consider the full service lifecycle when you do SOA, and drive governance to ensure that you can deliver "real service" - not just code wrapped in XML-based interfaces." Then he offers some examples where the provider's idea of service doesn't match the consumer's expectation.

In addition to flexibility, businesses want applications that work. These two points go to the heart of the need for higher levels of test automation and agility throughout the design and development process, as well as the benefits that virtualization can bring to both flexibility and getting good, ready data.

Without rapid, repeatable test cycles, you cannot achieve flexibility as development cycles get bogged down. This was the fate of one financial service institution before they moved from manual to automated testing. Service Virtualization can further accelerate the development process by eliminating the bottlenecks of constrained or unavailable systems as one European telco discovered.

Neil concludes that the "rise of cloud computing and SaaS should entice us to revisit our development-centred assumptions about SOA and search for a 'bigger picture' that focuses on consumer expectation and value first." One way to do this is to simplify the development process and enable faster iterations. This enables us to focus less on the integration challenges of the technology, and more on the business challenges the technology is designed to meet.

Service Virtualization Addresses the Sticky Challenges

Alex Handy recently wrote about virtualization in testing for the San Diego Times. (see Virtualization bridges, from development to IT). He notes that virtualization is a hot IT topic and begins with the  comment that, “many of virtualization's proponents see the technology as a way to bridge the gap between operations and development. The path to that bridge, they say, is often through the test lab.” He later notes that on the application side, developers are motivated by speed and flexibility. These concepts are often completely lost on the operations side, where the focus in on cost and control. Virtualization addresses both needs.

In addition to saving time and money, Alex notes that it can provide continuity to a support team as it can look at a given user's exact deployment of a given application or a given group's exact configuration. This can really accelerate the support and remediation process.

One challenge arises when virtual test beds attempt to enter distributed application environments, such as Cloud Computing and SOA. When an application is tied into a network of services offered throughout an organization's extended network of partners, how can they be added into a test environment? You can't just take a hard drive or a server and replicate it, when many of the elements in the environment aren't available for that activity, or they are far too complex to realize cost-efficient hardware virtualization models.

Here Alex quotes iTKO's John Michelsen, who said that this issue can be troublesome for large development projects inside and outside of the cloud. "In the real world, there's an airline that has 1,500-plus regression tests that run on a nightly build," said John. "They spent three or four hours each day dealing with about 10% of those tests failing every night. The vast majority of the failures were false failures." The lack of availability to the needed services, and relevant data for testing, made the test lab a major bottleneck during the software lifecycle.

Service Virtualization, using a Virtual Service Environment to capture and simulate the behavior and data of interconnected systems, addresses this issue through bypassing the constraints of operating in the real world with production systems. Here is an example of how an airline addressed this issue with virtualization. 

Stories from the Field - Part Two: Leading Financial Institution

This is the second of an eight part series on "stories from the field" from our engineers and architects working with customers to solve the challenges of dynamic enterprise applications, based on SOA, BPM, integration suites, and ESBs.

It looks at how a leading financial institution eliminated a cumbersome and expensive manual testing process, freeing up resources and dramatically decreasing implementation cycle time. The bank set up a center of excellence (CoE) for middleware performance testing. In many cases one middleware test might connect with 70 to 80 systems that represent an alphabet soup of different technologies. To handle this effort, the bank built a very large custom test harness to respond to their load testing solution over the course of several years. But it could not meet all the changing needs and required a team of consultants just to keep it going.

The hand-coded responders were all one-offs that were not integrated, requiring so much rework that the team needed to push back releases by months to accommodate test cycles. Ken, the iTKO architect brought in, said that the bank felt this was not a scalable or cost effective solution anymore. Ken was able to "virtualize" or simulate these 70+ applications running within a Virtual Service Environment (VSE) in a few days - with more dynamic logic than the hand-built responders that had taken years to put in place.

Now they had an integrated solution that could handle the entire process through an automated testing approach that could provide ready access and data modeled to adapt to needed test scenario changes. The bank had been employing a team of highly skilled and highly paid consultants to maintain the test harness and perform testing – much of it manually. These consultants had been originally brought in for more complex application and test case development. Now they could focus on their original assignment. It was a win all around.

The bank greatly reduced their ongoing testing and validation costs and time. Several additional product releases per year are now planned. The solution consulting partners were also winners, as they were able to return staff to higher value tasks, maintaining a service level differentiator over lower skilled competitors for the manual tasks they had been pitch-hitting on.

In fact, the consulting company was so pleased by the outcome that they have started to build a consulting practice around the use of iTKO LISA for similar situations at other financial service institutions. It's informally been called the "bank in a box" solution because of its power and simplicity. We all know how much financial services firms need to cut costs these days so they should find a responsive audience. Go here to see the entire case. Our next case covers how a leading Canadian Bank removed constraints to greater productivity in the Test Lab.

AppGap Covers iTKO’s New Service Virtualization and SOA Governance Offerings

The AppGap recently had a post by Bill Ives that covers our new service virtualization and SOA governance capabilities, titled "iTKO Expands the Agility of Enterprise 2.0 with New Service Virtualization and SOA Governance Offerings." John Michelsen, iTKO’s Founder/Chief Geek; and Chris Kraus, iTKO LISA Product Manager were interviewed.  

Chris said that with LISA, iTKO has integrated the leading governance vendors’ policies to directly launch our testing and validation services, and feed the results back into the SOA Registry/Repository, so that SOA policies can be better enforced with automated validation procedures.

The post spent more time talking about our newer service virtualization capabilities. It mentioned how iTKO takes the virtualization concept a step beyond hardware and desktop virtualization with service virtualization. Now you can virtualize the behavior of services even if they are unavailable or not yet developed. The post says that service virtualization can greatly reduce the dependencies between development and QA, and between the core service provider and the business solution service consumer.

Bill wrote a prior post last summer, - iTKO LISA - Software Validation and Testing at the Speed of Enterprise 2.0 that covered our basic capabilities. In this post Bill wrote, "...that iTKO has further revived up the speed with these expansions."  We greatly appreciate these thoughts, and recommend you read this and other interesting posts from Bill and other bloggers on new E2.0 technologies. 

Guide to Service Virtualization in Enterprise Application Development - Part Six: Complete Strategy with Service Virtualization

This is the last post in our six-part series on Service Virtualization in Enterprise Application Development. The series covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle.

The complete white paper can be downloaded at Service Virtualization in Enterprise Application Development. In this post we look at a reference architecture when service architecture is added. Now we can finish solving the problems we encountered in the middle tier. We can create virtual models, modify the models to suit our needs, and enable that parallel development that we were lacking in the previous picture.

Once services are virtualized, and not just hardware, we are good to go for parallel development. Below is a diagram of the architecture:

In addition to virtual hardware, in the back end, we can take those constrained services and system resources we couldn't replicate via hardware virtualization, and make them 24/7 accessible. We can take things that had capacity constraints, for example the performance lab that could only do 10 TPS against the back-end systems, and virtualize it to allow hundreds or thousands of transactions.

I also get data consistency. I can drive the specific data scenarios that I want. I can get predictable, stable data across a variety of systems – even the systems that I do not own and control, and that’s crucial for any distributed system.

And finally, I can desensitize my sensitive systems -- take away those security constraints. The process is very much the same for hardware virtualization or service virtualization. When I virtualize a piece of hardware, I take an image of the disk. In a virtual service, you image the behavior of a particular service. You construct the virtual service from that behavior, and then you deploy it to a virtual service environment. Same steps, but different tools, and different outcomes based on the type of virtualization you are doing.

In summary, you can completely isolate IT from physical constraints by using Service Virtualization. We invite you to explore how this new strategy can deliver the cost savings and agility you expect across the lifecycle of your entire software infrastructure.

That wraps up our overview of Service Virtualization. We believe there is a huge amount of untapped value to be gained from virtualizing the behaviors of the most constrained and changing elements of business IT.

Here are the first five posts in this series. 

Guide to Service Virtualization in Enterprise Application Development – Part One of Six

Guide to Service Virtualization in Enterprise Application Development – Part Two: Hardware Virtualization

Guide to Service Virtualization in Enterprise Application Development - Part Three: Challenges of Access

Guide to Service Virtualization in Enterprise Application Development - Part Four: When No Virtualization is in Use

Guide to Service Virtualization in Enterprise Application Development - Part Five: Leveraging Hardware Virtualization

Guide to Service Virtualization in Enterprise Application Development - Part Five: Leveraging Hardware Virtualization

This is the fifth post in our six part series on, Service Virtualization in Enterprise Application Development. The series covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle. The complete white paper can be downloaded at Service Virtualization in Enterprise Application Development.

In this post, we look at a reference architecture when hardware virtualization is added to the standard architecture presented in my last post. We need to explain this step, because while virtualization at the hardware/OS level is valuable, it is only one form of virtualization for enterprise IT.

Below is a diagram of the architecture.
The market’s concept of hardware virtualization is worth applying, because it’s a good thing and it’s going to get us some value out of the box -- mostly in the middle tier. But there are still issues.
Hardware virtualization gives you the concept of server proliferation (where everybody gets their own server) but it doesn’t require physical assets to do it. This can reduce IT hardware acquisition and support costs significantly.

However, beyond the boxes, we still have difficulties with parallel application development. Realizing that Service2 is not ready for my application to use (e.g., the database in our example above), even running virtualized hardware won’t help me until the development team implements their changes. And unfortunately, I haven’t done anything to alleviate our constraints on accessing the back-end systems; possibly I have made things worse.

Because I still have access issues on the mainframe, I still have capacity constraints throughout development, testing and integration. I still have costly access on the SaaS side, and I still have an insane amount of data volatility, which makes it hard for my team to stabilize the application against the rest of the environment.

Of course, I may also have security concerns when sharing a process among teams, especially when they are distributed across departments or companies. Don't get me wrong -- preventing server proliferation in the datacenter is a good thing, but the largest, most complex systems are not meaningfully affected, and this is still why we need to stay at it and complete our virtualization strategy. In the next post, I will cover what happens when you add service virtualization to the architecture to complete the strategy.

Guide to Service Virtualization in Enterprise Application Development - Part Four: When No Virtualization is in Use

This is the fourth post in our six part series on, Service Virtualization in Enterprise Application Development. The series covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle. The complete white paper can be down loaded at Service Virtualization in Enterprise Application Development.

In this post we look at a reference architecture when no virtualization is in use to set the stage for adding hardware virtualization and then service virtualization. Below is a diagram of the architecture.
 

This is a simplified but typical application that we see all the time in our customer base. In this case applications have access to a middle-tier set of services, which are built into some kind of application server, integration layer, etc. Those services very frequently make calls out to legacy mainframe systems and third-party hosted applications.

There are lots of challenges here without any virtualization in place:

• Server proliferation in the middle tier to support multiple teams & workflows
• Lots of lost productivity while I wait for things like Service2 (above) to be developed
• Increased cost from third party systems because every time I access that SaaS-based solution or that hosted application it’s costing me money
• Increased risk of production issues because of all these things, including the fact that I can’t do as much repeatable testing because of data volatility.

In the next post, I will cover what happens when you add hardware virtualization to the architecture.

Guide to Service Virtualization in Enterprise Application Development - Part Three: Challenges of Access

This is the third post in our six part series on Service Virtualization in Enterprise Application Development. The series covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle.

The complete white paper on Service Virtualization in Enterprise Application Development can be downloaded from itko.com.

In this post, we move from hardware virtualization approaches to the service virtualization concept. Taking the concept of virtualization all the way into the service interactions and behaviors of my interconnected systems opens up new possibilities. When assets make the migration from the real world into the virtual world, they lose their constraints. I can control their behavior, I can control their capacity, their access, and I can constrain them in the ways that I want – not the ways that the real world imposes upon me. This is exactly the technique this paper covers. See an example below.
Let’s look at an example. First, the current physical environment is shown below. This presents several challenges.
 
Access to a mainframe: The trouble here is that because I’m not the only team in the environment, there are dozens of other project teams; therefore I have very infrequent access to the mainframe.
Access to a database: Another other team owns a database that we access. This database already exists; we even have access to it in a development lab, but we need new stored procedures in that database schema. It will take some 3 or 4 months of negotiating and design work to produce those stored procedures.
Access to the web service: There is a legacy system already deployed, and we’ve decided that as an architectural mandate, we are going to use web services to get at the legacy functionality; which is great — except that the web service doesn’t actually exist yet – we’re still shopping the contract so access is months away. All of the above are very real world constraints — these are nothing that we haven’t heard dozens of times from our customers. So let’s see what service virtualization can do to remove these constraints. We will describe the diagram below form the bottom up.

For mainframe access, build a model of the behavior and then host it as a virtual service in a virtual service environment. For database access, construct a model from the database and make changes as needed within minutes. For web access, construct a virtual service from a WSDL, from SOAP documents, from XML samples: whatever you can give the Virtualization team. Now I will go into these concepts in more detail in the next three posts. In the next post, I will cover reference architectures, starting with Stage One, in which no virtualization in use.

Guide to Service Virtualization in Enterprise Application Development – Part Two: Hardware Virtualization

This is the second post in our six part series on, Service Virtualization in Enterprise Application Development. The series covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle. Each post will summarize the key points within a section of the paper. The complete white paper can be downloaded at "Service Virtualization in Enterprise Application Development."

In this post we look at hardware virtualization, how it works, and why it is not a complete strategy. Most current forms of virtualization in IT could be described as hardware virtualization and they provide the three benefits we covered in the last post. Hardware virtualization creates simulators of hardware behavior, but they are actually intelligent proxies to the physical world. These proxies have the ability to negotiate with the virtual environment in which they are deployed, so they do not require exclusive access to the hardware they represent offering more flexibility.

Hardware virtualization has generated a lot of buzz for immediately realized cost savings. In most cases tools image the existing physical asset by cloning the hard disk contents. From this image, the tool constructs a virtual machine that can be put to use.

However, stopping here is not a complete strategy. First, there are many systems that simply cannot be imaged as the hardware virtualization process above defines. Examples include: Systems not on Intel-class servers like mainframes, externally hosted partner services, SaaS, cloud-based systems, and systems that are under a high degree of change. These assets are often the most mission-critical and the most costly to provide access and increased capacity.

In addition, you cannot virtualize beyond the limits of your physical world; this means additional hardware purchases are still a frequent reality. So where hardware virtualization is possible, it clearly reduces the hardware acquisition component of TCO, but that is only a small component of TCO. In the next post, I will cover how the service virtualization concept can greatly expand the benefits of virtualization.

Guide to Service Virtualization in Enterprise Application Development – Part One of Six

 This post begins a six-part commentary based on our white paper, Service Virtualization in Enterprise Application Development. It covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle. Each post will informally discuss some key points I'd like to make in conjunction with the paper.

Leading technology and business analysts cite the adoption of Virtualization as one of the most significant technology priorities of this decade. Virtualization at the hardware and data center level generates an almost immediate payback in with many millions saved IT operations costs. However, as we discuss in this paper, solely focusing on hardware Virtualization, we are leaving savings in both time and money on the table. In this post we will define virtualization in a general sense (traits both hardware virtualization and Service Virtualization share) and cover three main benefits.

Virtualization is the practice of simulating the behavior of a physical asset, such as a server or application, in a software emulator, and hosting that emulator in a virtual environment. The virtual environment behaves enough like the physical environment that communication with the emulated asset is just like the real thing. There are a number of value propositions associated with this practice.

• First, virtualization allows us to better manage physical assets. For example, many enterprises have troublesome configuration and change management issues. The additional abstraction of a virtual environment makes best practices around change and configuration management easier.
• Second, we can better leverage the capacity of physical assets with virtualization. Instead of every team acquiring its own hardware platforms for development, QA, and integration testing, the same servers can be leveraged between disciplines and even across teams. The goal here is to stem the tide of server proliferation.
• Third, virtualization helps organizations to be more agile. It is easier to reconfigure people than physical hardware resources. Virtualization increase the flexibility of the physical assets as we can better access the applications and services that we need immediately, and without time delays waiting on IT to switch servers or perform other reconfigurations.

In the next post we will look at how hardware virtualization sets the stage for added benefits from service virtualization. The complete white paper can be down loaded in our Resources section: Service Virtualization in Enterprise Application Development.

Sizing the Opportunity for IT to Cut Carbon Emissions

A recent McKinsey report, How IT can cut carbon emissions, reported that the carbon footprint associated with IT, including laptops and PCs, data centers and computing networks, mobile phones, and telecommunications networks, could make them among the biggest greenhouse gas emitters by 2020. IT now accounts for 0.86 metric gigatons of emissions a year, or about 2 percent of the emissions added to the atmosphere globally. However, the McKinsey report predicted that the increasing need for IT could significantly drive up that figure.  They write, “by 2020, they (IT) will account for about 3 percent of all emissions: 1.54 metric gigatons, or twice what the United Kingdom produces today.” The report adds that, “the adoption and use of information and communications technologies in China, India, and other developing economies will account for much of this growth.”

As a Baylor alum I recently had a chance to attend a BBN talk with HP's CEO Mark Hurd, and he put it in an interesting light. Our hunger for accessing, using and storing data is increasing exponentially every year - and it is moving faster than Moore's law - the exponential increase in how much data our processing systems can effectively manage. That puts a lot of attention on innovating to reduce heat in high-powered processors, and the energy consumption associated with trying to keep it down. We will need to continue to innovate in reducing the energy cost of all of that data in the data center with more efficient systems.

On the good news side the McKinsey report said that there is the potential for IT products to help abate far more emissions in the general economy than their own production and use generates. The authors looked at things like smarter use of energy in buildings and greater efficiency in motors used in manufacturing. However, they also studied the possibility of reducing emissions by “dematerializing” physical goods and processes through telecommuting, video conferencing, Internet shopping, and downloading content rather than physical objects using paper, CDs, DVDs and found that there are great opportunities here also.  They concluded that information and communications technologies that promote abatement will “create attractive growth opportunities for those companies.”

This is good news as Virtualization (another way to say dematerializing) is a major opportunity for SOA to help with the global warming crisis. We have written about the opportunities for greater business efficiency with virtualization (e.g., Outlook Interview Part Four: Virtualization and Testing and  Can Virtual Environments take Performance & Load Testing?  This all leads to energy efficiency as less power is used by factors of ten or more when you can virtualize aspects of testing and validation. Here is another positive impact that may increase market demand for more environmentally friendly technologies.  Joe McKendrick recently discussed the cost saving side of SOA in his post, Service Oriented Architecture on $10 a day, and how it might do well in today's down economy. "Web services were forged in the dot-com era, but were, quite simply, pressed into service as a very low-cost way to work around very complex integration projects with reusable code."

Joe goes on to provide some good advice on SOA in a down market. This all can start by starting “with the smallest business process you can find that is the most inefficient, where the inefficiency is caused by an aspect of continuous change (a lack of agility) and the business is nevertheless forced to continue to invest in that inefficient business process.”

Of course all of this is an adjunct to the things we can personally do to reduce environmental impact. Especially in business - companies are now more compatible than ever with telecommuting, and "virtual meetings" which can have a dramatic impact on our carbon footprint.

Agile SOA Across the Lifecycle - Part Four: IT Operations, Monitoring & Performance

This is the fourth of a six part series of posts on how SOA works within the Agile life cycle. Here we will look at IT operations, monitoring and performance. Once an enterprise application is in deployment and under use, ensuring its continued availability, performance and accuracy becomes critical to the business. IT Operations teams may be part of the overall test and development team, or grouped as a separate function in many enterprises to offer a measure of impartiality to ensuring that required Service Levels are met within the live application environment.

Operations Management and Monitoring

The leading monitoring frameworks can be supported by directly testing and validating the systems under management, and feeding rich metrics and test output directly into the team’s IT Management dashboard, such as Wily/CA Unicenter, TIBCO Hawk, HP OpenView, IBM Tivoli, and others. As an example, our LISA tests can be run continuously at runtime and act as a listener for both functional errors, and server metrics from components including JMX, SNMP, Windows Perfmon and LISA’s own types of metrics.

The Operations team can set thresholds or boundary conditions on these continuous tests and have the Testing framework alert them if an issue occurs. For instance, if performance is too slow, or memory usage or a certain database table increases in an unexpected way over time, the test should report a failure to the management dashboard, and send an SMS message to the admin, along with the test case for root cause analysis and correction. LISA can also output this data as reports into the team’s management tools or data store to provide the ability to perform audits.

Performance & Load Testing with Leading Tools and a Virtual Service Environment (VSE)

Also key to the Operations team is ensuring that delivered systems will meet expected Service Level Agreements (SLAs) for customers. For today’s highly interconnected applications, the leading Test and Performance Lab solutions on the market were left out of the lifecycle of applications until near the end, when an interface or a complete system environment was available to test. A Virtual Service Environment (or VSE) provides teams using Performance Testing tools like LoadRunner and SilkTest the ability to get involved in ensuring performance much earlier in the lifecycle, at up to a 90% reduced cost per test environment.

The VSE captures and simulates the expected behavior and response times all of the dependent systems within your target environment. As component load tests are conducted earlier, teams can optimize their use of system resources, find memory leaks and fix the root causes of errors, at a much earlier stage in the design and development lifecycle, without needing access to the live system or all of the interdependent components needed in the test environment. The ability for multiple teams to conduct their own performance testing processes in parallel, prior to solution delivery, pays huge dividends in productivity and quality in deployment.

Behavioral Service Virtualization in this sense is by no means a replacement for virtualizing hardware and network resources to save costs in IT operations. But it does represent a huge way to reduce the dependencies and costs that can't be touched by virtualizing a given set of servers - after all, there are many third party or shared Services in the cloud, or heavy transaction systems and partner systems that can't be virtualized by conventional means.

Michael Vizard of eWeek writes about the role of virtualization in his post, Network Management Gets Virtual. He writes that many vendors are saying that, “it's become critical to extend existing network and systems management tools into the realm of virtualization. They argue that IT organizations don't need to invest in learning separate management tools for physical and virtual environments and the impact of decisions in one environment can be devastating on another unless the management infrastructure for both are tightly coupled.”

This tight coupling can occur under LISA. Using a VSE, teams can either model incomplete components, or capture live services, and simulate their behavior on a running server. Functionally and under load, these Virtual Services hosted in LISA’s VSE act and respond just like other services, databases and systems you connect to in the live deployment, including expected response and transaction times. Without requiring access to critical live systems, the team can connect their component to the rest of the virtual architecture in LISA Virtualize, and conduct performance and load testing with their tools of choice.

It is important to note that most companies have significant investments in test lab tools, and supporting them with robust target test beds makes those labs much more productive within the software lifecycle. Of course, our LISA Test & Validation solutions can also be that load and pefromance testing engine, and LISA test suites are executable and interoperable with the Test Management, ALM and SOA Governance processes mentioned in this series.

In our next post, we will look at IT and SOA governance. You can download this complete series in the Whitepaper on "Agile SOA" at our ITKO LISA resources page. 

Real time from SOA/Cloud/Virtualization World - Plaques

Hey, we are here in San Jose for SYS-CON's "super connection" show of SOA World / Virtualization Conference / Cloud Computing Expo (and probably a few others). Rajeev is going on in about an hour to talk about "Peeling the Onion" of SOA.

I just got down to the booth and had 2 surprises:

• (uh-oh) Where's my signs? (I'm sure we'll sort that out in a bit.)
• (great) However, HEY, the nice folks here gave us 2 nice pieces of decor which really brighten things up - award nominations for LISA Virtualize:

- SOA World Show Awards 2008: Best Integration Solution
- Cloud Computing Show Awards 2008: Best Cloud Management Solution

Much thanks to SYS-CON for brightening our week here. We have been excited about the capabilites and future for LISA Virtualize - going far beyond our known presence in SOA testing & Validation.

iTKO talking at SYS-CON's SOA - Virtualization - Cloud Computing Event Nov. 19-21

SYS-CON Events announced today that more than 40 Cloud technology providers, as well as Virtualization and SOA companies will exhibit at the upcoming First International Cloud Computing Conference & Expo on November 19-21, in San Jose, California. It's co-located with SOAworld West and Virtualization Expo - so attendees can pick and choose topics from all three agendas. We will be there and we're looking forward to seeing how practitioners will bridge these three disciplines.

iTKO's Rajeev Gupta, Director, Solutions Delivery will present at 9:00 AM on Thursday, Nov. 20 - on "Peel the Onion, Lose the Tears: Test, Validate and Virtualize Every Layer of SOA" at the Virtualization Conference. The session will provide best practices and real-world examples of our customers that are testing, validating and virtualizing every component of the architecture, across multiple teams, on a continuous basis, to ensure trust and reliability.

A lot of the Cloud is seeping into the practice of both SOA and virtualization. This makes a lot of sense, as SOA is by nature decoupled and leverages distributed software components and logic, much of which will be hosted in the Cloud (see eBay, Google, SalesForce and others we use every day). At the same time we are seeing a need to Virtualize the behaviors of critical Cloud-based services such as transaction and inventory systems, to help teams reduce the cost and dependencies of developing and testing against them.

SYS-CON points to the growing market in cloud computing. Over the next five years, IDC expects spending on IT cloud services to grow almost threefold, reaching $42 billion by 2012 and accounting for 9% of revenues in five key market segments. More importantly, spending on cloud computing will accelerate throughout the forecast period, capturing 25% of IT spending growth in 2012 and nearly a third of growth the following year.

Making IT More Green and Saving Money at the Same Time Through SOA

Saving money though reducing the environmental impact of IT has gained increased urgency in our down economy. Green computing even has a Wikipedia entry. Fortunately, many of the Green IT efforts also result in cost reduction. One of our business partners, Software AG, has looked at ways that SOA can help here – see Eco-computing: Software AG and the Hasso Plattner Institute Demonstrate SOA’s Green Potential.

Software AG and the Potsdam-based Hasso Plattner Institute for Software Systems Engineering (HPI) completed a one-year research project examining the impact of service-oriented architecture (SOA) governance on Green IT practices. They developed methods and tools for optimizing resource sharing of IT services, thereby reducing energy consumption and lowering hardware costs. Using these methods, administrators of complex IT landscapes can determine exactly how much computing power is needed, as well as the maximum amount of energy each service might use. With proper SOA governance you can regulate and more tightly control energy costs by taking advantage of the more efficient distribution of services that SOA can bring. This makes sense and is one more reason to make sure your SOA governance is carefully conceived.

There are other ways SOA can have a positive eco-impact, as well as a bottom line impact. For example, virtualization of hardware saves the materials and energy consumption of so many servers - as much as 10 to 1. Most companies have already gone that far, but what about the kinds of applications that are too distributed (i.e. shared services and Cloud-based apps) or too monolithic (i.e. mainframes, major enterprise apps) to be replicated via hardware virtualization?

We call this Service Virtualization and it allows the behavior of complex SOA applications to be captured and simulated - which is key to achieving the productivity and efficiency you expect from SOA. Therefore, if you could save the cost of attempting to replicate several distributed applications and services, that's saving a lot more processing power throughout the lifecycle and not just servers in your own data center. In addition, it allows you to scale down hardware and processing power in your test lab, and in deployment, as you no longer have to try to make a live instance available to so many teams, or scale up the hardware of the live instance to handle a bunch of extra capacity.

There are more savings to be harvested. When you break up project teams into smaller "agile" teams focused on enabling certain Services for use and reuse, you gain additional efficiencies besides Agility and labor cost savings (see our recent paper: "Agility Across the SOA Lifecycle" for more).

Think about the reduced need for travel, and for dozens of people to occupy an office configuring and maintaining separate test environments per partner and per test/development team. The more we can do to decouple our dependencies on constrained servers and applications, and decouple our interdepency on other teams' lifecycles through service virtualization, the bigger the positive ripple effect between the interaction of technology and the environment.

We welcome any discussion and ideas about how Virtualization in a Service-Oriented World can make a difference in the world.

VMware – Sixth in Our Series on Software Community Blogs

VMware, one of our partners, has the VMNT blog which provides virtualization news from VMware and the community of virtualization users, including the VMware Communities and VMTN, the VMware Technology Network. This blog also lists 17 other VMware blogs, each with a specific focus.  There is the Console blog that is VMware's Executive Blog. It has contributions from a number of VMware executives. The Develop Center Blog supports their developer community.  There is the WMware PhD blog that provides education on VMware products.

Ed Albanese,
Product Management, 
VMware Application Virtualization Technologies writes the VMware Application Virtualization blog.  The VI Team Blog provides implementation tips. The VIX API Blog discusses the VMware VIX API which allows you to automate VM and guest operations on VMware Server, Workstation and ESX.

The blog, VMware: Virtual Reality, carries the subtitle, Setting the Record Straight One Post at a Time.  It responds to industry claims. There is a nice review of Why Choose VMware that provides their competitive differentiation is a single clear post.  The one prior to it addresses claims by Microsoft. There are others such as VROOM! by the VMware performance team. It is nice to see a focused set of blogs that cover a range of issues.

The VMware blogs also list 22 WMware employee blogs and provide a longer list of blogs on Virtualization. The VWware employee blogs are individual efforts, a good way to advance the advocacy of Virtualization for their community of practitioners with real examples.

Skytap Provides Cloud Access and Licensing for ISV Solutions; ITKO LISA is an Initial Partner

Skytap, Inc., a leading provider of cloud-based virtual lab solutions, today announced its Independent Software Vendor (ISV) Alliance program to enable on-demand distribution of commercial software solutions through its Virtual Lab platform. Skytap's initial ISV partners include ITKO LISA. Skytap's Virtual Lab automation platform, combined with ITKO LISA, will enable customers to dynamically spin up entire IT environments for service-oriented testing or training labs.

I'm here at STARwest in hot Anaheim, CA, and a lot of the people I'm talking to are mighty curious about how Virtual Test Labs happen in the Cloud. For us, the ability to Virtualize a service-based application, and provision it with Skytap's virtual hardware, represents a great way to get the validation you need without the provisioning nightmare.

 

We think this is a great application for where the cloud is going - just like SOA, it is going to need better ways to test and validate the infrastructure (even if virtual) for expected business outcomes. Joe McKendrick mentioned my last post on this in his Service-Oriented blog on ZDnet: "SOA soon part of the Cloud: Hold that thought." The great thing is, if providers and customers are already thinking about these quality issues up front, the adoption of the Cloud model will catch up (and become part of) the wave of SOA.

Skytap allows companies to run their existing applications and virtual machines unchanged to take advantage of cloud economics without a major application rewrite. The company's Web services API and one-click VPN functionality allow organizations to create a "hybrid" IT model whereby cloud resources can be used and managed as an extension of existing onsite IT environments. With the introduction of the Skytap ISV alliance program, customers can now also access software from leading ISVs within the Skytap environment and gain the benefits of a pay-as-you-go model for the ISV software.

Jim Mackay, our CMO, said, "The cost model for using LISA Virtualize as a test and validation environment in the cloud makes perfect sense. In addition to offering Skytap customers complete SOA testing capabilities, LISA Virtualize abstracts away the actual system under test from dependencies on partner systems and third party resources, which means huge cost savings, as well as a much more rapid way to stand up a complex SOA environment."

Validation of cloud services makes them reliable for business. Virtualization of cloud services makes them available throughout the lifecycle. It's like two waves coming together for a bigger, stronger wave. Who can argue with that?

Outlook Interview Part Four: Virtualization and Testing

Here is part 4 of my recent interview with host Mike Lippis of the Outlook Series. We have broken the 45 minute podcast interview into five parts for easier reading. This section covers virtualization for SOA and how it affects the development and testing teams' productivity.

Mike:  “With this virtualized service edition of LISA.  What are you doing in the area of parallel development and test cycles?”

John:  “What we do is enable that parallel development, because we’re trying to decouple those service providers and consumers from each other during their lifecycle. 

“So a very reasonable approach towards meeting this kind of objective is that I might go through a requirement phase and a design phase and as I start development, I can discover my dependent systems, virtualize those dependent systems and then execute my development plan against my virtual services.  When I do this, I am decoupled from all of those constraints on my peers or on all those other services.

“The reason that I do this is because:  we’ve all heard our development leads say, ‘by the way I haven’t been able to do anything today because the “so & so system” is down.’  Or, ‘remember…they gave us a new build yesterday? Well the new build doesn’t work … they broke one of the major operations. So my team hasn’t had any productive time during the last two days.’ 

“We hear this all the time … this live connectivity to everybody (remember that white board I just mentioned a minute ago?)  Live connectivity to all of these boxes creates a large amount of friction or construction barriers, if you will, in the road. 

“What we can do, by isolating ourselves from that through virtualization, is we can parallel that development activity and, of course as a part of our final integration testing we go from virtual back to live services.  Once we are all live, we can obviously make sure that everything inter-operates the way we expect.  The value here is that instead of having to wait for my dependencies to complete, I can run in parallel with my dependency and get it done faster. 

“A quick example of this is:  If I’m asking you to implement a new feature in your service, I have two choices:  I either ask you to make that change and wait for you to make that change, test that change, produce that change into a build for me and make it available, or I can use a virtual service.

“I can make the change in the virtual model very quickly (we are talking minutes to do this with our product) … and I can be developing in parallel against the virtual version of your service just an hour or two later.  Meanwhile, you’ll take weeks to produce a new version but I’m developing against the new version in parallel in a virtual world.  Once your service is complete, I can point my application away from the virtual edition, and instead to the live edition, and we can make sure that it actually works as we expect.”

Mike:  “When it comes to testing in this area, we certainly want to simulate as many data set combinations as possible to see how effectively that this solution is working; how robust would release be in that area in terms of being able to simulate data set combinations?”

John:  “We’ve spent a lot of time on this.  It turns out … as we embarked on this virtualization strategy, we knew that virtualizing data layers would be a big thing, but I can’t tell you how many times I’ve heard our customers say “this is the big thing.”  It’s because of all this data synchronization, and all of this volatility of data – every team wants to reset the database every time they run their test and every time that they do a development cycle, and that means that no two teams can be sharing the database at the same time, and it’s always a mess!  We’ve spent a lot more time here than we’ve even thought and we’ve solved a lot of problems here.

“A classic example of this is:  When you are working on the purchase ordering system, and the supplier system is your partner, you don’t actually produce the supplier’s service, but you talk to a supplier … and yet you’re supposed to build an application that tightly integrates with your supplier … how do you do this?  Well again, you virtualize either at the behavioral layer or the data layer.  And, why do you virtualize at the data layer?

“Think about it … the supplier could respond to a PO request by supplying all of the requested goods at the requested date with no issue; but the supplier could just as easily split the order, could partially cancel, could respond to you that these items were no longer carried, could warn you with a credit check, could warn you … The number of possible data scenarios in the response to a requested PO -- it reaches the point where we wonder how we can possibly test all these out. 

“Since we can’t drive data scenarios in live systems, we can’t drive data scenarios with our partners -- at least we can’t effectively -- we need to virtualize that database so that we can drive all those.  I can make certain that every kind of possible response to a PO request is available to me all of the time.  That’s what data virtualization does for us.  It makes me able to make certain that every time I need the stars to align a certain way for me to make a certain condition occur, I can do that.  I’m certainly not strong enough to literally make the stars align but, in a virtual world I can, so in that way I can always make sure that everything works the way I expected.”

Mike:  “There are a number of load and performance testing tools such as LoadRunner or SilkPerformer, and a lot of companies have made investments in those technologies, so how can they leverage those investments that they’ve made and expand on those with LISA Virtual Service Edition?”

John:  “That’s absolutely true Mike, there’s plenty of successful LoadRunner shops and SilkPerformer shops and others, and LISA does load testing, but we’re certainly not interested in trying to fix what’s not broken.  We’re certainly quite comfortable with working with companies who are doing load testing with LoadRunner.  A number of our virtual services environment customers are doing exactly that.

“In fact, if you picture in your mind:  the left-hand side of the graphic is Load Runner generating a load on a system in the middle of this graphic and on the right-hand side of this graphic is LISA Virtual Services environment.  What we do is enable more and better load testing even with the tools that we did not provide.  What we’re doing is we’re freeing the system that you’re testing from its constraints.  We’re not eliminating that system nor are we trying to affect the load test product itself.  We’re actually trying to virtualize away the constraints on the right hand side of the graphic. 

“So, it’s LoadRunner, versus the System Under Test, which can be LISA … and that triad, if you will, makes for a very powerful load testing combination.  What we have found is that you have to have production hardware or at least a reasonable production performance lab for your own application. 

“Our customers understand this, what they have trouble with is:  ‘Wait a minute, my application no longer lives on its own island, it now goes and invokes its own transactions on a main frame or it now integrates between a TIBCO-based system or this web message-based system and it goes and talks to this ERP system.’ 

“In order for me to performance test my application, my performance lab just went from a half million-dollar investment to a five million-dollar investment … and that’s what they can’t do.  So when you go Load Runner/Your Application/LISA, you eliminate the five million-dollar investment. You literally eliminate it.  What you go from instead is the half million-dollar investment in your hardware platform -- what you have to run your application and your service on, and we virtualize away all the heavy iron that you have to connect to.  We put that on a commodity box, what would be a rounding area on a half-million dollar investment -- we would run on a $20,000 server.”

[This concludes part four. In the next post we wrap up the interview and provide an overview of ITKO.]

Blowing Smoke? 3 Tests for the Cloud's Future

We couldn't help but notice how fast Cloud Computing has gone to the top of the hype cycle over the last month. You could say the Cloud is "the internet" in general and it has been there all along, and in fact it may have been referenced 10 or more years ago. This time it is new and improved, and it is really getting attention as a philosophy that is broader than SOA - you can't click twice in your IT news feed without sniffing this version of the Cloud.

Alas, this is probably the time that the big SaaS and internet platform providers like eBay and Amazon, Google and Salesforce, really come of age. Joe McKendrick recently put out some good coverage on this on his FastForward blog, "Cloud Computing: Uh Oh, Now It’s Getting Serious".

To us, this is not a mind-blowing concept -- it is a natural move for services, and applications to "live" in the cloud. However, there are 3 tests that Cloud Computing will need to overcome if it is indeed going to become the air we breathe:

1. There is no "free beer" for consumption of the Cloud.
Just like we saw a few years ago in SOA, there a perception that Cloud resources will be freely available for use in designing and building your architectures. But that is not a sustainable model. And no it's not going to be supported by advertising (on your iPhone for Facebook, etc.). If someone is offering an application that we rely on, they will need to ensure that they cover those support costs, and that the consumers are using the applications in ways that can be supported without unduly impacting other users of the cloud. Strong Validation of new offering and intended uses puts responsibility for reliability on both the producer, and consumer of Cloud resources. If there is healthy competition in the Cloud Computing market, the most reliable applications will win the most subscription dollars or usage fees.

2. There is still dependency, in fact, dependency may increase.
So if you are relying on the Cloud to provide data, transactions and other services, how can you test and validate your own business workflows and continue to evolve, if the Cloud may either not be available or ready to take your team's test and development transactions? Lack of ability to validate your own business applications against Cloud resources creates a huge bottleneck to productivity and agility. This is where behavioral Virtualization of the Cloud becomes of primary importance. If you could capture and simulate your expected interactions with the Cloud, that would eliminate a lot of the dependency and bring back the agility you expected.

3.  Fad resistance. (Uh, what were we talking about again?)
When the Cloud hype dissipates, how will this IT approach be driven by business, and not by the "coolness" of the technology? The world's leading companies will be taking more cautious wing-flaps into the Cloud - after all, they are still working on integrating and consolidating their most critical live applications for end customers. Vendors will continue to attempt to assert dominance over the definition of Cloud Computing - you might call it a shared Grid for a variety of apps, or a suite of apps running as a SaaS on a hosted provider's servers. Interoperability definitions and standards will be in flux. Nobody wants to be left behind when the definition and practice continues to change, and it certainly will continue to evolve.

We have been asked about this a lot lately, in terms of how to test, validate and virtualize Cloud Computing environments. And what we've found is that most of the same concepts that we saw in SOA apply to the Cloud - if you are going to rely on these services and apps for business, the risks have to be mitigated with continuous testing, and you need to isolate your own teams from dependency on the Cloud by virtualizing those behaviors. In this way, you can reap the benefits of ubiquitous availability of Cloud resources (services and data) as a platform for your apps, while still being able to productively design, test and develop (and keep working) when the cloud isn't available.

Anyway, this is just an initial take on the topic. We will be there at SYS-CON's first "cloud computing expo" in San Jose in November, and talking much more about how cutting edge companies are making the cloud work for business in the future.

Gartner SOA Design Patterns Call for Complex Testing and Validation Requirements

While we find many enterprise customers don't make the distinction between design patterns -- they either call it "enterprise integration" or SOA, yet there are some interesting ways to break down the patterns so you can look at your own unique situation in that light.

Tony Cook recently posted Gartner: SOA Design Patterns, on the service oriented enterprise blog.  He covers the five design patterns observed by Gartner analysts and comments on each.  They are:
1. Multichannel Applications
2. Composite Applications
3. Business Process Orchestration
4. Service Oriented Enterprise
5. Federated SOA

It strikes me how each of these raises the complexity bar for testing and validation. As Tony writes, Multichannel Applications separate back-end business logic from front-end logic and deliver full application functionality to a maximum number of users from various channels. This multi-channel delivery ups the validation requirements.  Composite applications are often drawing from multiple data sources that the company might tightly control, but those components are often created for very different business reasons. This is an area that requires ongoing validation to make sure the multiple sources stay on course - even if they are centrally managed.

Business process management (BPM) uses a metadata repository to manage the proceedings of the business process model at runtime. Implementation requires solid business logic testing. Tony writes that the SOA-based enterprise model is a step beyond composite applications, as all applications are perceived as components of one integrated whole. This integrated whole is created from reusable components, so the same ongoing validation requirements for composite applications come into play. Federated SOA logically splits the enterprise into semi-independent SOA domains. These domains are then federated to enable inter-domain sharing of services. Here is another scene for the necessity of ongoing validation. In this realm, we have found that actual US federal agencies are leading the charge -- they call it a "Net-Centric" approach of sharing and instilling Trust across agencies.

You can buck classification, but face it, if you are integrating multiple enterprise IT assets, you fall somewhere along the axis of either highly disparate (composite) use of controlled assets, or highly controlled (federated) integration of disparate assets. Either way, you want to increase your ability to deliver functionality better and faster amidst complexity and change.

Therefore, comprehensive testing and validation is a requirement -- otherwise, trust between the teams that build and control those Services is hard to come by.  As some of the contributing services may be in various stages of development, virtualization of service behaviors can also help speed things along by making the constrained or unavailable service available for this activity.