1. The document provides a recipe for breaking apart a monolithic software system into microservices without overloading development teams. 2. The recipe involves instrumenting the monolith to understand data flows, aligning team boundaries with natural segments of the code, and splitting the system into independent services one segment at a time. 3. The goal is to reduce cognitive load on development teams by separating codebases, deployments, and responsibilities into independent subsystems that match team capabilities and domains of expertise.

1. How to break apart a
monolithic system safely
without destroying your team
Matthew Skelton, Skelton Thatcher Consulting
@matthewpskelton
04 Nov 2016, Bristol, UK - #agilecitybrs

2. Today
Cognitive load for teams
‘Monolith’
Code Forensics
Team-first boundaries
Monolith-splitting recipe

3. For now, let’s forget:
Microservices
CQRS / Event Sourcing
Queues
(Architectural changes)

5. Continuous Delivery / etc…
30+ organisations
UK, US, EU, India, China

7. How to break apart a
monolithic system safely
without destroying your
team

8. Safer, more rapid changes
to software systems
(Business Agility)

9. A ‘team-first’ approach to
software subsystem
boundaries

10. TEAM

12. TEAM
capabilities
appetite & aptitude
understanding
responsibilities

13. (assumption)
the team is stable, slowly
changing, and long-lived
#NoProjects

14. Conway’s Law

15. “organizations which design
systems ... are constrained to
produce designs which are copies
of the communication structures of
these organizations”
– Mel Conway, 1968
http://www.melconway.com/Home/Conways_Law.html

16. Front-end
developers
Back-end
developers

17. ‘Reverse Conway’
Tobbe Gyllebring (@drunkcod)

