Recommended
More Related Content
What's hot
What's hot (20)
Similar to GECon2017_ Lean_architecturemanagement_Andrei Kavaleu
Similar to GECon2017_ Lean_architecturemanagement_Andrei Kavaleu (20)
More from GECon_Org Team
More from GECon_Org Team (10)
Recently uploaded
Recently uploaded (20)
GECon2017_ Lean_architecturemanagement_Andrei Kavaleu
- 1. Lean Architecture Management by Andrei Kavaleu
- 2. 2 ABOUT ME • 14+ years of experience in IT architecture, technical leadership, software development • Main Focus on .NET, cross-language architecture, Architecture Design and Review, Architecture Audit and Governance • SEI certified Architect • Microsoft Competency Center expert, Architecture community leader • Hands-on experience examples: – As Solution Architect: Ticketing platform for Premier League clubs (eCommerce, CRM, CMS, inventory management, AWS migration, millions of users on peeks) – As Architect and Team Lead: Production automation and railway transportation (Integration with ERP, hardware integration, production pipeline management, shop-floor data collection, multi-site environment – 16 factories across EU, thousands of workstations)
- 3. 3 • Is it hard to make right architecture? • Case for today: from Darkness to Light • Agile transition: Complex things via simple steps • Lean applied: Changing architecture • Vision is not enough: Channing processes AGENDA
- 4. 4 Is it hard to make right architecture?
- 5. 5 • What is Architecture? • Is here someone who creates Architecture as part of his job? • Who implements things according to Architecture? • Who has no Architecture on his project? • Who doesn’t need it? WHAT IS ARCHITECTURE
- 6. 6 Architecture is a set of rules and already made decisions on how a system is to be built Good architecture is good decisions and good approach WHAT IS ARCHITECTURE
- 7. 7 WHOSE PROBLEM IS THIS?
- 11. 12 EXAMPLE: WEB APPLICATION HOSTING https://epa.ms/aws-ref-arch
- 12. 13 EXAMPLE: WORD PRESS HOSTING https://epa.ms/aws-ref-arch
- 13. 14 EXPAMPLE: NETFLIX OSS STACK https://netflix.github.io/
- 14. 16 • MapReduce and more fault tolerance than you need might sound fine, but consider the cost: you might be switching from a mature system—with stuff like transactions, indexes, and query optimizers • Dynamo and Cassandra are distributed databases prioritize write availability. Amazon wanted the “add to cart” action to never fail. This was done by compromising consistency, as well as basically every feature present in a traditional RDBMS • Kafka was designed to handle the throughput of all the analytics events at LinkedIn: to around 1 trillion events per day, with peaks of over 10 million messages per second. • … YOU ARE NOT GOOGLE https://epa.ms/gc-not-google
- 16. 18 Case for today: from Darkness to Light
- 17. 19 Problem • 20+ years old, 1.5M LoC big legacy system • Hard to add new features and extend existing code. Reached capacity of VB6 • Painful releases: hard to ensure appropriate quality • 100+ clients afraid of new changes Business Drivers/Goals • Get control on updates of clients apps • Decrease operational, infrastructure, license cost • Add new clients easier • Continuous Improvement SYSTEM AS IT WAS
- 18. 20 Problem • 20+ years old, 1.5M LoC big legacy system • Demand driven development • 400+ forms, 600+ DB tables • 100+ clients afraid of new changes Business Drivers/Goals • Get control on updates of clients apps • Decrease operational, infrastructure, license cost • Add new clients easier • Continuous Improvement SYSTEM AS IT WAS
- 19. 21 IS THIS OUR END STATE?
- 20. 22 Good architecture is good decisions and good approach RIGHT ENOUGH DECISIONS UPFRONT • Make good decisions in face of uncertainty and lack of time • Don’t constraint developers • Imagine ideal future
- 21. 23 IDEAL FUTURE Long-Term Goals: • Speed and Confidence Improve product development. Reduce time to market. Allow Experiments • Flexibility & Stability Reconfigure services. Make new products. Enable innovation
- 22. 24 HOW TO REACH THIS FUTURE? Long-Term Goals: • Speed and Confidence Improve product development. Reduce time to market. Allow Experiments • Flexibility & Stability Reconfigure services. Make new products. Enable innovation
- 23. 25 Agile transition: Complex things via simple steps
- 24. 26 AGILE AND ARCHITECTURE? AGILE Iterative and incremental Frequent delivery of releases Small and lightweights requirements Teams are decisions makers Decisions could be changed frequently Short planning (sprint/product backlog) Value is visible on every release ARCHITECTURE (MYTHS) Big up-front design Longer releases Massive documentation Architects are decisions makers Decisions are hard to change Long-term design Low visible value
- 25. 27 MEET LEAN
- 27. 30 TRANSITION VIA SMALL STEPS • Small agile steps toward reference architecture • Measure each step and react • Adjust next steps forward
- 28. 31 SMALL STEPS EXAMPLE: PRINTING • External component • Owns printers • Rendering via external engine • Available for other systems via REST Steps: • In-Process component • In-Process REST API (Loop-Back) • Out-Of-Process REST API APP TCT (Rendering Engine) Physical Printers VM Printing Service Printers ownership Batch Printing ... Other Systems Other Systems Other Systems
- 29. 32 SMALL STEPS EXAMPLE: PAYMENT • External component • Multiple Payment Providers • Available for other systems via REST Steps: • In-Process component • In-Process REST API (Loop-Back) • Out-Of-Process REST API OUR APP IPS (For now Credit Cards and Bank transfer) 3rd party Integrations Payment Service 12+ Methods of payment Other Systems Other Systems Other Systems
- 30. 33 SMALL STEPS EXAMPLE: ACCESS CONTROL • External component • Unifies AC-systems access • Available for other systems via REST? Similar Steps again and again: • In-Process component • Unify AC integration via DB • In-Process REST API (Loop-Back) • Out-Of-Process REST API OUR APP Access Control Service DB Inegration Fortress Other Systems Other Systems Other Systems Access Manager Ski Data ?
- 31. 35 NEW CAPABILITIES AS STEPS • Promotions • Supporters Clubs • Soccer Schools • Ticket Resale • Merchandise sales (e-commerce) • 3rd party sales via API • … • Amazon Alexa integration? Reference architecture Application 1 Web Application 2 Desktop Application N Web TM Capability #1 (Printing) Service Component 1 Service Component 2 TM Capability #3 (Payments) TM Capability #2 (Mailing)
- 32. 36 Vision is not enough: change your processes
- 33. 37 • Build and Visualize your value stream Do you have CI/CD pipeline? • Ensure the steps occur in sequence Do you skip steps? • Change process from push to pull Do you use Feature Flags? • Measure you process Do you collect process metrics? PROCESS CHANGES (TOWARD LEAN)
- 34. 38 VALUE STREAM IS DEVELOPMENT PIPELINE Development Specification Development Code Review Testing CI Build Unit/Integration Tests Code Analysis QA Auto Tests Manual Tests Staging Integration Tests Load Tests Capacity Stress Tests UAT Production Blue/Green Deployment Feature Release Monitoring
- 35. 42 Feature Flags • Disable Feature if it’s not ready or doesn’t work • No Roll-Backs • Let user decide what to Turn On • Your binaries contain Future features • UAT in Prod? Possible • Next step is A/B testing https://martinfowler.com/articles/feature-toggles.html
- 36. 44 OUR STATE AS FOR TODAY • 100% Code coverage • AQA coverage for Release -1 • Monthly releases for 30+ team (no excuses) • Devs are making architectural decisions • Team got incremental mindset Room for improvements • Weekly releases. Bottleneck – 2 weeks for regression
- 37. 45 THANK YOU • PM: Dmitry D. • Team Leads: Viachaslau L., Alexey A., Vital S. and their Dev Teams • BA: Siarhei K. and his BA Team • QA: Natalia P. and her QA Team • AQA: Maksim S. and his AQA Team • DevOps: Timur S. and his DevOps Team • Tech Leads: Alex Ch., Yauhen K., Kanstantsin H. • and our Customer who allows all this
- 38. 46 SUMMARY
- 39. 47 AGILE AND ARCHITECTURE! AGILE Iterative and incremental Frequent delivery of releases Small and lightweights requirements Teams are decisions makers Decisions could be changed frequently Short planning (sprint/product backlog) Value is visible on every release ARCHITECTURE (REALITY) Reasonable up-front design Incremental design updates Simplified documentation Shared decisions Evolutionary architecture Incremental design Value is visible few releases