The document discusses various software architecture anti-patterns, emphasizing the importance of need-driven architectures and cautioning against blindly adopting microservice architectures. It highlights the potential downsides of layering and the significance of considering factors like team boundaries and responsibilities when designing systems. The text advocates for maintaining simplicity, optimizing for change, and fostering visibility and collaboration in architectural discussions.

1. Software Architecture
Anti-Patterns
Eduards Sizovs
eduards.sizovs@gmail.com
@eduardsi

2. YAGNI Architecture

3. Story time

4. Some software is never intended to stand
out from the crowd.

5. YAGNI KIND ASS Architecture

6. KEEP IT NEED DRIVEN AND SIMPLE, SIR

7. NEED-DRIVEN ?

8. NEED-DRIVEN ?
REQUIREMENTS

9. NEED-DRIVEN ?
REQUIREMENTS • RISKS

10. NEED-DRIVEN ?
REQUIREMENTS • RISKS • CONSTRAINTS

11. Maslow's Hierarchy of Needs (of Software
Development)
http://gojko.net/2012/05/08/redefining-software-quality/

12. SIMPLE ?

13. Pick the tool you know well and ship the
simplest possible solution.

14. Optimize for CHANGE.

15. Nano-Service Architecture
When SOA goes wild.

16. You think that because you understand “one” that
you must therefore understand “two” because one
and one make two. But you forget that you must also
understand “and.”
— Sufi teaching story

17. By blindly splitting a system into "micro" services, you
get all negative consequences with questionable
benefits.

18. Micro Service-Oriented Architecture
SIZE DOESN'T MATTER

19. Driving factors for decomposition

20. Driving factors for decomposition
- Team boundaries

21. Driving factors for decomposition
- Team boundaries
- Frequency of change

22. Driving factors for decomposition
- Team boundaries
- Frequency of change
- Different responsibilities

23. Driving factors for decomposition
- Team boundaries
- Frequency of change
- Different responsibilities
- Different (cross-functional) requirements

24. Driving factors for decomposition
- Team boundaries
- Frequency of change
- Different responsibilities
- Different (cross-functional) requirements
- Different technical stack

25. Driving factors for decomposition
- Team boundaries
- Frequency of change
- Different responsibilities
- Different (cross-functional) requirements
- Different technical stack
- Prototyping / Experiments

26. Staying BIG is OK.

27. Structureless Architecture

28. Looks familiar?

29. Looks familiar?
✗ reveal high-level components

30. Looks familiar?
✗ reveal high-level components
✗ reduce discovery cost

31. Looks familiar?
✗ reveal high-level components
✗ reduce discovery cost
✗ improve comprehensibility

32. Looks familiar?
✗ reveal high-level components
✗ reduce discovery cost
✗ improve comprehensibility
✗ enable poka-yoke

33. What about this?

34. What about this?
✔ reveal high-level components

35. What about this?
✔ reveal high-level components
✔ reduce discovery cost

36. What about this?
✔ reveal high-level components
✔ reduce discovery cost
✔ improve comprehensibility

37. What about this?
✔ reveal high-level components
✔ reduce discovery cost
✔ improve comprehensibility
✔ enable poka-yoke

38. Apply micro service-oriented mindset to software
structure. Keep services decoupled as if they were
remote.

39. WHERE IS LAYERING?

40. Lasagna Architecture

41. Expected (doubtful) benefits from layering

42. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)

43. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)

44. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)
- Decoupling / abstracting for independent evolution (ha-ha)

45. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)
- Decoupling / abstracting for independent evolution (ha-ha)
- Decoupling for reuse (ha-ha)

46. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)
- Decoupling / abstracting for independent evolution (ha-ha)
- Decoupling for reuse (ha-ha)
- Separation of concerns (is particular layer our concern?)

47. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)
- Decoupling / abstracting for independent evolution (ha-ha)
- Decoupling for reuse (ha-ha)
- Separation of concerns (is particular layer our concern?)
- Related stuff co-location (are DAOs really related?)

48. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)
- Decoupling / abstracting for independent evolution (ha-ha)
- Decoupling for reuse (ha-ha)
- Separation of concerns (is particular layer our concern?)
- Related stuff co-location (are DAOs really related?)
- Constraint enforcement (is there a better way?)

49. Layering is your service's detail and is
internal to the service.

