The debate on monoliths vs microservices as architectural patterns for modern software systems usually focuses on technological aspects, missing crucial details around organizational strategy and team dynamics. Should we start with a monolith and extract microservices or start with microservices? How many microservices is the right number? These kinds of questions indicate a confusion that is made worse by the perceived need to adopt lots of new technology in order to make microservices work. The false dichotomy between monoliths and microservices helps no-one. Instead, switched-on organizations start with the team cognitive load required to build and run a part of the software system. If a team is not able to fully understand the details of a service or subsystem, there is little chance of the team being able to own and support it. The resulting team-sized services are by definition suitable in size and complexity for a single team to own, develop, and run. No longer do we care how many lines of code there are in a single service or whether it is a “monolith”: what we care about is that a team can own and run the software effectively. Using team cognitive load as the guiding principle - assessed by the team via measures such as supportability, deployability, testability, operability, prioritization difficulties and domain complexity - organizations can optimize for sustainable ownership and evolution of software systems. This talk draws on research and case studies from the book ​Team Topologies​ by Matthew Skelton and Manuel Pais (IT Revolution Press, 2019) together with first-hand consulting experience from the authors with organizations around the world.

1. TeamTopologies.com
@TeamTopologies
Forget ‘Monoliths vs Microservices’; focus on
Team Cognitive Load
Manuel Pais
co-author of Team Topologies
@manupaisable
TFOW Scotland - 6 May 2020

2. Who am I ?
2
Independent IT organizational consultant and trainer
Ex-dev, ex-build manager, ex-tester, ex-QA lead
LinkedIn instructor on Continuous Delivery
Co-author of the book Team Topologies

3. 3

4. Team Topologies
4
Organizing business and
technology teams for fast flow
Matthew Skelton & Manuel Pais
IT Revolution Press
Order via stores worldwide: teamtopologies.com/book

5. 5
Team Cognitive Load
Team-First Approach
Case Studies
Getting started

6. Team Cognitive Load
6

7. 7

8. “Start with monolith and
extract microservices.”
- Tammer Saleh
8
https://www.infoq.com/presentations/cloud-anti-patterns

9. “Don’t start with a
monolith when your goal is
a microservices
architecture”
- Stefan Tilkov
9
http://martinfowler.com/articles/dont-start-monolith.html

10. “If you can't build a
monolith, what makes you
think microservices are
the answer?”
- Simon Brown
10
http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html

11. 11
WTF?!?!
* where to focus?

12. “Software that
fits in your head”
- Daniel Terhorst-North
12
https://speakerdeck.com/tastapod/microservices-software-that-fits-in-your-head?slide=62

13. 13
“Software that
fits in our heads”

14. 4 key metrics: ‘Accelerate’
14
lead time
deployment frequency
mean time to restore (MTTR)
change fail percentage

15. Software that is ‘too big for
our heads’ works against
organizational agility
15

16. COGNITIVE LOAD:
The total amount of
mental effort being used
in the working memory
- John Sweller
16

17. Intrinsic
Extraneous
Germane
17
“How are
classes
defined in
Java?”

18. Intrinsic
Extraneous
Germane
18
“How do I
deploy this
app,
again?”

19. Intrinsic
Extraneous
Germane
19
“How do
bank
transfers
work?”

20. Intrinsic (skills)
Extraneous (mechanism)
Germane (domain focus)
20

21. (Intrinsic)
] Extraneous [
Germane
21

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. 25
Team cognitive load as
a key consideration for
org decisions

26. 26
Software Sizing
Monoliths or Microservices ?

27. 27
Start with cognitive load
Software Sizing

28. 28
Team Composition
Specialists vs Generalists?
Full Stack vs T-Shaped ?

29. 29
Team Composition
Start with cognitive load

30. 30
Team Autonomy
Fully cross-functional?

31. 31
Team Autonomy
Different team topologies
& core interaction patterns
to reduce cognitive load

32. Team-First Approach
36

33. A ‘team-first’
approach to delivery
of digital products
37

34. Team size ≲ 9 *
* possibly 15
38

35. Well-chosen streams
& domain boundaries
40

36. 41

37. 42

38. 43
Feature

39. 44
Types of streams
● a service
● a set of features
● a user persona or user journey
● a compliance standard
● a specific market or geography
● ...

40. Developer Experience
#DevEx
46

41. Operator Experience
#operability
47

42. 4 fundamental topologies
49
Stream-aligned team
Enabling team
Complicated Subsystem team
Platform team

43. 4 fundamental topologies
50
Flow of change

44. 3 core interaction modes
51
Flow of change
X-as-a-Service
Facilitating
Collaboration

45. 52
Rapid flow of change

46. 53
Rapid feedback from
running systems

47. 54

48. 55

49. 56
Handovers (can) kill flow

50. 57
Each service must be fully
owned by a team with
sufficient cognitive capacity
to build and operate it.

51. 58
Team ownership must include:
Releasability
Testability
Operability / Supportability

52. 59

53. 60

54. 62

55. 63

56. “...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)
64

