In the third part of my three-part YouTube series, I highlight how Service Virtualization offers a better alternative to today's cumbersome enterprise release process and how a journey that now takes nine-months can be completed in less than a month.

Most large companies go through massive, heavily constrained enterprise releases. They begin with long development cycles that overlap with other development cycles and then they implement a variety of test and integration test activities. The end result is that the change the business wanted quickly, and that development said would take two days, becomes a nine-month train trip to market.

We’re all frustrated with this process and we don’t know what to do about it. All of our systems are so interconnected that after months and months in development we’ve touched pretty much everything by the time we’re ready to go to integration testing. That means our integration test cycles are huge and very difficult to get through.

If we really leverage Service Virtualization and take it all the way, we see that there is a better alternative. If we are doing development and continuous integration type testing in a more live-like environment, we can implement an incremental integration test approach. Development doesn't take nine months. It's completed in a two week scrum. The entire landscape hasn't been changed. Only three applications at a time will be changed so I can accomplish one delivery into production. Only three live systems will be integration tested. The rest of the landscape will be virtual services. Performance testing and user acceptance testing can also be done in the same time frame.

Many companies use virtual services to do monthly releases, or for a break-fix on an immediate basis, or to change one application and take it through a quick test cycle and get it into production. You can take that same approach even with integration level issues by doing incremental integration tests based on virtual services capabilities.

With Service Virtualization, the nine-month train trip is over. If it’s a two day development effort, the change is made in the required systems in a two-week scrum. Next comes one week of incremental integration tests and then you take that change to production.

This is the beginning of the end for an enterprise release cycle that is anti-agile and unresponsive to the requirements of the business.

John Michelsen's Software Development Life Cycle Series

Part 1: Your SDLC Process Does Not Change 

Part 2: Improving the SDLC with Service Virtualization