Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Software Architecture 
Anti-Patterns 
Eduards Sizovs 
eduards.sizovs@gmail.com 
@eduardsi
YAGNI Architecture
Story time
Some software is never intended to stand 
out from the crowd.
YAGNI KIND ASS Architecture
KEEP IT NEED DRIVEN AND SIMPLE, SIR
NEED-DRIVEN ?
NEED-DRIVEN ? 
REQUIREMENTS
NEED-DRIVEN ? 
REQUIREMENTS • RISKS
NEED-DRIVEN ? 
REQUIREMENTS • RISKS • CONSTRAINTS
Maslow's Hierarchy of Needs (of Software 
Development) 
http://gojko.net/2012/05/08/redefining-software-quality/
SIMPLE ?
Pick the tool you know well and ship the 
simplest possible solution.
Optimize for CHANGE.
Nano-Service Architecture 
When SOA goes wild.
You think that because you understand “one” that 
you must therefore understand “two” because one 
and one make two. But y...
By blindly splitting a system into "micro" services, you 
get all negative consequences with questionable 
benefits.
Micro Service-Oriented Architecture 
SIZE DOESN'T MATTER
Driving factors for decomposition
Driving factors for decomposition 
- Team boundaries
Driving factors for decomposition 
- Team boundaries 
- Frequency of change
Driving factors for decomposition 
- Team boundaries 
- Frequency of change 
- Different responsibilities
Driving factors for decomposition 
- Team boundaries 
- Frequency of change 
- Different responsibilities 
- Different (cr...
Driving factors for decomposition 
- Team boundaries 
- Frequency of change 
- Different responsibilities 
- Different (cr...
Driving factors for decomposition 
- Team boundaries 
- Frequency of change 
- Different responsibilities 
- Different (cr...
Staying BIG is OK.
Structureless Architecture
Looks familiar?
Looks familiar? 
✗ reveal high-level components
Looks familiar? 
✗ reveal high-level components 
✗ reduce discovery cost
Looks familiar? 
✗ reveal high-level components 
✗ reduce discovery cost 
✗ improve comprehensibility
Looks familiar? 
✗ reveal high-level components 
✗ reduce discovery cost 
✗ improve comprehensibility 
✗ enable poka-yoke
What about this?
What about this? 
✔ reveal high-level components
What about this? 
✔ reveal high-level components 
✔ reduce discovery cost
What about this? 
✔ reveal high-level components 
✔ reduce discovery cost 
✔ improve comprehensibility
What about this? 
✔ reveal high-level components 
✔ reduce discovery cost 
✔ improve comprehensibility 
✔ enable poka-yoke
Apply micro service-oriented mindset to software 
structure. Keep services decoupled as if they were 
remote.
WHERE IS LAYERING?
Lasagna Architecture
Expected (doubtful) benefits from layering
Expected (doubtful) benefits from layering 
- Ability to distribute your layers over multiple physical tiers (ha-ha)
Expected (doubtful) benefits from layering 
- Ability to distribute your layers over multiple physical tiers (ha-ha) 
- De...
Expected (doubtful) benefits from layering 
- Ability to distribute your layers over multiple physical tiers (ha-ha) 
- De...
Expected (doubtful) benefits from layering 
- Ability to distribute your layers over multiple physical tiers (ha-ha) 
- De...
Expected (doubtful) benefits from layering 
- Ability to distribute your layers over multiple physical tiers (ha-ha) 
- De...
Expected (doubtful) benefits from layering 
- Ability to distribute your layers over multiple physical tiers (ha-ha) 
- De...
Expected (doubtful) benefits from layering 
- Ability to distribute your layers over multiple physical tiers (ha-ha) 
- De...
Layering is your service's detail and is 
internal to the service.
Keep services mind-sized so there is no 
need for internal layering. Break services 
into tiny modules. 
(and consider kee...
Undocumented Architecture
Working software over comprehensive 
documentation. 
(c) Agile Manifesto
Architecture is code! 
...but level of abstraction of code is negligible
I remember everything!
Code has hard time telling you about
Code has hard time telling you about 
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
Code has hard time telling you about 
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc. 
- Significant De...
Code has hard time telling you about 
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc. 
- Significant De...
Code has hard time telling you about 
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc. 
- Significant De...
Code has hard time telling you about 
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc. 
- Significant De...
"That’s the page I read that made the 
difference" 
is a great sanity check
UML vs C4 
Context, Containers, Components, Classes
http://static.codingthearchitecture.com/c4.pdf
Optimistic Architecture
Fault tolerance is a lesson best learned offline.
Raise and keep your hand if you know ->
Raise and keep your hand if you know -> 
What connection and thread pools does your application have
Raise and keep your hand if you know -> 
What connection and thread pools does your application have 
Approximate size
Raise and keep your hand if you know -> 
What connection and thread pools does your application have 
Approximate size 
Ut...
Raise and keep your hand if you know -> 
What connection and thread pools does your application have 
Approximate size 
Ut...
Raise and keep your hand if you know -> 
What connection and thread pools does your application have 
Approximate size 
Ut...
Raise and keep your hand if you know -> 
What connection and thread pools does your application have 
Approximate size 
Ut...
What if an integration point will start to fail?
What if an integration point will start to fail? 
What if it will send slow response for 5+ minutes without failing?
What if an integration point will start to fail? 
What if it will send slow response for 5+ minutes without failing? 
What...
What if an integration point will start to fail? 
What if it will send slow response for 5+ minutes without failing? 
What...
What if an integration point will start to fail? 
What if it will send slow response for 5+ minutes without failing? 
What...
What if an integration point will start to fail? 
What if it will send slow response for 5+ minutes without failing? 
What...
Timeouts
Timeouts 
Retries
Timeouts 
Retries 
Circuit Breakers
Timeouts 
Retries 
Circuit Breakers 
Bulkheads
Timeouts 
Retries 
Circuit Breakers 
Bulkheads 
Handshaking
Timeouts 
Retries 
Circuit Breakers 
Bulkheads 
Handshaking 
Leaky Bucket 
...
Alchemy Architecture
Wear software architect's hat by 
understanding and impacting current state 
of affairs.
Run short design sessions before diving into 
implementation.
Make sure architecture is VISIBLE for 
everyone.
Run weekly meetup on issues and plan how 
to get better in small steps.
Change the architecture with baby steps
Change the architecture with baby steps 
~ 45 minutes a day / person
Change the architecture with baby steps 
~ 45 minutes a day / person 
~ 4 hours a week / person
Change the architecture with baby steps 
~ 45 minutes a day / person 
~ 4 hours a week / person 
~ 20 hours a week / 5 peo...
Change the architecture with baby steps 
~ 45 minutes a day / person 
~ 4 hours a week / person 
~ 20 hours a week / 5 peo...
Software Architecture Essentials 
11th of March, 2015 
Register at www.craftsmans.lv
Software Architecture Anti-Patterns
Software Architecture Anti-Patterns
Software Architecture Anti-Patterns
Software Architecture Anti-Patterns
Upcoming SlideShare
Loading in …5
×

Software Architecture Anti-Patterns

2,042 views

Published on

Applications of different size, business domain and criticality suffer from a huge set of issues, be it boring enterprise software, “Highly-Loaded” social network or a cozy startup. In this talk Eduards will cover Software Architecture issues that he finds the most prevailing nowadays and what you can do with that. Think big!

Published in: Software

Software Architecture Anti-Patterns

  1. 1. Software Architecture Anti-Patterns Eduards Sizovs eduards.sizovs@gmail.com @eduardsi
  2. 2. YAGNI Architecture
  3. 3. Story time
  4. 4. Some software is never intended to stand out from the crowd.
  5. 5. YAGNI KIND ASS Architecture
  6. 6. KEEP IT NEED DRIVEN AND SIMPLE, SIR
  7. 7. NEED-DRIVEN ?
  8. 8. NEED-DRIVEN ? REQUIREMENTS
  9. 9. NEED-DRIVEN ? REQUIREMENTS • RISKS
  10. 10. NEED-DRIVEN ? REQUIREMENTS • RISKS • CONSTRAINTS
  11. 11. Maslow's Hierarchy of Needs (of Software Development) http://gojko.net/2012/05/08/redefining-software-quality/
  12. 12. SIMPLE ?
  13. 13. Pick the tool you know well and ship the simplest possible solution.
  14. 14. Optimize for CHANGE.
  15. 15. Nano-Service Architecture When SOA goes wild.
  16. 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. 17. By blindly splitting a system into "micro" services, you get all negative consequences with questionable benefits.
  18. 18. Micro Service-Oriented Architecture SIZE DOESN'T MATTER
  19. 19. Driving factors for decomposition
  20. 20. Driving factors for decomposition - Team boundaries
  21. 21. Driving factors for decomposition - Team boundaries - Frequency of change
  22. 22. Driving factors for decomposition - Team boundaries - Frequency of change - Different responsibilities
  23. 23. Driving factors for decomposition - Team boundaries - Frequency of change - Different responsibilities - Different (cross-functional) requirements
  24. 24. Driving factors for decomposition - Team boundaries - Frequency of change - Different responsibilities - Different (cross-functional) requirements - Different technical stack
  25. 25. Driving factors for decomposition - Team boundaries - Frequency of change - Different responsibilities - Different (cross-functional) requirements - Different technical stack - Prototyping / Experiments
  26. 26. Staying BIG is OK.
  27. 27. Structureless Architecture
  28. 28. Looks familiar?
  29. 29. Looks familiar? ✗ reveal high-level components
  30. 30. Looks familiar? ✗ reveal high-level components ✗ reduce discovery cost
  31. 31. Looks familiar? ✗ reveal high-level components ✗ reduce discovery cost ✗ improve comprehensibility
  32. 32. Looks familiar? ✗ reveal high-level components ✗ reduce discovery cost ✗ improve comprehensibility ✗ enable poka-yoke
  33. 33. What about this?
  34. 34. What about this? ✔ reveal high-level components
  35. 35. What about this? ✔ reveal high-level components ✔ reduce discovery cost
  36. 36. What about this? ✔ reveal high-level components ✔ reduce discovery cost ✔ improve comprehensibility
  37. 37. What about this? ✔ reveal high-level components ✔ reduce discovery cost ✔ improve comprehensibility ✔ enable poka-yoke
  38. 38. Apply micro service-oriented mindset to software structure. Keep services decoupled as if they were remote.
  39. 39. WHERE IS LAYERING?
  40. 40. Lasagna Architecture
  41. 41. Expected (doubtful) benefits from layering
  42. 42. Expected (doubtful) benefits from layering - Ability to distribute your layers over multiple physical tiers (ha-ha)
  43. 43. Expected (doubtful) benefits from layering - Ability to distribute your layers over multiple physical tiers (ha-ha) - Decoupling / abstracting for exhangeability (ha-ha)
  44. 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. 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. 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. 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. 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. 49. Layering is your service's detail and is internal to the service.
  50. 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. 51. Undocumented Architecture
  52. 52. Working software over comprehensive documentation. (c) Agile Manifesto
  53. 53. Architecture is code! ...but level of abstraction of code is negligible
  54. 54. I remember everything!
  55. 55. Code has hard time telling you about
  56. 56. Code has hard time telling you about - Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
  57. 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. 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. 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. 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. 61. "That’s the page I read that made the difference" is a great sanity check
  62. 62. UML vs C4 Context, Containers, Components, Classes
  63. 63. http://static.codingthearchitecture.com/c4.pdf
  64. 64. Optimistic Architecture
  65. 65. Fault tolerance is a lesson best learned offline.
  66. 66. Raise and keep your hand if you know ->
  67. 67. Raise and keep your hand if you know -> What connection and thread pools does your application have
  68. 68. Raise and keep your hand if you know -> What connection and thread pools does your application have Approximate size
  69. 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. 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. 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. 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
  73. 73. What if an integration point will start to fail?
  74. 74. What if an integration point will start to fail? What if it will send slow response for 5+ minutes without failing?
  75. 75. 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?
  76. 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? If your service fails, can others handle additional load they take?
  77. 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? If your service fails, how far that failure reaches into app landscape?
  78. 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? Can you switch off functionality that produces unexpectedly high load?
  79. 79. Timeouts
  80. 80. Timeouts Retries
  81. 81. Timeouts Retries Circuit Breakers
  82. 82. Timeouts Retries Circuit Breakers Bulkheads
  83. 83. Timeouts Retries Circuit Breakers Bulkheads Handshaking
  84. 84. Timeouts Retries Circuit Breakers Bulkheads Handshaking Leaky Bucket ...
  85. 85. Alchemy Architecture
  86. 86. Wear software architect's hat by understanding and impacting current state of affairs.
  87. 87. Run short design sessions before diving into implementation.
  88. 88. Make sure architecture is VISIBLE for everyone.
  89. 89. Run weekly meetup on issues and plan how to get better in small steps.
  90. 90. Change the architecture with baby steps
  91. 91. Change the architecture with baby steps ~ 45 minutes a day / person
  92. 92. Change the architecture with baby steps ~ 45 minutes a day / person ~ 4 hours a week / person
  93. 93. Change the architecture with baby steps ~ 45 minutes a day / person ~ 4 hours a week / person ~ 20 hours a week / 5 people
  94. 94. 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.
  95. 95. Software Architecture Essentials 11th of March, 2015 Register at www.craftsmans.lv

×