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 session I explain how and why. 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 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 canown 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
Madriagil Meetup - 14 Jan 2020

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. Monoliths vs
Microservices
4

5. 5

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

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

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

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

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

11. 11
“Software that
fits in our heads”

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

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

14. Team Cognitive Load
14

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

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

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

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

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

20. (Intrinsic)
] Extraneous [
Germane
20

21. More: ‘Hacking Your Head’
21
Jo Pearce
(@jdpearce)
https://www.slideshare.net/JoPearce5/hacking-your-head-managing-information-overload-extended

22. Limit the size of software
services/products to the
cognitive load that the
team can handle.
22

23. 23
“Software that
fits in our heads”

24. “Any organization that designs a
system (defined broadly) will
produce a design whose structure is
a copy of the organization's
communication structure.”
– Mel Conway, 1968
24

25. 25

26. 26

27. 27
Reverse
Conway
Image from Max Pixel

28. A ‘team-first’
approach to software
boundaries
28

29. Team size ≲ 9 *
* possibly 15
29

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

31. Whole-team
techniques
(mob programming)
31

32. Well-chosen domain
boundaries (DDD)
32

33. 33

34. 34

35. 35

37. Developer Experience
#DevEx
37

38. Operator Experience
#operability
38

39. Thinnest Viable Platform
(TVP)
39

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

41. 4 fundamental topologies
41
Flow of change

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

43. “...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)
43

44. Case Studies
44

45. CaseStudy
45

46. CaseStudy
46
2016
(early)

47. CaseStudy
47
2016
(late)
CMS

48. CaseStudy
Framework
48
2017
(early)
CMS
Products

49. CaseStudy
Framework
49
Products
2017
(late)
CMS

50. CaseStudy
Framework
50
Products
2017
(early)
CMS

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

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

53. CaseStudy
53

54. CaseStudy
54
CD Enablement
Infrastructure
Automation
Test
Automation
Build & CI
Support

55. CaseStudy
55
CD Enablement Infrastructure
Automation
Test
Automation
Build & CI
Support

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

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

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

59. Getting started with
team cognitive load
59

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

61. 61

62. Push some things into a Platform?
Explicit cognitive load
62

63. Are skills or capabilities missing?
Explicit cognitive load
63

64. What would change if we adopted the
3 team interaction patterns?
Collaboration, X-as-a-Service, Facilitating
Team Interactions
64

65. Collaboration, X-as-a-Service, Facilitating
How would teams react & behave?
Team Interactions
65

66. How is your Platform defined?
Thinnest Viable Platform
66

67. What is the thinnest platform that
could work?
Thinnest Viable Platform
67

68. What’s needed to run and support it?
Thinnest Viable Platform
68

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

70. Training
70
Day 1
Fundamentals
Day 2
Deep Dive
Day 3
Applying in Context
teamtopologies.com/training

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

72. Thank you!
teamtopologies.com
72
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