Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
TeamTopologies.com
@TeamTopologies
Forget ‘Monoliths vs Microservices’; focus on
Team Cognitive Load
Matthew Skelton & Man...
2
Monoliths vs Microservices
Team Cognitive Load
Case Studies
Getting started
Team Topologies
3
Organizing business and
technology teams for fast flow
Matthew Skelton & Manuel Pais
IT Revolution Press
...
4
Book signing ✍
TODAY
@ 19:15
Monoliths vs
Microservices
5
6
“Start with monolith and
extract microservices.”
- Tammer Saleh
7
https://www.infoq.com/presentations/cloud-anti-patterns
“Don’t start with a
monolith when your goal is
a microservices
architecture”
- Stefan Tilkov
8
http://martinfowler.com/art...
“If you can't build a
monolith, what makes you
think microservices are
the answer?”
- Simon Brown
9
http://www.codingthear...
10
WTF?!?!
* where to focus?
“Software that
fits in your head”
- Daniel Terhorst-North
11
https://speakerdeck.com/tastapod/microservices-software-that-f...
12
“Software that
fits in our heads”
4 key metrics: ‘Accelerate’
13
lead time
deployment frequency
mean time to restore (MTTR)
change fail percentage
Software that is ‘too big for
our heads’ works against
organizational agility
14
Team Cognitive Load
15
COGNITIVE LOAD:
The total amount of
mental effort being used
in the working memory
- John Sweller
16
Intrinsic
Extraneous
Germane
17
“How are
classes
defined in
Java?”
Intrinsic
Extraneous
Germane
18
“How do I
deploy this
app,
again?”
Intrinsic
Extraneous
Germane
19
“How do
bank
transfers
work?”
Intrinsic (skills)
Extraneous (mechanism)
Germane (domain focus)
20
(Intrinsic)
] Extraneous [
Germane
21
More: ‘Hacking Your Head’
22
Jo Pearce
(@jdpearce)
https://www.slideshare.net/JoPearce5/hacking-your-head-managing-informa...
Limit the size of software
services/products to the
cognitive load that the
team can handle.
23
24
“Software that
fits in our heads”
A ‘team-first’
approach to software
boundaries
25
Team size ≲ 9 *
* possibly 15
26
27
Each service must be fully
owned by a team with
sufficient cognitive capacity
to build and operate it.
Whole-team
techniques (mobbing)
28
Well-chosen domain
boundaries (DDD)
29
Developer Experience
#DevEx
30
Operator Experience
#operability
31
Thinnest Viable Platform
(TVP)
32
4 fundamental topologies
33
Stream-aligned team
Enabling team
Complicated Subsystem team
Platform team
4 fundamental topologies
34
Flow of change
3 core interaction modes
35
Flow of change
X-as-a-Service
Facilitating
Collaboration
“...trend analysis, simulations, rapid
prototyping, scenario planning,
gaming, environmental scanning
… give clues to the ...
Case Studies
37
CaseStudy
38
CaseStudy
39
2016
(early)
CaseStudy
40
2016
(late)
CMS
CaseStudy
Framework
41
2017
(early)
CMS
Products
CaseStudy
Framework
42
Products
2017
(late)
CMS
Team became too large
⇔
System became monolithic
Blocked flow of work across streams
43
Listen to ‘triggers for evolution’
❏ Software grows too large
❏ Over specialization (Brent)
❏ Increased coordination needs...
CaseStudy
45
CaseStudy
46
CD Enablement
Infrastructure
Automation
Test
Automation
Build & CI
Support
CaseStudy
47
CD Enablement Infrastructure
Automation
Test
Automation
Build & CI
Support
It’s not always about software size...
More broadly, align size and number
of domains of responsibility
with team cognitiv...
Aim for teams with high cohesion internally
(think autonomy, mastery & purpose)
Aim for low bandwidth comms
between smalle...
Listen to ‘triggers for evolution’
❏ Awkward interactions
❏ People not invested, burn out
❏ Frequent context switching
50
Getting started with
team cognitive load
51
How well can the team as a unit “grok”
the systems they own and develop?
Explicit cognitive load
52
Push some things into a Platform?
Explicit cognitive load
53
Are skills or capabilities missing?
Explicit cognitive load
54
What would change if we adopted the
3 team interaction patterns?
Collaboration, X-as-a-Service, Facilitating
Team Interact...
Collaboration, X-as-a-Service, Facilitating
How would teams react & behave?
Team Interactions
56
How is your Platform defined?
Thinnest Viable Platform
57
What is the thinnest platform that
could work?
Thinnest Viable Platform
58
What’s needed to run and support it?
Thinnest Viable Platform
59
Team Topologies
60
Organizing business and
technology teams for fast flow
Matthew Skelton & Manuel Pais
IT Revolution Press...
Training
61
Day 1
Fundamentals
Day 2
Deep Dive
Day 3
Applying in Context
teamtopologies.com/training
Looking for case studies
62
Global manufacturing company
Large government agency
Global financial services
Remaining problems
63
Measuring cognitive load at scale
Assessing team communication at scale
How to nudge managers and he...
TeamTopologies.com
@TeamTopologies
Sign up for news and tips:
TeamTopologies.com
Thank you!
teamtopologies.com
65
Matthew Skelton, Conflux
@matthewpskelton
Manuel Pais, Independent
@manupaisable
Copyright...
Nächste SlideShare
Wird geladen in …5
×

Monoliths vs microservices is missing the point - start with team cognitive load - Team Topologies - DOES USA - 2019-10-30

330 Aufrufe

Veröffentlicht am

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 we explain how and why, based on material from the book Team Topologies by Matthew Skelton and Manuel Pais.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

Monoliths vs microservices is missing the point - start with team cognitive load - Team Topologies - DOES USA - 2019-10-30

  1. 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 USA 2019 - 29 Oct
  2. 2. 2 Monoliths vs Microservices Team Cognitive Load Case Studies Getting started
  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 Book signing ✍ TODAY @ 19:15
  5. 5. Monoliths vs Microservices 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. Team Cognitive Load 15
  16. 16. COGNITIVE LOAD: The total amount of mental effort being used in the working memory - John Sweller 16
  17. 17. Intrinsic Extraneous Germane 17 “How are classes defined in Java?”
  18. 18. Intrinsic Extraneous Germane 18 “How do I deploy this app, again?”
  19. 19. Intrinsic Extraneous Germane 19 “How do bank transfers work?”
  20. 20. Intrinsic (skills) Extraneous (mechanism) Germane (domain focus) 20
  21. 21. (Intrinsic) ] Extraneous [ Germane 21
  22. 22. More: ‘Hacking Your Head’ 22 Jo Pearce (@jdpearce) https://www.slideshare.net/JoPearce5/hacking-your-head-managing-information-overload-extended
  23. 23. Limit the size of software services/products to the cognitive load that the team can handle. 23
  24. 24. 24 “Software that fits in our heads”
  25. 25. A ‘team-first’ approach to software boundaries 25
  26. 26. Team size ≲ 9 * * possibly 15 26
  27. 27. 27 Each service must be fully owned by a team with sufficient cognitive capacity to build and operate it.
  28. 28. Whole-team techniques (mobbing) 28
  29. 29. Well-chosen domain boundaries (DDD) 29
  30. 30. Developer Experience #DevEx 30
  31. 31. Operator Experience #operability 31
  32. 32. Thinnest Viable Platform (TVP) 32
  33. 33. 4 fundamental topologies 33 Stream-aligned team Enabling team Complicated Subsystem team Platform team
  34. 34. 4 fundamental topologies 34 Flow of change
  35. 35. 3 core interaction modes 35 Flow of change X-as-a-Service Facilitating Collaboration
  36. 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. 37. Case Studies 37
  38. 38. CaseStudy 38
  39. 39. CaseStudy 39 2016 (early)
  40. 40. CaseStudy 40 2016 (late) CMS
  41. 41. CaseStudy Framework 41 2017 (early) CMS Products
  42. 42. CaseStudy Framework 42 Products 2017 (late) CMS
  43. 43. Team became too large ⇔ System became monolithic Blocked flow of work across streams 43
  44. 44. Listen to ‘triggers for evolution’ ❏ Software grows too large ❏ Over specialization (Brent) ❏ Increased coordination needs 44
  45. 45. CaseStudy 45
  46. 46. CaseStudy 46 CD Enablement Infrastructure Automation Test Automation Build & CI Support
  47. 47. CaseStudy 47 CD Enablement Infrastructure Automation Test Automation Build & CI Support
  48. 48. It’s not always about software size... More broadly, align size and number of domains of responsibility with team cognitive capacity. 48
  49. 49. Aim for teams with high cohesion internally (think autonomy, mastery & purpose) Aim for low bandwidth comms between smaller teams 49
  50. 50. Listen to ‘triggers for evolution’ ❏ Awkward interactions ❏ People not invested, burn out ❏ Frequent context switching 50
  51. 51. Getting started with team cognitive load 51
  52. 52. How well can the team as a unit “grok” the systems they own and develop? Explicit cognitive load 52
  53. 53. Push some things into a Platform? Explicit cognitive load 53
  54. 54. Are skills or capabilities missing? Explicit cognitive load 54
  55. 55. What would change if we adopted the 3 team interaction patterns? Collaboration, X-as-a-Service, Facilitating Team Interactions 55
  56. 56. Collaboration, X-as-a-Service, Facilitating How would teams react & behave? Team Interactions 56
  57. 57. How is your Platform defined? Thinnest Viable Platform 57
  58. 58. What is the thinnest platform that could work? Thinnest Viable Platform 58
  59. 59. What’s needed to run and support it? Thinnest Viable Platform 59
  60. 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. 61. Training 61 Day 1 Fundamentals Day 2 Deep Dive Day 3 Applying in Context teamtopologies.com/training
  62. 62. Looking for case studies 62 Global manufacturing company Large government agency Global financial services
  63. 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. 64. TeamTopologies.com @TeamTopologies Sign up for news and tips: TeamTopologies.com
  65. 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

×