Download as PDF, PPTX
![(Intrinsic)
] Extraneous [
Germane
21](https://image.slidesharecdn.com/monolithsmicroservicesandteamcognitiveload-teamtopologies-doeseur2019-06-26-190626173619/75/Monoliths-vs-Microservices-is-Missing-the-Point-Start-with-Team-Cognitive-Load-DOES-London-2019-21-2048.jpg)
Uploaded byManuel Pais
Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load @ DOES London 2019
The document discusses the concept of team cognitive load in relation to monoliths and microservices, emphasizing that the focus should shift from the architecture to how teams manage their cognitive capacities. It highlights the importance of team autonomy, effective communication, and well-defined boundaries for services to enhance organizational agility. Key recommendations include organizing teams according to cognitive load considerations and ensuring that each team has ownership of the services they develop.
More Related Content
Similar to Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load @ DOES London 2019
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load @ DOES London 2019
- 1. TeamTopologies.com @TeamTopologies Forget ‘Monoliths vsMicroservices’; focus on Team Cognitive Load Matthew Skelton & Manuel Pais co-authors of Team Topologies @matthewpskelton @manupaisable DevOps Enterprise Summit EUR 2019 - 26 June
- 2. 2 Monoliths vs Microservices TeamCognitive Load Case Studies Getting started
- 3. Team Topologies 3 Organizing businessand technology teams for fast flow Matthew Skelton & Manuel Pais Publication date: Sept 2019 IT Revolution Press Pre-order from Amazon: https://teamtopologies.com/book
- 4. 4 Book signing ✍ Weds26 June @ 19:30
- 5.
- 6.
- 7. “Start with monolithand extract microservices.” - Tammer Saleh 7 https://www.infoq.com/presentations/cloud-anti-patterns
- 8. “Don’t start witha monolith when your goal is a microservices architecture” - Stefan Tilkov 8 http://martinfowler.com/articles/dont-start-monolith.html
- 9. “If you can'tbuild 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 tofocus?
- 11. “Software that fits inyour head” - Daniel Terhorst-North 11 https://speakerdeck.com/tastapod/microservices-software-that-fits-in-your-head?slide=62
- 12. 12 “Software that fits inour 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
- 15.
- 16. COGNITIVE LOAD: The totalamount of mental effort being used in the working memory - John Sweller 16
- 17.
- 18. Intrinsic Extraneous Germane 18 “How do I deploythis app, again?”
- 19.
- 20. Intrinsic (skills) Extraneous (mechanism) Germane(domain focus) 20
- 21.
- 22. More: ‘Hacking YourHead’ 22 Jo Pearce (@jdpearce) https://www.slideshare.net/JoPearce5/hacking-your-head-managing-information-overload-extended
- 23. Limit the sizeof software services/products to the cognitive load that the team can handle. 23
- 24. 24 “Software that fits inour heads”
- 25. A ‘team-first’ approach tosoftware boundaries 25
- 26. Team size ≲9 * * possibly 15 26
- 27. 27 Each service mustbe fully owned by a team with sufficient cognitive capacity to build and operate it.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33. 4 fundamental topologies 33 Stream-alignedteam Enabling team Complicated Subsystem team Platform team
- 34. 4 fundamental topologies 34 Flowof change
- 35. 3 core interactionmodes 35 Flow of change X-as-a-Service Facilitating Collaboration
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42. Team became toolarge ⇔ System became monolithic Blocked flow of work across streams 42
- 43. Listen to ‘triggersfor evolution’ ❏ Software grows too large ❏ Over specialization (Brent) ❏ Increased coordination needs 43
- 44.
- 45.
- 46.
- 47. It’s not alwaysabout software size... More broadly, align size and number of domains of responsibility with team cognitive capacity. 47
- 48. Aim for teamswith high cohesion internally (think autonomy, mastery & purpose) Aim for low bandwidth comms between smaller teams 48
- 49. Listen to ‘triggersfor evolution’ ❏ Awkward interactions ❏ People not invested, burn out ❏ Frequent context switching 49
- 50.
- 51. Getting started with teamcognitive load 51
- 52. How well canthe team as a unit “grok” the systems they own and develop? Explicit cognitive load 52
- 53. Push some thingsinto a Platform? Explicit cognitive load 53
- 54. Are skills orcapabilities missing? Explicit cognitive load 54
- 55. What would changeif we adopted the 3 team interaction patterns? Collaboration, X-as-a-Service, Facilitating Team Interactions 55
- 56. Collaboration, X-as-a-Service, Facilitating Howwould teams react & behave? Team Interactions 56
- 57. How is yourPlatform defined? Thinnest Viable Platform 57
- 58. What is thethinnest platform that could work? Thinnest Viable Platform 58
- 59. What’s needed torun and support it? Thinnest Viable Platform 59
- 60. Team Topologies 60 Organizing businessand technology teams for fast flow Matthew Skelton & Manuel Pais Publication date: Sept 2019 IT Revolution Press Pre-order via stores worldwide: teamtopologies.com/book
- 61. Training 61 Day 1 Fundamentals Day 2 DeepDive Day 3 Applying in Context teamtopologies.com/training
- 62. Sign up fornews and tips: TeamTopologies.com 62
- 63. Thank you! teamtopologies.com 63 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