50. Keep services mind-sized so there is no
need for internal layering. Break services
into tiny modules.
(and consider keeping modules in separate VCS tree)

51. Undocumented Architecture

52. Working software over comprehensive
documentation.
(c) Agile Manifesto

53. Architecture is code!
...but level of abstraction of code is negligible

54. I remember everything!

55. Code has hard time telling you about

56. Code has hard time telling you about
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.

57. Code has hard time telling you about
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
- Significant Decisions and Agreements (e.g. rejected frameworks)

58. Code has hard time telling you about
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
- Significant Decisions and Agreements (e.g. rejected frameworks)
- Surroundings (Dependencies, Service Consumers)

59. Code has hard time telling you about
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
- Significant Decisions and Agreements (e.g. rejected frameworks)
- Surroundings (Dependencies, Service Consumers)
- Onboarding (Source Repository, Building, QC, Deployment)

60. Code has hard time telling you about
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
- Significant Decisions and Agreements (e.g. rejected frameworks)
- Surroundings (Dependencies, Service Consumers)
- Onboarding (Source Repository, Building, QC, Deployment)
- Birdseye Technical View

61. "That’s the page I read that made the
difference"
is a great sanity check

62. UML vs C4
Context, Containers, Components, Classes

63. http://static.codingthearchitecture.com/c4.pdf

64. Optimistic Architecture

65. Fault tolerance is a lesson best learned offline.

66. Raise and keep your hand if you know ->

67. Raise and keep your hand if you know ->
What connection and thread pools does your application have

68. Raise and keep your hand if you know ->
What connection and thread pools does your application have
Approximate size

69. Raise and keep your hand if you know ->
What connection and thread pools does your application have
Approximate size
Utilization during peak load

70. Raise and keep your hand if you know ->
What connection and thread pools does your application have
Approximate size
Utilization during peak load
When pools will approach the size limit

71. Raise and keep your hand if you know ->
What connection and thread pools does your application have
Approximate size
Utilization during peak load
When pools will approach the size limit
How does your app behave when pools become full

72. Raise and keep your hand if you know ->
What connection and thread pools does your application have
Approximate size
Utilization during peak load
When pools will approach the size limit
How does your app behave when pools become full
How to timely react on it

74. What if an integration point will start to fail?

75. What if an integration point will start to fail?
What if it will send slow response for 5+ minutes without failing?

76. What if an integration point will start to fail?
What if it will send slow response for 5+ minutes without failing?
What if it will send back huge 1GB result set?

77. What if an integration point will start to fail?
What if it will send slow response for 5+ minutes without failing?
What if it will send back huge 1GB result set?
If your service fails, can others handle additional load they take?

78. What if an integration point will start to fail?
What if it will send slow response for 5+ minutes without failing?
What if it will send back huge 1GB result set?
If your service fails, can others handle additional load they take?
If your service fails, how far that failure reaches into app
landscape?

79. What if an integration point will start to fail?
What if it will send slow response for 5+ minutes without failing?
What if it will send back huge 1GB result set?
If your service fails, can others handle additional load they take?
If your service fails, how far that failure reaches into app
landscape?
Can you switch off functionality that produces unexpectedly high
load?

80. Timeouts

81. Timeouts
Retries

82. Timeouts
Retries
Circuit Breakers

83. Timeouts
Retries
Circuit Breakers
Bulkheads

84. Timeouts
Retries
Circuit Breakers
Bulkheads
Handshaking

85. Timeouts
Retries
Circuit Breakers
Bulkheads
Handshaking
Leaky Bucket
...

88. Alchemy Architecture

89. Wear software architect's hat by
understanding and impacting current state
of affairs.

90. Run short design sessions before diving into
implementation.

91. Make sure architecture is VISIBLE for
everyone.

92. Run weekly meetup on issues and plan how
to get better in small steps.

93. Change the architecture with baby steps

94. Change the architecture with baby steps
~ 45 minutes a day / person

95. Change the architecture with baby steps
~ 45 minutes a day / person
~ 4 hours a week / person

96. Change the architecture with baby steps
~ 45 minutes a day / person
~ 4 hours a week / person
~ 20 hours a week / 5 people

97. Change the architecture with baby steps
~ 45 minutes a day / person
~ 4 hours a week / person
~ 20 hours a week / 5 people
No excuse for not starting tomorrow.

98. Software Architecture Essentials
11th of March, 2015
Register at www.craftsmans.lv