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.

Monoliths vs Microservices is the Wrong Question; Start with Team Cognitive Load @ London Microservices meetup, Nov 2020

277 views

Published on

The “monoliths vs microservices” debate often focuses on technological aspects, ignoring strategy and team dynamics. Instead of technology, smart-thinking organizations are beginning with team cognitive load as the guiding principle for modern software. In this talk I explain how and why.

Key takeaways:
- What is team cognitive load and why that matters
- Using team cognitive load as the guiding principle for sustainable ownership and evolution of software systems
- What are the fundamental topologies and interaction modes that help reduce cognitive load

Published in: Technology
  • Be the first to comment

Monoliths vs Microservices is the Wrong Question; Start with Team Cognitive Load @ London Microservices meetup, Nov 2020

  1. 1. TeamTopologies.com @TeamTopologies Forget ‘Monoliths vs Microservices’; start with Team Cognitive Load Manuel Pais co-author of Team Topologies @manupaisable London Microservices Meetup - 18 Nov 2020
  2. 2. 2 Manuel Pais Independent IT organizational consultant and trainer Ex-dev, ex-build manager, ex-tester, ex-QA lead LinkedIn instructor on Accelerating Continuous Delivery Twitter: @manupaisable LinkedIn: manuelpais
  3. 3. Team Topologies 3 Organizing business and technology teams for fast flow Matthew Skelton & Manuel Pais IT Revolution Press Order via stores worldwide: teamtopologies.com/book
  4. 4. 4 Team Cognitive Load Team-First Approach Case Studies Getting started
  5. 5. Team Cognitive Load 5
  6. 6. 6
  7. 7. “Start with monolith and extract microservices.” - Tammer Saleh 7 https://www.infoq.com/presentations/cloud-anti-patterns
  8. 8. “Don’t start with a monolith when your goal is a microservices architecture” - Stefan Tilkov 8 http://martinfowler.com/articles/dont-start-monolith.html
  9. 9. “If you can't build a monolith, what makes you think microservices are the answer?” - Simon Brown 9 http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html
  10. 10. 10 WTF?!?! * where to focus?
  11. 11. “Software that fits in your head” - Daniel Terhorst-North 11 https://speakerdeck.com/tastapod/microservices-software-that-fits-in-your-head?slide=62
  12. 12. 12 “Software that fits in our heads”
  13. 13. 4 key metrics: ‘Accelerate’ 13 lead time deployment frequency mean time to restore (MTTR) change fail percentage
  14. 14. Software that is ‘too big for our heads’ works against organizational agility 14
  15. 15. COGNITIVE LOAD: The total amount of mental effort being used in the working memory - John Sweller 15
  16. 16. Intrinsic Extraneous Germane 16 “How are classes defined in Java?”
  17. 17. Intrinsic Extraneous Germane 17 “How do I deploy this app, again?”
  18. 18. Intrinsic Extraneous Germane 18 “How do bank transfers work?”
  19. 19. Intrinsic (skills) Extraneous (mechanisms) Germane (domain focus) 19
  20. 20. (Intrinsic) ] Extraneous [ Germane 20
  21. 21. More: ‘Hacking Your Head’ 21 Jo Pearce (@jdpearce) https://www.slideshare.net/JoPearce5/hacking-your-head-managing-information-overload-extended
  22. 22. Limit the size of software services/products to the cognitive load that the team can handle. 22
  23. 23. 23 “Software that fits in our heads”
  24. 24. 24 Team cognitive load as a key consideration for org decisions
  25. 25. Team-First Approach 35
  26. 26. A ‘team-first’ approach to delivery of digital products 36
  27. 27. Team size ≲ 9 * * possibly 15 37
  28. 28. Well-chosen streams & domain boundaries 39
  29. 29. 40
  30. 30. 41
  31. 31. 42 Feature
  32. 32. 43 Types of streams ● a service ● a set of features ● a user persona or user journey ● a compliance standard ● a specific market or geography ● ...
  33. 33. 44 Domain-Driven Design
  34. 34. 45 DDD-Lite™* Independent Service Heuristics * only joking
  35. 35. Independent Service Heuristics 46 https://github.com/TeamTopologies/Independent-Service-Heuristics
  36. 36. Developer Experience #DevEx 47
  37. 37. Operator Experience #operability 48
  38. 38. Modern Platform as a Product 49
  39. 39. 4 fundamental topologies 50 Stream-aligned team Enabling team Complicated Subsystem team Platform team
  40. 40. 4 fundamental topologies 51 Flow of change
  41. 41. 3 core interaction modes 52 Flow of change X-as-a-Service Facilitating Collaboration
  42. 42. 53 Rapid flow of change
  43. 43. 54 Rapid feedback from running systems
  44. 44. 58 Each service must be fully owned by a team with sufficient cognitive capacity to build and operate it.
  45. 45. 59 Team ownership must include: Releasability Testability Operability / Supportability
  46. 46. 60
  47. 47. 61
  48. 48. Case Study 65
  49. 49. “...trend analysis, simulations, rapid prototyping, scenario planning, gaming, environmental scanning … give clues to the context and competitive environment.” - Dr. Naomi Stanford, “Guide to Organisation Design” (The Economist) 66
  50. 50. CaseStudy 67
  51. 51. CaseStudy 68 2016 (early)
  52. 52. CaseStudy 69 2016 (late) CMS
  53. 53. CaseStudy Framework 70 2017 (early) CMS Products
  54. 54. CaseStudy Framework 71 Products 2017 (late) CMS
  55. 55. CaseStudy Framework 72 Products 2017 (early) CMS
  56. 56. Team became too large ⇔ System became too large for team Blocked flow of work across streams 73
  57. 57. Listen to ‘triggers for evolution’ ❏ Software grows too large ❏ Over specialization (Brent) ❏ Increased coordination needs 74
  58. 58. Getting started 81
  59. 59. Getting started 82 Explicit cognitive load
  60. 60. How well can the team as a unit “grok” the systems they own and develop? Explicit cognitive load 83
  61. 61. 84
  62. 62. Push some things into a Platform? Explicit cognitive load 85
  63. 63. Are skills or capabilities missing? Explicit cognitive load 86
  64. 64. Getting started 87 Explicit cognitive load Misaligned work streams Team Interactions Thinnest Viable Platform
  65. 65. Does it frequently take three or more teams to change a single user journey? Misaligned work streams 88
  66. 66. Are development teams assumed to know and comply with regulations? Misaligned work streams 89
  67. 67. Getting started 91 Team interactions
  68. 68. Do we know which teams we need to interact with? What outcomes do we expect from the interaction? Collaboration, X-as-a-Service, Facilitating Team Interactions 92
  69. 69. Getting started 93 Explicit cognitive load Misaligned work streams Team interactions
  70. 70. Team Topologies 94 Organizing business and technology teams for fast flow Matthew Skelton & Manuel Pais IT Revolution Press Order via stores worldwide: teamtopologies.com/book
  71. 71. Workbook coming soon... Team Topologies for Remote Teams 95 for Remote Teams Sign up for news: teamtopologies.com/newsletter Icon by Pixel perfect from www.flaticon.com
  72. 72. Remote- Friendly Training 🠊 teamtopologies.com/training 96
  73. 73. Resources 98 teamtopologies.com/resources (links, slides, video) github.com/teamtopologies (templates, assessments, etc)
  74. 74. TeamTopologies.com @TeamTopologies Sign up for news and tips: TeamTopologies.com
  75. 75. Thank you! 101 Matthew Skelton, Conflux @matthewpskelton Manuel Pais, Independent @manupaisable teamtopologies.com

×