Slide 1
Slide 1 text
Modern Trade-off Analysis
Thoughtworks
Director / Software Architect / Meme Wrangler
http://www.nealford.com
@neal4d
Neal Ford
11/25/24
Slide 2
Slide 2 text
First Law of
Software Architecture
“Everything in software
architecture is a trade-off”
Slide 3
Slide 3 text
First Law of
Software Architecture
“If you think you’ve found
something that isn’t a
tradeoff, it just means you
haven’t identified the
tradeoff…yet.”
First Corollary:
Slide 4
Slide 4 text
First Law of
Software Architecture
“You can’t avoid doing it
over and over.”
Second Corollary:
Slide 5
Slide 5 text
Architecture vs.
Design
Slide 6
Slide 6 text
architecture design
architecture design
architecture vs. design
Slide 7
Slide 7 text
architecture vs. design
A C
B D
architecture design
strategic tactical
high effort low effort
significant tradeoffs insignificant tradeoffs
is the choice more about architecture
or more about design?
Slide 8
Slide 8 text
architecture vs. design
A C
B D
architecture design
strategic tactical
high effort low effort
significant tradeoffs insignificant tradeoffs
“We are considering using microservices for
the new system”
Slide 9
Slide 9 text
architecture vs. design
A C
B D
architecture design
strategic tactical
high effort low effort
significant tradeoffs insignificant tradeoffs
“We need the cancel button moved to the
bottom of the screen”
Slide 10
Slide 10 text
architecture vs. design
A C
B D
architecture design
strategic tactical
high effort low effort
significant tradeoffs insignificant tradeoffs
“We're considering breaking the single payment service
into separate services, one for each payment type"
Slide 11
Slide 11 text
scenario 1: update credit card processing separate: maintainability, testability, deployability
architecture vs. design
Slide 12
Slide 12 text
scenario 2: add a new payment type
scenario 1: update credit card processing separate: maintainability, testability, deployability
separate: extensibility
architecture vs. design
Slide 13
Slide 13 text
scenario 2: add a new payment type
scenario 1: update credit card processing separate: maintainability, testability, deployability
separate: extensibility
scenario 3: use multiple types for payment separate: performance, data consistency
architecture vs. design
Slide 14
Slide 14 text
architecture vs. design
A C
B D
architecture design
strategic tactical
high effort low effort
significant tradeoffs insignificant tradeoffs
“The Payment Service will be broken up into separate
services, one for each payment type"
Slide 15
Slide 15 text
Iterative architecture?
adaptable
architecture
: An architecture that allows incremental additions
while maintaining existing functionality.
evolutionary
architecture
: An evolutionary architecture support guided,
incremental change across multiple dimensions.
emergent
design
: A design that gradually emerges as understanding
of the domain deepens and broadens.
Why can’t
architecture be
emergent like
design?
Slide 16
Slide 16 text
why you can’t have emergent
architecture
design:
architecture:
behavior
≠
capabilities
You can’t emerge
capabilities—they
require planning.
Slide 17
Slide 17 text
agile architecture
“Agile means no
architecture!”
Agile + architecture = fast feedback
Iterative architecture
Slide 18
Slide 18 text
Service Granularity
Slide 19
Slide 19 text
what is the right level of granularity for a service?
Slide 20
Slide 20 text
granularity integrators
“when should I consider putting services back together?”
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 21
Slide 21 text
service
functionality
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 22
Slide 22 text
service
functionality
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 23
Slide 23 text
service
functionality
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 24
Slide 24 text
code
volatility
service
functionality
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 25
Slide 25 text
code
volatility
code rarely changes
code always changes
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 26
Slide 26 text
code
volatility
code rarely changes
code always changes
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 27
Slide 27 text
code
volatility
scalability and
throughput
service
functionality
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 28
Slide 28 text
scalability and
throughput
220,000 / min
1 / min
500 / min
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 29
Slide 29 text
scalability and
throughput
220,000 / min
1 / min
500 / min
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 30
Slide 30 text
code
volatility
scalability and
throughput
fault
tolerance
X
service
functionality
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 31
Slide 31 text
fault
tolerance
X
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 32
Slide 32 text
fault
tolerance
X
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 33
Slide 33 text
code
volatility
scalability and
throughput
fault
tolerance
X
access
restriction
service
functionality
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 34
Slide 34 text
access
restriction
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 35
Slide 35 text
code
volatility
scalability and
throughput
access
restriction
fault
tolerance
X
service
functionality
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
Slide 36
Slide 36 text
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
granularity integrators
“when should I consider putting services back together?”
Slide 37
Slide 37 text
database
transactions
service granularity
granularity integrators
“when should I consider putting services back together?”
Slide 38
Slide 38 text
“register a new customer”
database
transactions
service granularity
profile info security info
{profile info,
security info}
no acid (db)
transaction
Slide 39
Slide 39 text
database
transactions
service granularity
granularity integrators
“when should I consider putting services back together?”
Slide 40
Slide 40 text
database
transactions
data
dependencies
service granularity
granularity integrators
“when should I consider putting services back together?”
Slide 41
Slide 41 text
data
dependencies
service granularity
1 2 3 4 5 6
Slide 42
Slide 42 text
1 2 3 4 5 6
data
dependencies
service granularity
Slide 43
Slide 43 text
data
dependencies
service granularity
1 2
3
4
5
6
1 2 4 6
Slide 44
Slide 44 text
data
dependencies
service granularity
1 2 3
4
5
6
1 2 4 6
3
Slide 45
Slide 45 text
data
dependencies
service granularity
1 2 3
4
5
6
1 2 4 6
3 5
Slide 46
Slide 46 text
data
dependencies
service granularity
1 2 4 6
3 5
1 2 3
4
5
6
Slide 47
Slide 47 text
data
dependencies
service granularity
1 2 4 6
3 5
1 2 3
4
5
6
Slide 48
Slide 48 text
data
dependencies
service granularity
1 2 4 6
3 5
1 2 3
4
5
6
Slide 49
Slide 49 text
1 2 4 6
3 5
1
data
dependencies
service granularity
2 3 4 6
5
Slide 50
Slide 50 text
database
transactions
data
dependencies
service granularity
granularity integrators
“when should I consider putting services back together?”
Slide 51
Slide 51 text
database
transactions
workflow and
choreography
data
dependencies
service granularity
granularity integrators
“when should I consider putting services back together?”
Slide 52
Slide 52 text
service granularity
Slide 53
Slide 53 text
service granularity
1500ms
4500ms
! responsiveness and
performance
Slide 54
Slide 54 text
service granularity
! reliability and data
consistency
Slide 55
Slide 55 text
database
transactions
workflow and
choreography
data
dependencies
service granularity
granularity integrators
“when should I consider putting services back together?”
Slide 56
Slide 56 text
service granularity
granularity disintegrators
“when should I consider breaking apart a service?”
granularity integrators
“when should I consider putting services back together?”
Slide 57
Slide 57 text
Build Your Own
Trade-off Analyses
Slide 58
Slide 58 text
First Law of
Software Architecture
“Everything in software
architecture is a trade-off”
Slide 59
Slide 59 text
Modern Tradeoff
Analysis
“What happens when there
are no best practices?”
?
Slide 60
Slide 60 text
Business
Drivers
Architecture
Characteristics
Trade-off
Analysis
“Time To Market!” Maintainability
Testability
Deployability
Performance vs. Maintainability
Analyzing Architecture Tradeoffs
Slide 61
Slide 61 text
Watch out for the “out of context”
trap when analyzing trade-offs.
Slide 62
Slide 62 text
“I can’t decide whether to use shared libraries or
shared services for the common functionality
in the system.”
software
architect
Slide 63
Slide 63 text
scalability
fault tolerance
performance
overall change risk
heterogeneous code X
high code volatility X
ability to version changes X
X
X
X
X
Slide 64
Slide 64 text
“We have services written in 4 different languages in
our ecosystem. Performance and fault tolerance aren't concerns for us –
it’s all about managing frequent changes to
shared functionality.”
software
architect
Slide 65
Slide 65 text
Use qualitative analysis to iterate
on design, leading to quantitative
analysis.
Slide 66
Slide 66 text
“I'm not sure which distributed architecture style
would be most appropriate for the new system.”
software
architect
Microservices
Service-Based
Event-Driven
Space-Based
Slide 67
Slide 67 text
maintainability maintainability maintainability maintainability
Microservices Service-Based Event-Driven Space-Based
Slide 68
Slide 68 text
Business
Drivers
Architecture
Characteristics
Trade-off
Analysis
“Time To Market!” Maintainability
Testability
Deployability
Analyzing Architecture Tradeoffs
Slide 69
Slide 69 text
maintainability maintainability maintainability maintainability
Microservices Service-Based Event-Driven Space-Based
Slide 70
Slide 70 text
“I'm not sure which transactional saga to use
for the new system.”
software
architect
Slide 71
Slide 71 text
epic saga
fantasy fiction saga
fairy tale saga
parallel saga
phone tag saga
horror story saga
time travel saga
anthology saga
decoupled simplicity responsiveness scalability consistency coordination comm.
atomic sync
orchestration
choreography
choreography
choreography
choreography
sync
sync
sync
async
async
async
async
orchestration
orchestration
orchestration
atomic
atomic
atomic
eventual
eventual
eventual
eventual
saga summary
Slide 72
Slide 72 text
Business
Drivers
Architecture
Characteristics
Trade-off
Analysis
“Time To Market!” Maintainability
Testability
Deployability
Analyzing Architecture Tradeoffs
Slide 73
Slide 73 text
epic saga
fantasy fiction saga
fairy tale saga
parallel saga
phone tag saga
horror story saga
time travel saga
anthology saga
decoupled simplicity responsiveness scalability consistency coordination comm.
atomic sync
orchestration
choreography
choreography
choreography
choreography
sync
sync
sync
async
async
async
async
orchestration
orchestration
orchestration
atomic
atomic
atomic
eventual
eventual
eventual
saga summary
eventual
Slide 74
Slide 74 text
“Now that the system is in place, we need
to demonstrate overall agility to support
our fast time-to-market needs.”
software
architect
Quantitative Analysis
Slide 75
Slide 75 text
“An architectural fitness function
provides an objective integrity
assessment of some
architectural characteristic(s).”
architecture fitness functions
Quantitative Analysis
Slide 76
Slide 76 text
average development to release hours and calendar days for features or bugs
based on sizing (broken down by development, testing, and deployment effort)
Quantitative Analysis
average hours
time
Slide 77
Slide 77 text
Quantitative Analysis
number of errors and bugs over time
# errors and bugs
time
Slide 78
Slide 78 text
Model relevant business use-case
scenarios to identify trade-offs.
Slide 79
Slide 79 text
“I wonder if we should have a single payment
service or a separate service for each
payment type.”
software
architect
Slide 80
Slide 80 text
scenario 1: update credit card processing separate: maintainability, testability, deployability
Slide 81
Slide 81 text
scenario 2: add a new payment type
scenario 1: update credit card processing separate: maintainability, testability, deployability
separate: extensibility
Slide 82
Slide 82 text
scenario 2: add a new payment type
scenario 1: update credit card processing separate: maintainability, testability, deployability
separate: extensibility
scenario 3: use multiple types for payment separate: performance, data consistency
Slide 83
Slide 83 text
Business
Drivers
Architecture
Characteristics
Trade-off
Analysis
“Time To Market!” Maintainability
Testability
Deployability
Analyzing Architecture Tradeoffs
Slide 84
Slide 84 text
scenario 2: add a new payment type
scenario 1: update credit card processing separate: maintainability, testability, deployability
separate: extensibility
scenario 3: use multiple types for payment separate: performance, data consistency
Slide 85
Slide 85 text
Avoid over-evangelizing a particular
solution or technology
Slide 86
Slide 86 text
“You should always use publish-and-subscribe broadcast
messaging using topics because it supports architectural
extensibility and evolutionary architecture!”
software
architect
Slide 87
Slide 87 text
bidder
consumer
consumer
consumer bid capture
consumer
consumer
consumer bid tracking
consumer bid analytics
consumer
consumer
queue
item bid
queue
item bid
queue
item bid
bid history
consumer
consumer
consumer
queue
item bid
Slide 88
Slide 88 text
item bid
bidder
topic
consumer
consumer
consumer bid capture
consumer
consumer
consumer bid tracking
consumer bid analytics
consumer
consumer
bid history
consumer
consumer
consumer
Slide 89
Slide 89 text
“You should always use publish-and-subscribe broadcast
messaging using topics because it supports architectural
extensibility and evolutionary architecture!”
software
architect
“Wow, you are SO right! We're going
to take your advice and always use it
for everything.“
Slide 90
Slide 90 text
A little while later...
Slide 91
Slide 91 text
item bid
producer
topic
consumer
consumer
consumer bid capture
consumer
consumer
consumer bid tracking
consumer bid analytics
consumer
consumer
“I can't create separate
contracts for each of
the services!”
!
“We just had a security
breach because everyone
has uncontrolled access to
that data!”
!
“I can't use auto-scaling
because I don't have access
to the queue-depth!”
!
Slide 92
Slide 92 text
Modern Trade-off Analysis
Thoughtworks
Director / Software Architect / Meme Wrangler
http://www.nealford.com
@neal4d
Neal Ford
11/25/24