19. homomorphic force
(#Conway  #Yawnoc)
HT @allankellynet
(same) (shape)

20. Cognitive load for teams

21. Cognitive load
the total amount of
mental effort being used in
the working memory
(see Sweller, 1988)

22. Cognitive load
Intrinsic
Extraneous (Irrelevant )
Germane (Relevant)

23. ‘Hacking Your Head’: Jo Pearce
See http://www.slideshare.net/JoPearce5/hacking-your-head-managing-information-overload-45-mix
@jdpearce

24. We have SCIENCE!

25. Science since 1988 (!)
• Driskell et al, 1999 ‘Does Stress Lead to a Loss of Team Perspective?’ Group Dynamics:
Theory, Research, and Practice 3, no. 4 (1999): 291.
• Fan et al, 2010 ‘Learning HMM-Based Cognitive Load Models for Supporting Human-Agent
Teamwork’. Cognitive Systems Research 11, no. 1 (2010): 108–119.
• Ilgen & Hollenbeck, 1993 ‘Effective Team Performance under Stress and Normal Conditions:
An Experimental Paradigm, Theory and Data for Studying Team Decision Making in
Hierarchical Teams with Distributed Expertise’. DTIC Document, 1993.
• Johnston et al, 2002 ‘Application of Cognitive Load Theory to Developing a Measure of Team
Decision Efficiency’. DTIC Document, 2002.
• Sweller, John, 1994 ‘Cognitive Load Theory, Learning Difficulty, and Instructional Design’.
Learning and Instruction 4 (1994): 295–312.
• Sweller, John, 1988. ‘Cognitive Load during Problem Solving: Effects on Learning’. Cognitive
Science 12, no. 2 (1988): 257–285.

26. “stress impacts team
performance … by narrowing
or weakening the team-level
perspective required for
effective team behavior.”
– Driskell et al, 1999
Group Dynamics: Theory, Research, and Practice 1999, Vol. 3, No. 4,291-302

27. (not just ‘pop’ science!)

28. ‘Monolith’

29. monolith
μόνο λίθος
“single stone”
Reiner Flassig - CC BY-SA 2.0 de - Wikipedia

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

31. “Start monolithic and extract”
– Tammer Saleh, Pivotal
https://www.infoq.com/presentations/cloud-anti-patterns

32. A ‘team-first’ approach to
software subsystem
boundaries

33. Types of software monoliths
•Application monolith
•Joined at the DB
•Monolithic build (rebuild everything)
•Monolithic releases (coupled)
•Monolithic thinking (standardisation)

34. Application
monolith
Single block of code
Deployed as a unit

35. Joined at
the DB
Difficult to change
separately (but not
impossible)
Risk is (probably)
elevated
Chris Collyer, http://www.stone-circles.org.uk/stone/pentreifan.htm

36. Monolithic
builds
One gigantic CI build
just to get a new
version of any
component

37. Monolithic
releases
Smaller components
bundled together into a
‘release’

38. Monolithic
thinking
‘One-size-fits-all’ for
teams
Assumption that
minimising variation is
A Good Thing

39. Dangers of splitting a
monolith
•Reduced domain consistency
•Data duplication (unintentional)
•Additional operational complexity due to
distributed system and async messaging
•Degraded UX across the product

43. Splitting a
monolith
Reiner Flassig - CC BY-SA 2.0 de - Wikipedia
Choose the right
technique for splitting
Understand the nature
of the monolith

45. ‘Fracture planes’ for code
•Business domain bounded context
•Regulatory compliance
•Change cadence
•Risk
•Performance isolation
•User personas
•Team location

46. ‘Fracture planes’ for code
Ask:
Could we consume this thing as a
service?

47. ‘Fracture planes’ for code
Ask:
Could we provide this thing as a
service?

48. Code Forensics

49. Forensics
Your Code as a
Crime Scene
Adam Tornhill

50. Adam Tornhill
Code, Crime, Complexity:
Analyzing software with
forensic psychology
Adam Tornhill
TEDxTrondheim
youtube.com/watch?v=qJ_hplxTYJw

51. ‘Code Maat’ tool

52. Adam Tornhill, http://www.adamtornhill.com/articles/crimescene/codeascrimescene.htm
Code City plus Code Maat forensics

53. Beware of badly-named
subsystems

54. "information-poor abstract
names are magnets for extra
[unwanted] responsibilities"
– Adam Tornhill
p.185, Your Code as a Crime Scene

55. Team-first boundaries

56. DevOpsTopologies.com

57. Team types
Component team
Platform / ’substrate’ team
Supporting / ‘productivity’ team
Product/Feature team

58. Team types
devopstopologies.com
Platform / ’substrate’ team
Product/Feature team

59. Team types
devopstopologies.com
Component team
Platform / ’substrate’ team
Product/Feature team

60. Team types
devopstopologies.com
Component team
Platform / ’substrate’ team
Product/Feature team
Supporting / ‘productivity’ team

61. Code repositories
Align repositories to subsystem
boundaries
Avoid monolithic-y repos like TFS*
* Don’t get me started on TFS, grrr…

62. Code repositories
Repo 1 Build Test Deploy Run
Repo 2 Build Test Deploy Run
Repo 3 Build Test Deploy Run

63. “You can use a monorepo only if
your organisation has published a
scientific paper on Computer
Science. Otherwise, use one repo
per deployable runnable thing.”
– Matthew Skelton
LondonCD meetup group, 11 Oct 2016 

64. Find natural or available
‘fracture planes’ for splitting
a monolith
(with the team in mind)

65. Industry experience
Examples from recent work with clients
Different monoliths
Different ‘fracture planes’

66. Software for R&D teams
Customers: over 80% of top 20
global pharma companies

67. 2014:
Monolithic: builds, releases
Pharma GxP: traceability
Changes slow and tricky

68. Fracture plane: business domain

71. Fracture plane: technology

72. Compose with packages
Logging for insights
Technology splits
Improved traceability

73. Major UK broadcaster (TV + online)
Increasing digital delivery of content

74. 2014:
Wide mix of technologies
Need for visibility of changes
Need for rapid turnaround

75. Fracture planes: read-only, location & cadence

76. Split off Reporting (read-only)
Split on change cadence
Increased change throughput

77. UK’s second largest
credit reference agency
Customers: major banks + large orgs

78. 2014:
6-weekly monolithic release
Outage-sensitive customers

79. Fracture planes: risk & business domain

80. Split releases based on risk
Align teams to value streams
More rapid release cadence

81. Software for Internal Comms
Customers: FTSE 100 & Fortune 1000

82. 2015:
Successful system (monolithic)
ISO 27001 compliance
Aim to expand the org (x N)

83. Fracture plane: business domain

84. Optimise split for team
engagement & personas
Minimise ISO 27001 footprint
Aided organisation expansion

85. When not to split a monolith
•‘Heritage’ ERP system (‘cloudified’)
•No native Unit Test framework
•20-30 min startup times
•VMs need 56GB RAM (yes)
•CI builds take 50 mins

86. Monolith-splitting recipe
Tried and tested!

87. How to break apart a monolith
without destroying your team
1. Instrument the monolith – logging
2. Grok data flows and fault responses
3. Align teams to available segments
4. Split off segments one-by-one

88. Instrument the monolith

89. Instrument the monolith

90. Instrument the monolith

91. search by
event
Event ID
{Delivered,
InTransit,
Arrived}

92. transaction
trace
Correlation ID
612999958…

93. Technical
Domain
public enum EventID
{
// Badly-initialised logging data
NotSet = 0,
// An unrecognised event has occurred
UnexpectedError = 10000,
ApplicationStarted = 20000,
ApplicationShutdownNoticeReceived = 20001,
PageGenerationStarted = 30000,
PageGenerationCompleted = 30001,
MessageQueued = 40000,
MessagePeeked = 40001,
BasketItemAdded = 60001,
BasketItemRemoved = 60002,
CreditCardDetailsSubmitted = 70001,
// ...
}

94. BasketItemAdded = 60001
BasketItemRemoved = 60002

95. Instrument the monolith
Correlation ID Logs
Event ID

97. use logging as a
channel/vector to
make distributed systems
more testable
use logging as a
channel/vector to
make distributed systems
more testable

98. Grok data flows and fault responses

99. Grok data flows and fault responses
Correlation ID
Event ID
Unexpected
collaborating
subsystems
Undetected
fault condition

100. Grok data flows and fault responses
Correlation ID
Event ID
Adjust
subsystem
boundaries
Fix poor fault
responses

101. runbooktemplate.info
Run Book dialogue sheets

102. Align teams to available segments

103. Align teams to available segments

104. Align teams to available segments
Map to
business
domain

105. Align teams to available segments
Identify likely
components
or ‘platform’
elements

106. Split off segments one-by-one

107. Split off segments one-by-one

108. Split off segments one-by-one
Separate:
- Builds
- Infrastructure
- Deployments
- Versions
- Lifecycle

109. Team needs / responsibilities /
capabilities come first

110. use logging as a
channel/vector to
make distributed systems
more testable
Invest in
Build & Release Engineering

112. How to break apart a monolith
without destroying your team*
1. Instrument the monolith – logging
2. Grok data flows and fault responses
3. Align teams to available segments
4. Split off segments one-by-one
(5. Invest in Build & Release Engineering)
* The simplistic version

113. How to break apart a monolith
without destroying your team*
1. Instrument
2. Grok behaviour
3. Align teams
4. Split off segments
5. Invest in Build & Release
* The simplistic version

114. How to break apart a monolith
without destroying your team*
* The simplistic version
1. Instrument
2. Grok behaviour
3. Align teams
4. Split off segments
5. Invest in Build & Release

115. Further material

117. Books & articles
• Working Effectively with Legacy Code, by Michael Feathers
• Building Microservices by Sam Newman (O’Reilly, 2015)
• ‘Managing Cognitive Load for Team Learning’ by Jo Pearce
http://12devsofxmas.co.uk/2015/12/day-3-managing-cognitive-
load-for-team-learning/
• Continuous Delivery with Windows and .NET by Matthew Skelton
and Chris O’Dell (O’Reilly, 2016) http://cdwithwindows.net/
• Team Guide to Software Operability by Matthew Skelton and Rob
Thatcher (Skelton Thatcher Publications, 2016)

118. Training
• From Monolith to Microservices (online training) – Sam Newman,
author of Building Microservices
http://www.oreilly.com/live-training/from-monolith-to-
microservices.html

119. Talks & slides
• Hacking Your Head – Managing Information Overload, by Jo
Pearce - http://www.slideshare.net/JoPearce5/hacking-your-
head-managing-information-overload-45-mix /
http://conferences.oreilly.com/oscon/open-source-
eu/public/schedule/detail/53013
• Principles of Microservices by Sam Newman @ Devoxx 2015
https://www.youtube.com/watch?v=PFQnNFe27kU

120. Research papers
• Driskell, James E., Eduardo Salas, and Joan Johnston. ‘Does Stress Lead to a Loss of Team
Perspective?’ Group Dynamics: Theory, Research, and Practice 3, no. 4 (1999): 291.
• Fan, Xiaocong, Po-Chun Chen, and John Yen. ‘Learning HMM-Based Cognitive Load Models for
Supporting Human-Agent Teamwork’. Cognitive Systems Research 11, no. 1 (2010): 108–119.
• Ilgen, Daniel R., and John R. Hollenbeck. ‘Effective Team Performance under Stress and Normal
Conditions: An Experimental Paradigm, Theory and Data for Studying Team Decision Making in
Hierarchical Teams with Distributed Expertise’. DTIC Document, 1993.
http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA284683.
• Johnston, Joan H., Stephen M. Fiore, Carol Paris, and C. A. Smith. ‘Application of Cognitive Load Theory
to Developing a Measure of Team Decision Efficiency’. DTIC Document, 2002.
http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA525820.
• Sweller, John. ‘Cognitive Load Theory, Learning Difficulty, and Instructional Design’. Learning and
Instruction 4 (1994): 295–312.
• Sweller, John. ‘Cognitive Load during Problem Solving: Effects on Learning’. Cognitive Science 12, no. 2
(1988): 257–285.

121. thank you
Matthew Skelton
@matthewpskelton
skeltonthatcher.com