Monoliths, microservices, and team cognitive load - Team Topologies - DOES EUR 2019-06-26
12 likes6,762 views
The document discusses the concept of team cognitive load and advocates for a 'team-first' approach in software development, emphasizing the need for teams to manage software services within their cognitive capacity. It outlines key metrics for assessing software health, the importance of aligning team sizes with responsibilities, and introduces four fundamental team topologies for effective collaboration. The authors, Matthew Skelton and Manuel Pais, promote a practical framework for organizing teams to enhance agility and performance in technology contexts.
![(Intrinsic)
] Extraneous [
Germane
21](https://image.slidesharecdn.com/monolithsmicroservicesandteamcognitiveload-teamtopologies-doeseur2019-06-26-190626175233/85/Monoliths-microservices-and-team-cognitive-load-Team-Topologies-DOES-EUR-2019-06-26-21-320.jpg)
Monoliths, microservices, and team cognitive load - Team Topologies - DOES EUR 2019-06-26
- 1. TeamTopologies.com @TeamTopologies Forget ‘Monoliths vs Microservices’; 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 Team Cognitive Load Case Studies Getting started
- 3. Team Topologies 3 Organizing business and 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 ✍ Weds 26 June @ 19:30
- 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. Case Studies 36
- 37. CaseStudy 37
- 42. Team became too large ⇔ System became monolithic Blocked flow of work across streams 42
- 43. Listen to ‘triggers for evolution’ ❏ Software grows too large ❏ Over specialization (Brent) ❏ Increased coordination needs 43
- 44. CaseStudy 44
- 47. It’s not always about software size... More broadly, align size and number of domains of responsibility with team cognitive capacity. 47
- 48. Aim for teams with high cohesion internally (think autonomy, mastery & purpose) Aim for low bandwidth comms between smaller teams 48
- 49. Listen to ‘triggers for evolution’ ❏ Awkward interactions ❏ People not invested, burn out ❏ Frequent context switching 49
- 50. CaseStudy
- 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 Publication date: Sept 2019 IT Revolution Press Pre-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. Sign up for news 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