Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Strangling the Monolith With a Data-Driven Approach: A Case Study

476 views

Published on

SpringOne Platform 2017
David Julia, Pivotal; Simon P Duffy, Pivotal

"The scene: A complex procedure cost estimation system with hundreds of unknown business rules hidden in a monolithic application. A rewrite is started. If our system gives an incorrect result, the company is financially on the hook. A QA team demanding month-long feature freezes for testing. A looming deadline to cut over to the new system with severe financial penalties for missing the date. Tension is high. The business is nervous, and the team isn’t confident that it can replace the system without introducing costly bugs. Does that powder-keg of a project sound familiar?

Enter Project X: At a pivotal moment in the project, the team changed their approach. They’d implement a unique, data-driven variation of the strangler pattern. They’d run their system in production alongside the legacy system, while collecting data on their system’s accuracy, falling back to the legacy system when answers differed. True to Lean Software development, they would amplify learning and use data to drive their product decisions.

The end result: An outstanding success. Happy stakeholders, business buy-in to release at will, a vastly reduced QA budget, reusable microservices, and one heck of a Concourse continuous delivery pipeline. We achieved all of this, while providing a system that was provably better than the legacy subsystem we replaced.

This talk will appeal to engineers, managers, and product managers.

Join us for a 30 minute session where we review this case study and learn how you too can:

Build statistically significant confidence in your system with data-driven testing
Strangle the Monolith safely
Take a Lean approach to legacy rewrites
Validate your system’s accuracy when you don’t know the legacy business rules
Leverage Continuous Delivery in a Legacy Environment
Get Business and QA buy-in for Continuous Delivery
Articulate the business value of data-driven product decisions"

Published in: Technology
  • Be the first to comment

Strangling the Monolith With a Data-Driven Approach: A Case Study

  1. 1. A Data Driven Approach Dec 6, 2017 Simon Duffy, Staff Product Manager | Pivotal Labs David Julia, Director | Pivotal Labs
  2. 2. Additional business features Cost Estimator for medical procedures Financial Penalties for inaccurate estimations
  3. 3. 3rd Party Web UI Monolith Source System 1 Source System 2 Source System 3 … Source System N
  4. 4. Main Member-Facing Web UI Account Customization Member Store Secure Messages ...etc. Member Liability Estimator SOAP Service Component Source System 1 Source System 2 Source System 3 … Source System N
  5. 5. Main Member-Facing Web UI Account Customization Member Store Secure Messages ...etc. Member Liability Estimator SOAP Service Component Source System 1 Source System 2 Source System 3 … Source System N
  6. 6. The expert leads the way
  7. 7. Complex flows create anxiety
  8. 8. External QA test team with competing priorities Generating mocks and test cases is time consuming Testing is not Production. Period.
  9. 9. ♥ Strangler Fig Hollow Inside of Strangler Fig
  10. 10. + = ☺
  11. 11. 3rd Party Web UI Monolith Source System 1 Source System 2 Source System 3 Project X 3rd Party Web UI 1 week
  12. 12. 3rd Party Web UI Monolith Source System 1 Source System 2 Source System 3 Project X 3rd Party Web UI Monolith Source System 1 Source System 2 Source System 3 Project X Calculation Module 2 weeks
  13. 13. Web App UI Monolith Source System 1 Source System 2 Source System 3 Project X Calculation Module 3 weeks
  14. 14. ✖ ✖
  15. 15. Web App UI Monolith Source System 1 Source System 2 Source System 3 Project X Calculation Module 4 weeks
  16. 16. Web App UI Monolith Project X Calculation Module Source System 1 Source System 2 Source System 3 5 weeks
  17. 17. Project X 3rd Party Web UI Source System 1 Source System 2 Source System 3 Project X Calculation Module 13 weeks
  18. 18. V100 Project X Calculation Module Production Baseline Extractor Extract v100 15 weeks
  19. 19. Build & Test Deploy to Staging Baseline Variance Test Deploy to Prod Take New Baseline
  20. 20. Build & Test Deploy to Staging Baseline Variance Test Deploy to Prod Take New Baseline V101 Project X Calculation Module v100 Baseline Variance Test Staging
  21. 21. Build integrity in -> Continuous delivery You can’t always analyze a problem before acting.... Accept it and lean in! Value based business metrics > team activity metrics Automated testing can include “What’s the business impact?” Pragmatism > perfection, especially in rewrites/app modernization
  22. 22. Consumer Legacy System Proxy New System
  23. 23. Consumer request Execute legacy app Execute new app Route old or new
  24. 24. You want to decompose a system, and you know the logic inside it. OR You can redefine the business rules in the new system that you are writing. This is probably lower cost!
  25. 25. Consumer request Execute new app Log request Orchestrate calls to old and new Log responses Execute legacy app Analyse results
  26. 26. You want to decompose a system, and don’t know the logic inside it. AND The output of your new system ought to match the monolith.

×