CA John Michelsen - Oracle OpenWorld 2012 - "ServiceVirtualization Reality is Overrated"

796 views

Published on

CA CTO, inventor of SV and author John Michelsen's presentation at Oracle OpenWorld #OOW 2012. To truly achieve Agile development, enterprises need a "virtual world" to avoid constraints in software development. Service Virtualization is a new technology and practice of simulating and modeling any service or system dependency needed by teams throughout development, integration, functional and performance testing activities. Other industries from avionics to pharma already understand the power of simulation and virtual "wind tunnels" throughout design and development, and now it's time for software and IT innovation to follow this route to more consistent quality and innovation speed with SV. For more info, visit CA.com or see the community at http://servicevirtualization.com.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
796
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Copyright © 2010 CA. All rights reserved.
  • Copyright © 2010 CA. All rights reserved.
  • Copyright © 2010 CA. All rights reserved.
  • 80% of all new applications are composite based Agile has replaced waterfall as the development method of choice 70% of the information needed by a developer is not available – no access or not owned SaaS and Cloud-powered customer apps have created “instant on” mentality Current platform vendors have no suitable offering for these transformational projects Address constraints and behavior and the primary challenges of this spaghetti and meatballs. Copyright © 2010 CA. All rights reserved.
  • We know how complex enterprise application architectures have become. This is what motivates us... What drove our thinking to create LISA. More complex and changing your architecture, the better for us. Main Point: Do you have an IT architecture like this? IT architectures are becoming more distributed, more heterogeneous, and more complex. There are several moving parts behind enterprise apps today. Each point of connection becomes a potential point of failure in production, and we don’t always have all of the systems that impact our business under control. This can create significant problems in ensuring application quality. ------------------
  • Using traditional waterfall methodologies for developing software, much of the activity of development and testing of the application happens in a series of steps, one after another. But, with CA LISA, by eliminating those constraints common in typical software development approaches, much of the SDLC becomes parallel. This difference, customer after customer, has been shown to be 25%-50% We achieve this with a couple of specific capabilities: First, developers now have their own private environments for developing code. They don’t share environments, and don’t need to wait for other developers to create new services they use provided a contract of how the service to-be-developed behaves is available. Second, much of the testing at a component level can “shift left”, or be moved earlier in the SDLC. Because each component can be tested individually instead of waiting for a complete assembly, unit and regression testing happens sooner, is more complete, and defects are identified long before integration or user acceptance testing. Finding bugs earlier means developers fix issues now instead of moving on to new releases or other projects before the defects are identified, and costs to remediate are substantially higher. As customers mature with their use of Lisa, regression and individual component testing becomes increasingly automated. Automation and validation as early as code check-in is possible, finding bugs earlier and far more consistently than manual and UI testing methods. This is possible because service virtualization allows this component level testing in isolation, without underlying dependencies. Once automation is implemented, one can easily make it a continuous process. Using this approach, any change breaking interfaces, contracts or use patterns is easily and automatically detected before the code disrupts other services or applications. Finding defects earlier and moving these steps into parallel on a component-by-component basis saves tremendous calendar time from a project. The LISA deployment at ANZ Bank solved two critical challenges… First, by eliminating system dependencies, testing began far earlier in the development cycle. Defects in code no longer lurked until UAT, but instead were found far earlier. Additionally, ANZ’s formally serial processes were set in parallel, dramatically reducing release times. Copyright © 2010 CA. All rights reserved.
  • Copyright © 2010 CA. All rights reserved.
  • Copyright © 2010 CA. All rights reserved.
  • May 16, 2010 [Presentation Name via Insert tab > Header & Footer] Copyright © 2010 CA
  • May 16, 2010 [Presentation Name via Insert tab > Header & Footer] Copyright © 2010 CA
  • May 16, 2010 [Presentation Name via Insert tab > Header & Footer] Copyright © 2010 CA
  • Copyright © 2010 CA. All rights reserved.
  • Copyright © 2010 CA. All rights reserved.
  • Copyright © 2010 CA. All rights reserved.
  • Copyright © 2010 CA. All rights reserved.
  • Copyright © 2010 CA. All rights reserved.
  • May 16, 2010 [Presentation Name via Insert tab > Header & Footer] Copyright © 2010 CA
  • May 16, 2010 [Presentation Name via Insert tab > Header & Footer] Copyright © 2010 CA
  • Copyright © 2010 CA. All rights reserved.
  • CA John Michelsen - Oracle OpenWorld 2012 - "ServiceVirtualization Reality is Overrated"

    1. 1. Reality is Overrated:Enterprise Agile Requires aVirtual WorldJohn MichelsenCTO, CA Technologies
    2. 2. innovate or die  The Product is the entire brand and customer experience  Service oriented products are delivered late, over budget and with questionable quality…WHY? Copyright © 2012 CA. All rights reserved.
    3. 3. changes in software development Constraints Composite Complexity (Custom Applications, Costs SOA, Cloud) Client/Server (Packaged Apps such as SAP, Siebel, Oracle…) Mainframe … 1980 … 1985 … 1990 … 1995 … 2000 … 2005 … 2010 … 2015 Copyright © 2012 CA. All rights reserved.
    4. 4. Change and Complexity Increasing CRM Routing Help App Collaboration Web Service Engine Portal Virtual Web/WAP BI Tools App Interface Service Interface External Partners Cloud Content Database Business EJB SOAP Rules ESB Data Internal Warehouse Legacy BPMS File Products System Infrastructure Messaging Financials Service RMI Objects Mainframe# of Interconnected # of Heterogeneous # of Interdependent Teams Rate of Change Components Technologies
    5. 5. I said REALLY complex
    6. 6. Agile goals move out of reach due to realityAgile Goal: Faster iterations and releases Dev 1 (Goal: rapid releases and Integration check-ins, faster delivery) Dev 2 Performance UAT Dev 3Reality: Schedule conflicts make Agile become Waterfall Dev 1 Dev 1a Dev 2 Integration Performance UAT Dev 3 New Dev 33 New Dev Waiting for Waiting for Conflicts Conflicts Teams Teams release release Dev 22to Dev to appear at appear at waiting for waiting for affects Dev 11 affects Dev complete complete Integration Integration environments environments
    7. 7. the big problem: constraints INCOMPLETE DEVELOPMENT ESB ACCESS FEES SYSTEM MAINFRAME DATA LEGACY EXTERNAL UNAVAILABLE INVALID DATA“I can’t do anything until I have everything… and I never have everything!” Copyright © 2012 CA. All rights reserved.
    8. 8. solution: service virtualization ESB MAINFRAME DATA LEGACY EXTERNAL Copyright © 2012 CA. All rights reserved.
    9. 9. Meditation: Service Virtualization is like…  The Holodeck in Star Trek  A fake Wild West Town  Complete with stuntmen to shoot at  An Electronics Test Harness But our favorite is… Patagonia, Argentina 2008. Photo: Jason English
    10. 10. Flight and avionics simulation
    11. 11. service virtualization how does it work?1. Capture 2. Model 3. SimulateRecord conversation Client App Client App Assign context with service virtualizationdata, protocols used, to data, behavior as a “stand in” forresponse times & performance development dependencies App Current App Current App Under App Under Version Version Development Development Dev/Test teams Listen to Live traffic Listen to Live traffic vMF1 vSaaS Mainframe Mainframe SaaS Use SV for development Use SV for development Structured Conversations Heuristics Sophisticated Behavior Observe & Understand Analytics Dynamic Properties (Dates, values, etc.) Protocol-Level Algorithms Scenario Support  Recorded traffic State Test Data Sanitation  Design specs – e.g. WSDL Compiled Model vs. Stubs  Sample RR pairs, byte code, logs, etc. Automatic Healing 11 Copyright © 2012 CA. All rights reserved.
    12. 12. where do we start?3 common applications Integration Mergers and Acquisitions “Business-in-a-Box” Application Modernization Deadline Critical Value Release SDLC Optimization Opportunities Parallel Development Performance Engineering Hardware Reduction Confidence in Application Scalability12 Copyright © 2012 CA. All rights reserved.
    13. 13. constraint: schedule conflicts “shift-left” the SDLCWithout LISA Uncertain delivery schedule – defects persist until UAT Dev Dev Dev Dev Dev Dev Dev Dev 1 2 1 2 1 3 2 3 System Test Integration With CA LI SA more effort Typical composite app today waits moved sooner in the lifecycle for whole assembly to beginWith LISA Dev1 Dev2 Dev3 Reduction in SDLC Faster Rollout System Integration Performance UAT Copyright © 2012 CA. All rights reserved.
    14. 14. sample report card: Shift-Left at Sprint wk5 wk6 wk7 wk8 wk9 wk10 wk11 wk12 wk13 wk14 wk15 wk16 wk17 wk18 wk19 Project Phases Setup Shakeout Integrated System Test UAT Pass 1Dev Unit System Test UAT Pass 2 Mainframe ST 80 Virtual Service back 80 Virtual Service back Automated shakeout Automated shakeout Earlier test phases with Earlier test phases with MF Delivery ends delivered for ST happens 2 weeks happens 2 weeks fewer defects to fix fewer defects to fix ends delivered for ST earlier earlier Targeted Release Cycle • 2-week system test and Integration test savings in first project • 400% more effective defect elimination due to early coverage of environment Copyright © 2012 CA. All rights reserved.
    15. 15. constraint: infrastructure availability Reduced infrastructure requirements BEFORE AFTER ESB ESB MAINFRAME DATA LEGACY EXTERNAL MAINFRAME DATA LEGACY EXTERNAL Dev 1-n Integration 1-n  Contention for access  Constrained mainframe and between on-shore complex coordination cycles and off-shore teams stunted agility ESB MAINFRAME DATA LEGACY EXTERNAL ESB ESB MAINFRAME DATA LEGACY EXTERNAL MAINFRAME DATA LEGACY EXTERNAL Virtual Environments for Dev/Integration/Test/Pre-Prod Test 1-n Pre-Prod 1-n  Eliminates need for enterprise systems Environments not  Mainframe access (mainframe, CRM, ERP, etc.) in many cases realistic and require required for any  One customer avoided $65M+ infrastructure manual data and testing maintenance cost by eliminating lab expansion Copyright © 2012 CA. All rights reserved.
    16. 16. constraint: system availability Performance readiness BEFORE AFTER Shared Mainframe Service Or similar heavy-weight implementation environment Constraints affecting performance team productivity, with inability to isolate flaws  One customer achieved 300% more performance coverage and avoided $30+ High costs to build and maintain stubs with million in new infrastructure investment only limited functionality Copyright © 2012 CA. All rights reserved.
    17. 17. constraint: data volatility Data & scenario managementBefore App data complex and volatile Lengthy lab set-up times Activities often delayed to Many dependent data sets integration and UAT reduced down to only App4 those that directly connect. App1 App5 App7 Input Data App2 App6 System App8 Deal with the data at Under Test Out-of-Scope the application level, Stable, consistent inputs Dependencies not out-of-scope data cover happy paths, edge models. and error conditions elegantly with lower upkeep. Users One Customer’s Outcome: 30-day sprints for this implementation were reduced by 15-25 % Data setup time reduced by 68% by providing smart data Copyright © 2012 CA. All rights reserved.
    18. 18. customer successes Large US Telco – Popular cell phone launch Reduced software release cycle time by 33% 400% increase in defects identified 4 weeks to achieve 100%+ ROI – $1.6M Major US Financial Services Company – 3rd Party Access Avoided $700k investment in additional hardware on 1st project Avoided 95% of non-production 3rd party access fees Eliminated delays related to 3rd party dependencies from SDLC 8 weeks to 100%+ ROI Major US Bank – Performance Engineering 8 days to replace 2 years of custom-coded stubs Avoided $30M Y1 in lab upgrades, >$90M to date Increased quality from 3.7 to 5.1 Sigma in single release. Reduced outsourced testing headcount from 45 to 7. Increased team scalability from supporting 5 apps to 140.
    19. 19. Nirvana: Agile, continuous delivery has to be applicationlifecycle oriented App1-Dev App1-Dev App1-ST App1-ST SIT SIT App2-Dev App2-Dev App2-ST App2-ST PROD PROD PERF PERF App3-Dev App3-Dev App3-ST App3-ST  Follows the customer’s development cycle (Dev, SysTest, Integration, Prod)  Supports Environment contents that are different by stage and by Team  Allows for Environment Refresh and Environment Promotion  Allows for coordination/synchronization of promotions  Provides full auditability, rollback, reproduction, and redeployment  Deploys to any/all possible targets: existing, Cloud Provisioning, Run Book
    20. 20. Service Virtualization: Reality is Overrated  Get your copy at the CA Tap & Brew (Booth 101 Moscone South – while supplies last)  Signing 11:30 AM – 1:00 PM today!  Updates and more at the SV community, see http://ServiceVirtualization.Com/book Copyright © 2012 CA. All rights reserved.
    21. 21. NoticesCopyright © 2012 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced hereinbelong to their respective companies. No unauthorized use, copying or distribution permitted.Certain information in this publication may outline CA’s general product direction. However, CA may makemodifications to any CA product, software program, method or procedure described in this publication at any timewithout notice, and the development, release and timing of any features or functionality described in this publicationremain at CA’s sole discretion. CA will support only the referenced products in accordance with (i) the documentationand specifications provided with the referenced product, and (ii) CA’s then-current maintenance and support policyfor the referenced product. Notwithstanding anything in this publication to the contrary, this publication shall not: (i)constitute product documentation or specifications under any existing or future written license agreement or servicesagreement relating to any CA software product, or be subject to any warranty set forth in any such writtenagreement; (ii) serve to affect the rights and/or obligations of CA or its licensees under any existing or future writtenlicense agreement or services agreement relating to any CA software product; or (iii) serve to amend any productdocumentation or specifications for any CA software product.This document is for your informational purposes only and CA assumes no responsibility for the accuracy orcompleteness of the information contained herein. To the extent permitted by applicable law, CA provides thisdocument “as is” without warranty of any kind, including, without limitation, any implied warranties ofmerchantability, fitness for a particular purpose, or noninfringement. In no event will CA be liable for any loss ordamage, direct or indirect, from the use of this document, including, without limitation, lost profits, businessinterruption, goodwill or lost data, even if CA is expressly advised in advance of the possibility of such damages.Any examples provided in this presentation are for illustrative purposes only and are not necessarily reflective of theresults you can be expected to achieve.
    22. 22. Thank you

    ×