Forget Monoliths vs Microservices: Focus on Team Cognitive Load @ SeaCon UK 2019
2 likes344 views
The document discusses the importance of managing team cognitive load in software development, advocating for a focus on team capacity rather than just choosing between monoliths and microservices. It presents a 'team-first' approach to software design with recommendations for team sizes and domain boundaries to optimize performance. Key concepts include understanding cognitive load, creating autonomous teams, and implementing effective team interaction patterns.
![(Intrinsic)
] Extraneous [
Germane
21](https://image.slidesharecdn.com/monolithsvsmicroservicesismissingthepoint-startwithteamcognitiveload-teamtopologies-seacon-2019-11-1-191113113021/85/Forget-Monoliths-vs-Microservices-Focus-on-Team-Cognitive-Load-SeaCon-UK-2019-21-320.jpg)
Forget Monoliths vs Microservices: Focus on Team Cognitive Load @ SeaCon UK 2019
- 1. TeamTopologies.com @TeamTopologies Forget ‘Monoliths vs Microservices’: focus on Team Cognitive Load Matthew Skelton & Manuel Pais co-authors of Team Topologies @matthewpskelton @manupaisable SEACON 2019, London - 12 Nov 2019 #seacon2019
- 2. 2 Monoliths vs Microservices Team Cognitive Load Case Studies Getting started
- 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 Book signing ✍ TODAY @ 16:00 ! Thanks to
- 6. 6
- 7. “Start with monolith and extract microservices.” - Tammer Saleh 7 https://www.infoq.com/presentations/cloud-anti-patterns
- 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. “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 WTF?!?! * where to focus?
- 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 “Software that fits in our heads”
- 13. 4 key metrics: ‘Accelerate’ 13 lead time deployment frequency mean time to restore (MTTR) change fail percentage
- 14. Software that is ‘too big for our heads’ works against organizational agility 14
- 16. COGNITIVE LOAD: The total amount of mental effort being used in the working memory - John Sweller 16
- 18. Intrinsic Extraneous Germane 18 “How do I deploy this app, again?”
- 20. Intrinsic (skills) Extraneous (mechanism) Germane (domain focus) 20
- 22. More: ‘Hacking Your Head’ 22 Jo Pearce (@jdpearce) https://www.slideshare.net/JoPearce5/hacking-your-head-managing-information-overload-extended
- 23. Limit the size of software services/products to the cognitive load that the team can handle. 23
- 24. 24 “Software that fits in our heads”
- 25. A ‘team-first’ approach to software boundaries 25
- 26. Team size ≲ 9 * * possibly 15 26
- 27. 27 Each service must be fully owned by a team with sufficient cognitive capacity to build and operate it.
- 33. 4 fundamental topologies 33 Stream-aligned team Enabling team Complicated Subsystem team Platform team
- 34. 4 fundamental topologies 34 Flow of change
- 35. 3 core interaction modes 35 Flow of change X-as-a-Service Facilitating Collaboration
- 36. “...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) 36
- 37. Case Studies 37
- 38. CaseStudy 38
- 43. Team became too large ⇔ System became monolithic Blocked flow of work across streams 43
- 44. Listen to ‘triggers for evolution’ ❏ Software grows too large ❏ Over specialization (Brent) ❏ Increased coordination needs 44
- 45. CaseStudy 45
- 48. It’s not always about software size... More broadly, align size and number of domains of responsibility with team cognitive capacity. 48
- 49. Aim for teams with high cohesion internally (think autonomy, mastery & purpose) Aim for low bandwidth comms between smaller teams 49
- 50. Listen to ‘triggers for evolution’ ❏ Awkward interactions ❏ People not invested, burn out ❏ Frequent context switching 50
- 51. Getting started with team cognitive load 51
- 52. How well can the team as a unit “grok” the systems they own and develop? Explicit cognitive load 52
- 53. Push some things into a Platform? Explicit cognitive load 53
- 54. Are skills or capabilities missing? Explicit cognitive load 54
- 55. What would change if we adopted the 3 team interaction patterns? Collaboration, X-as-a-Service, Facilitating Team Interactions 55
- 56. Collaboration, X-as-a-Service, Facilitating How would teams react & behave? Team Interactions 56
- 57. How is your Platform defined? Thinnest Viable Platform 57
- 58. What is the thinnest platform that could work? Thinnest Viable Platform 58
- 59. What’s needed to run and support it? Thinnest Viable Platform 59
- 60. Team Topologies 60 Organizing business and technology teams for fast flow Matthew Skelton & Manuel Pais IT Revolution Press Order via stores worldwide: teamtopologies.com/book
- 61. Training 61 Day 1 Fundamentals Day 2 Deep Dive Day 3 Applying in Context teamtopologies.com/training
- 62. Looking for case studies 62 Global manufacturing company Large government agency Global financial services
- 63. Remaining problems 63 Measuring cognitive load at scale Assessing team communication at scale How to nudge managers and heads of X to become Team Topologies enablers
- 64. TeamTopologies.com @TeamTopologies Sign up for news and tips: TeamTopologies.com
- 65. Thank you! teamtopologies.com 65 Matthew Skelton, Conflux @matthewpskelton Manuel Pais, Independent @manupaisable Copyright © Conflux Digital Ltd 2018-2019. All rights reserved. Registered in England and Wales, number 10890964 Icons made by Freepick from www.flaticon.com - used under license