CodeValue Architecture Next 2018 - Executive track dilemmas and solutions in modern software development
0 likes142 views
The document discusses dilemmas and solutions in modern software development, focusing on microservices versus monolithic architectures, their benefits, and drawbacks. It emphasizes the importance of proper architecture and engineering practices to manage complexity, improve cohesion and coupling, and enhance organizational maturity. Additionally, it highlights UX tools for product discovery and strategies for agile planning in response to rapidly changing realities.
CodeValue Architecture Next 2018 - Executive track dilemmas and solutions in modern software development
- 2. Dilemmas and Solutions in Modern Software Development Alon Fliess Chief Software Architect Azure MVP, MRD [email protected] http://alonfliess.me 2
- 3. Agenda To Microservice or Not to Microservice? UX Tools for Product Discovery Planning the Unexpected: Dealing with a Rapidly Changing Reality 4
- 4. 5 Eran Stiller, Chief Technology Officer (CodeValue) To Microservice or Not to Microservice?
- 5. Decomposition Is this a good design?
- 6. Decomposition Is this a good design?
- 7. Decomposition Is this a good design?
- 8. Decomposition Is this a good design?
- 9. The Cost of the Software Development Process number of modules Module Integration cost (complexity) module development Cost (complexity)Cost
- 10. Microservices Platforms Benefits Modern microservices platforms significantly reduce the cost of module integration Shifting the cost equilibrium towards more modules Especially true when using proven PaaS platforms Both public and private cloud based The integration cost decreases with two factors: Mature PaaS platform Proven DevOps process 11
- 11. Monoliths Why are monoliths considered a bad thing? They’re not They all started with good intentions They usually become convoluted over time Features are added People change Deadlines happen Technical debt accumulated It’s very easy to fall 12
- 12. Microservices Are Microservices the solution? They also start with good intentions Will become convoluted with time as well Without proper architecture and guidance 13
- 13. Monoliths Natural starting point Easier to get started and deliver value Simpler build and deployment Simpler scalability Simpler security Low latency Intra-process communication Simpler testing Simpler logging and monitoring Simpler data and database management Simpler transaction management Large code base Simple change requires whole app to be redeployed Increased complexity as functionality is coupled together Single type of database doesn’t meet all requirements Tend to get difficult to work with over time Huge resource requirements Reduced agility over time Coarse-grain transactions 14 Source: https://bit.ly/2vf6eov
- 14. Microservices Smaller manageable functional units Multiple smaller code bases Single service provides single functionality Single responsibility per service Clearer separation of concerns Independently scalable services Polyglot persistence as applicable Polyglot programming language as applicable Independently deployable Easier on-boarding process Frequent functionality releases Decentralized ownership Team that develops it, manages it Distributed System Architecture Design, Development, Deployment, CAP theorem Handle Increased orchestration Troubleshooting challenges Call Traceability Log aggregation Data consistency issues Eventual consistency Compensatory & reconciliatory procedures Increased latency due to remote calls Distributed Configuration Management Organizational Maturity Company Culture Engineering practices IT Operations Software defined networks On-demand infrastructure provisioning Architectural complexity 15 Source: https://bit.ly/2vf6eov
- 15. Microservices Drawbacks Solution Plan ahead DevOps Use supporting platforms Cloud Containers Architect Low Coupling, High Cohesion Schema/API Versioning 16
- 16. Cohesion The degree to which a module performs one and only one function Strive for high cohesion A module can be: Library (assembly, shared module, DLL) File Class Method COM/CORBA component (Micro) Service Any reusable element
- 17. Coupling The degree to which each program module relies on each of the other modules Low coupling often correlates with high cohesion, and vice versa Low coupling is A sign of a well-structured computer system Good design When combined with high cohesion Supports high readability, maintainability, extendibility, and reusability Micro Service Architecture == High Cohesion & Low Coupling
- 18. Why Should I Care About Coupling Tightly coupled systems tend to exhibit the following developmental characteristics A change in one module usually forces a ripple (cascading) effect of changes in other modules Assembly of modules might require more effort and/or time due to the increased inter-module dependency A particular module might be harder to reuse and/or test because dependent modules must be included The DevOps process becomes a nightmare!!! 19
- 19. How to Decouple Microservices Have a managed hosting environment Cloud, Kubernetes, Service Fabric Use messages (not types) Use Queues Or use Service Locators + Load Balancers 20
- 20. So Should I Do Microservices? YES, but only if you have: Capable architects Rapid compute provisioning Mature CI/CD pipelines Advanced DevOps culture OR – get some experts to help 21 Source: https://bit.ly/2oro8Pi
- 21. 22 Erez Pedro, Head of UX (CodeValue) UX Tools for Product Discovery
- 22. Agenda What challenges can UX tools help with? What is product discovery? Goals When should it be done? Variations in discovery tools by product context Ways to do blitz type product discovery (GV’s Design Sprint, Design thinking) What we do in our Discovery Workshop? 23
- 23. Hitting the target is as easy as: Ready, Aim, Shoot! 24
- 24. Ready, Aim, Shoot! Easy, right? Sometimes you don’t hit the mark You have a limited number of arrows Moving targets 25
- 25. Design Sprint Understand Define Diverge Decide Prototype Validate Google Design Sprint
- 26. • Group conclusion • Joint ownership • Quick reviews with clarifications Product Manager (inbound) Business (outbound) UX Architect Technical Architect
- 27. Ready – Product Vision 28
- 28. Ready - need to identify a target In the beginning it is all a blur Need to decompose the problem 29
- 29. Ready, for what? Business goals Functional goals Usability goals 30
- 30. Variation in Market Focus 31 Fun consumer product Professional tool High Medium Low Efficiency Effectiveness Error Tolerant Easy to learn Engaging
- 31. Stand out in the crowd 32
- 33. User analysis tools Origin: Anthropology Tribal behavior It is relevant? Duhh!
- 34. Its often about desire not always needs 35 Watch & Listen to your users
- 35. Understanding our user’s state of mind 36“Adapting empathy maps for UX design.” Paul Boag
- 36. Aim - product vision product requirements Concentrate on customer pain points What will create the most value - USP? What should the product experience feel like? 37
- 37. Focusing on biggest pain points OnBoarding Search Criteria Review Results Comparison & Decision Exit funnel
- 38. Discovery is a mental state, not just a project phase. “
- 39. Customer Friend that knows The listing system Barbershop coordinator Need to find a barber Time for a cut Search for a barbershop Select a barbershop What do they offer? List of services in selected barbershop Select service(s) Find available slots List of services <Initial> List of services <available> List of services <Requested> Select slot and pay List of open slots <available> Set a reminder Find relevant shops Book the slot for selected service(s) Book in calendar Workflow analysis
- 41. Shoot! Release now? Do something before? 42
- 42. The solution Guided arrow/ missile 43 https://youtu.be/PWiU_HIZ4Jc
- 43. Testing with LoFi prototypes
- 44. 45 Ronen Rubinfeld, Dev. Management & Methodology Lead (CodeValue) Planning the unexpected… Dealing with today's rapidly changing reality using Agile
- 47. So, how do we do it then?... Complexity Uncertainty Risk Change Value Agility
- 49. The “Agile Challenge” Bottom Up Top Down Work incrementally in small steps while Seeing the big picture
- 50. The Process
- 51. Backlog Feature Feature FeatureFeatureFeature FeatureFeature Feature Feature Feature Feature Feature Feature Overall Product Process Outline
- 52. Backlog: Views Single Requirements Repository - Different Views Product Backlog • Holds all Requirements of the Product • Regardless the expected release planning • Managed on Epic / Feature level Release Backlog • Defines the scope of a given Release • Baseline is defined at the beginning of the Release • Requirements detailing evolves throughout the Release’s lifetime • Additions / modifications to the Release backlog are managed in a formal process Sprint Backlog • Defines the scope of a given Sprint on a US level • Finalized and signed-off close to the Sprint’s begging • Committed upon the beginning of the Sprint Release 1 Release 2 Release 3 Product Backlog Sprint 1 Sprint 2 Sprint 3
- 53. Product Backlog: Hierarchical Structure Epic • Top-level breakdown of the Product • Describe the “Investment Buckets” / Main goals of the Product • Can be considered as a “Convenience” level Feature • The “what” – what is implemented • Smallest functional increment that provides value to the end-user • Implementation should be completed within a Release • Can be implemented by several teams Product Backlog Item / User Story • The “how” – Breakdown of the Features to implementation details • Smallest functional increment that provides value to the System • Implementation should be completed within a single Sprint • Should be implemented by a single Team • Reflects the architecture and potentially the org structure Epic Feature User Story Epic Feature User Story
- 55. Agile Heartbeat Release 1 Release 2 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 3 Months 3 Months 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks Project Product BL
- 56. Release Heartbeat Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks Release 1 Plan Implementation Stable Product Backlog Release 1 Sprint1 Sprint2 Sprint3 Sprint4 Sprint5 Sprint6
- 57. Release Heartbeat Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks Release 1 Plan Implementation Stable Product Backlog Release 1 Sprint1 Sprint2 Sprint3 Sprint4 Sprint5 Sprint6 User Story User Story User Story User Story User Story User Story User Story User Story User Story Feature Feature Feature User Story User Story User Story User Story User Story User Story User Story User Story User Story User Story User Story
- 58. Agile Heartbeat Release 1 Plan Implementation Stable Release 2 Plan Implementation Stable
- 59. 60 Takeaways
- 60. 62
Editor's Notes
- #6: Alon to introduce
- #13: https://pixabay.com/en/maldives-palma-beach-sand-3220702/ https://pixabay.com/en/hurricane-irma-home-destruction-2857982/
- #14: https://pixabay.com/en/balls-of-wool-colors-storage-locker-2689442/ https://pixabay.com/en/flecked-heathered-wool-wool-knit-1228706/
- #17: Free image source: https://pixabay.com/en/approval-female-gesture-hand-happy-15914/
- #23: Alon to introduce
- #32: Objective performance Subjective image/impression Other General relationship Attractiveness of system Ease of use Utility Degree of usage Other Compositional Sensual Emotional
- #36: Products vary substantially, the analysis tools should adapt
- #41: ניתוח תהליכי
- #42: Quick
- #43: So what should the discovery team do now? Maybe just shoot a quick one And test … (prototype)
- #46: Alon to introduce
- #47: קצת על הסביבה בה אנו פעלים היום: Rapidly changing environment High Complexity Uncertainty Risk Value Short time to market / Fast Technological complexity
- #48: אז מה כל זה בעצם אומר? אנחנו חיים היום במציאות המחייבת אותנו להתמודד עם שינוי... אם בעבר אולי עוד חשבנו שניתן להמנע משינויים, היום אנחנו מבינים שלא רק שאנחנו לא יכולים להמנע מהם אלא שאנחנו רוצים לחשף אותם ולקבל את הפידבק כדי להבטיח מוצר טוב ואיכותי יותר אז מה הבעיה? עלות השינוי – ככל שהעלות שנדרשת כדי להתמודד עם השינוי גבוהה יותר, אנחנו ננסה להמנע משינויים ובטח שלא נחפש את הפידבק...
- #49: אז בעצם, הדרך להתמודד עם כל המורכבויות שדברנו עליהן - סביבה טכנולוגית מורכבת - אי וודאות - שינוי - Risk Time to market ... היא ע"י אג'ייל אז מה זה אג'ייל? עבודה איטרטיבית ואינקרימנטלית – לספק Incriminates קטנים של value בצורה איטרטיבית כלומר באופן דחוף על מנת שנוכל לבחון את עצמנו, לקבל פידבק על מה שעשינו ולבצע את ההתאמות הנדרשות במילים אחרות – התקדמות בצעדים קטנים כשבכל צעד "מחשבים כיוון מחדש" ומחליטים איך להתקדם קדימה
- #50: אבל.... מוצרים היום הם: מורכבים מסובכים מפותחים ע"י מס' צוותים במקביל בקיצור – מצד אחד צריך לראות את התמונה הגדולה ולהבין מה נדרש ומה רוצים לעשות, כדי לא לפספס את המטרה הסופית ומצד שני ללכת את הדרך בצעדים קטנים
- #51: וזה בעצם האתגר העיקרי שבו אנחנו נתקלים בשימוש באג'ייל – איך מאזנים בין התמונה הגדולה לבין ההתקדמות בצעדים קטנים, Zoom-in vs. Zoom-out האתגר המרכזי באג'ייל – איך אני יכול לבצע את העבודה בצעדים קטנים כשאני לא יודע מה רוצים להשיג ולאן רוצים להגיע. האתגר הוא בעצם להיות מסוגלים לראות ולהגדיר את התמונה המלאה אבל ברמה של JUAST ENOUGH כדי לאפשר ולהגיע אליה בצעדים קטנים כאשר תוך כדי כל הזמן מעדכנים ומתאימים למציאות המשתנה ולדברים החדשים שצצים לאורך הדרך נסיון לקבע מצב מסוים ולהתייחס אליו כאל היעד הסופי הוא לא ריאלי המטרה שלנו לעשות רק מה שנחוץ כדי להבין ולאפשר להגדיר את הצעד הבא צלילה לפרטים תעשה עבור כל מקרה לגופו ממש לפני המימוש
- #54: Emphasize that Sprint backlog is a bi-directional commitment
- #56: תחשבו על הערך שהמשתמש של המערכת יקבל לא את העבודה שצריכה להיעשות