57. Case Studies
65

58. CaseStudy
66

59. CaseStudy
67
2016
(early)

60. CaseStudy
68
2016
(late)
CMS

61. CaseStudy
Framework
69
2017
(early)
CMS
Products

62. CaseStudy
Framework
70
Products
2017
(late)
CMS

63. CaseStudy
Framework
71
Products
2017
(early)
CMS

64. Team became too large
⇔
System became monolithic
Blocked flow of work across streams
72

65. Listen to ‘triggers for evolution’
❏ Software grows too large
❏ Over specialization (Brent)
❏ Increased coordination needs
73

66. CaseStudy
74

67. CaseStudy
75
CD Enablement
Infrastructure
Automation
Test
Automation
Build & CI
Support

68. CaseStudy
76
CD Enablement Infrastructure
Automation
Test
Automation
Build & CI
Support

69. It’s not always about software size...
More broadly, align size and number
of domains of responsibility
with team cognitive capacity.
77

70. Aim for teams with high cohesion internally
(think autonomy, mastery & purpose)
Aim for low bandwidth comms
between smaller teams
78

71. Listen to ‘triggers for evolution’
❏ Awkward interactions
❏ People not invested, burn out
❏ Frequent context switching
79

72. Getting started
80

73. Getting started
81
Explicit cognitive load

74. How well can the team as a unit “grok”
the systems they own and develop?
Explicit cognitive load
82

75. 83

76. Push some things into a Platform?
Explicit cognitive load
84

77. Are skills or capabilities missing?
Explicit cognitive load
85

78. Getting started
86
Explicit cognitive load
Misaligned work streams
Team Interactions
Thinnest Viable Platform

79. Does it frequently take three or more
teams to change a single user journey?
Misaligned work streams
87

80. Are development teams assumed to
know and comply with regulations?
Misaligned work streams
88

81. Is “cost reduction” the holy grail?
Misaligned work streams
89

82. Getting started
90
Team interactions

83. 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
91

84. Getting started
92
Explicit cognitive load
Misaligned work streams
Team interactions

85. Team Topologies
93
Organizing business and
technology teams for fast flow
Matthew Skelton & Manuel Pais
IT Revolution Press
Order via stores worldwide: teamtopologies.com/book

86. Workbook
coming soon...
Team Topologies
for Remote Teams
94
for Remote
Teams
Sign up for news: teamtopologies.com/newsletter
Icon by Pixel perfect from www.flaticon.com

87. Resources
95
Remote-first interactions
teamtopologies.com/remote-first
Free tools & templates
github.com/teamtopologies

88. Remote-
Friendly
Training
🠊 teamtopologies.com/training
96

89. Remote-Friendly
Assessments
🠊 teamtopologies.com/assessments
97

90. Team Topologies for PMs
98
ascent.pmi.org
self-paced 4h course
TT4PM20
20% discount code
More courses from Peter
Drucker, Jeff Gothelf &
Josh Seiden, and others

91. TeamTopologies.com
@TeamTopologies
Sign up for news and tips:
TeamTopologies.com

92. Thank you!
teamtopologies.com
100
Matthew Skelton, Conflux
@matthewpskelton
Manuel Pais, Independent
@manupaisable
Copyright © Conflux Digital Ltd 2018-2020. All rights reserved.
Registered in England and Wales, number 10890964
Icons made by Freepick from www.flaticon.com - used under license