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.

The layperson's guide to software architecture

342 views

Published on

Software architecture explained for the layman with ThoughtWorks Lead Consultant Liauw Fendy.

Published in: Technology
  • Here's How YOU Can Stake Out Your Personal Claim In Our EIGHT MILLION DOLLAR GOLDMINE... ♥♥♥ http://ishbv.com/goldops777/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

The layperson's guide to software architecture

  1. 1. THE LAYPERSON’S GUIDE TO SOFTWARE ARCHITECTURE Liauw Fendy
  2. 2. 2 Ready to make your mark? /careers ©ThoughtWorks 2019 Commercial in Confidence
  3. 3. ANNOUNCEMENTS
  4. 4. 4 Agenda
  5. 5. ©ThoughtWorks 2019 Commercial in Confidence 5 Motivations for this talk Uncover: ● What is an architect? ● What is software architecture? ● How does design fit into architecture? ● When is the right time to make technical decisions? ● Who makes technical decisions? ● What should be the primary focus for technical decision making? Why are you here?
  6. 6. 6 ARCHITECT
  7. 7. WHAT IS AN ARCHITECT Original diagram can be found in Design it! - From programmer to Software Architect, 1st Edition, Page 4 (Diagram removed) There is a diagram here that shows an architect as someone sitting in the intersection between business, technology and users.
  8. 8. WHAT IS AN ARCHITECT Investigator Butcher Tactician Judge Instructor Entrepreneur
  9. 9. WHAT IS AN ARCHITECT An investigator An architect interviews, investigates and defines the problem. “A problem well-defined is a problem half-solved.” - Charles Kettering, Head of Research GM
  10. 10. WHAT IS AN ARCHITECT A butcher An architect splits / partitions the problem into smaller discrete pieces. “How do you eat an elephant? One bite at a time.” - Creighton Abrams, US Army General
  11. 11. WHAT IS AN ARCHITECT A tactician An architect makes plans according to the big picture and assigns responsibilities. “Start small. Think Big.” - Steve Jobs
  12. 12. WHAT IS AN ARCHITECT A judge An architect needs to understand trade-offs and make trade-offs on quality attributes. “There are no solutions. Only trade-offs.” - Thomas Sowell, Economist, Social Theorist, Stanford University
  13. 13. THERE IS NO..
  14. 14. TRADE OFF Taken from: https://www.cybera.ca/news-and-events/tech-radar/understanding-the-cap-theorem/
  15. 15. WHAT IS AN ARCHITECT A mentor An architect needs to grow architectural capabilities of others. “A rising tide lifts all boats” - Regional chamber of commerce - New England Council, or JFK
  16. 16. WHAT IS AN ARCHITECT An entrepreneur An architect needs to balance risk and manage technical debt. “He who is not courageous enough to take risks will accomplish nothing in life.” - Muhammad Ali
  17. 17. WHAT IS AN ARCHITECT Architect responsibilities: ● Define the problem ● Partition the system and assign responsibilities ● Keep an eye on the bigger picture ● Decide trade-offs among Quality attributes (CFRs) ● Grow the team’s architecture skills ● Manage technical debt Adapted from: Design it! - From programmer to Software Architect, 1st Edition, Page 4-7
  18. 18. 1 8 SOFTWARE ARCHITECTURE
  19. 19. ©ThoughtWorks 2019 Commercial in Confidence - Grady Booch Grady Booch. Taken from https://iasaglobal.org/architecture-vs-design/
  20. 20. ©ThoughtWorks 2019 Commercial in Confidence - Grady Booch “All architecture is design but not all design is architecture. ...” Grady Booch. Taken from https://iasaglobal.org/architecture-vs-design/
  21. 21. ©ThoughtWorks 2019 Commercial in Confidence - Grady Booch “...Architecture represents the significant design decisions that shape a system...” Grady Booch. Taken from https://iasaglobal.org/architecture-vs-design/
  22. 22. ©ThoughtWorks 2019 Commercial in Confidence - Grady Booch “...where significant is measured by cost of change.” Grady Booch. Taken from https://iasaglobal.org/architecture-vs-design/
  23. 23. ©ThoughtWorks 2019 Commercial in Confidence - Michael Keeling Design it! - From programmer to Software Architect, 1st Edition, Page 7
  24. 24. ©ThoughtWorks 2019 Commercial in Confidence - Michael Keeling “Software Architecture is a set of significant design decisions about how the software is organised to promote desired quality attributes and other properties." Design it! - From programmer to Software Architect, 1st Edition, Page 7
  25. 25. 2 5 DESIGN THINKING
  26. 26. RULES OF DESIGN THINKING
  27. 27. RULES OF DESIGN THINKING PRESERVE AMBIGUITY ALL DESIGN IS REDESIGN MAKE DESIGN TANGIBLE DESIGN FOR HUMANS Adapted from: Design it! - From programmer to Software Architect, 1st Edition, Page 16
  28. 28. RULES OF DESIGN THINKING Process should serve people, not people serve process DESIGN FOR HUMANS
  29. 29. RULES OF DESIGN THINKING DESIGN FOR HUMANS
  30. 30. RULES OF DESIGN THINKING DESIGN FOR HUMANS
  31. 31. RULES OF DESIGN THINKING DESIGN FOR HUMANS
  32. 32. RULES OF DESIGN THINKING DESIGN FOR HUMANS
  33. 33. RULES OF DESIGN THINKING DESIGN FOR HUMANS
  34. 34. RULES OF DESIGN THINKING DESIGN FOR HUMANS
  35. 35. RULES OF DESIGN THINKING DESIGN FOR HUMANS Taken from: https://www.sitepoint.com/feature-toggling-explained-with-qandidates-toggle/
  36. 36. RULES OF DESIGN THINKING DESIGN FOR HUMANS
  37. 37. RULES OF DESIGN THINKING DESIGN FOR HUMANS
  38. 38. RULES OF DESIGN THINKING DESIGN FOR HUMANS Developers
  39. 39. RULES OF DESIGN THINKING DESIGN FOR HUMANS
  40. 40. RULES OF DESIGN THINKING DESIGN FOR HUMANS
  41. 41. RULES OF DESIGN THINKING DESIGN FOR HUMANS
  42. 42. RULES OF DESIGN THINKING DESIGN FOR HUMANS Actionable checklist: ❏ Fill people’s needs? ❏ Easily understood? ❏ Collaborative process?
  43. 43. PRESERVE AMBIGUITY RULES OF DESIGN THINKING Delay decisions to the last responsible moment
  44. 44. PRESERVE AMBIGUITY RULES OF DESIGN THINKING Past Future Option C Option B Option A Option C will no longer be viable beyond this time
  45. 45. PRESERVE AMBIGUITY RULES OF DESIGN THINKING Delay in decision starts to have cost (Blocked) Past Future
  46. 46. PRESERVE AMBIGUITY RULES OF DESIGN THINKING Why delay: ❏ Change ❏ Information ❏ Pragmatism ❏ Budget?
  47. 47. PRESERVE AMBIGUITY RULES OF DESIGN THINKING
  48. 48. PRESERVE AMBIGUITY RULES OF DESIGN THINKING
  49. 49. ©ThoughtWorks 2019 Commercial in Confidence Manu Cornet. Taken from https://bonkersworld.net/organizational-charts
  50. 50. PRESERVE AMBIGUITY RULES OF DESIGN THINKING
  51. 51. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING If I have seen further it is only by standing on the shoulders of giants. -Isaac Newton
  52. 52. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING
  53. 53. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING
  54. 54. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING
  55. 55. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING https://www.michielrook.nl/2016/11/strangler-pattern-practice/
  56. 56. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING
  57. 57. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING
  58. 58. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING
  59. 59. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING
  60. 60. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING
  61. 61. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING
  62. 62. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING
  63. 63. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING
  64. 64. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING One new report One additional report One new report One additional report Build from scratch Create report engine Build from scratch Create report engine
  65. 65. ALL DESIGN IS REDESIGN RULES OF DESIGN THINKING
  66. 66. ARCHITECTURAL PATTERNS https://gcp.solutions https://azure.microsoft.com/en-au/solutions/architecture/ https://aws.amazon.com/architecture/
  67. 67. MAKE DESIGN TANGIBLE RULES OF DESIGN THINKING We favor the visible, the embedded, the personal, the narrated, and the tangible; we scorn the abstract. -Nassim Nicholas Taleb
  68. 68. MAKE DESIGN TANGIBLE RULES OF DESIGN THINKING Abstract = Theoretical Ambiguous = Not “locked in”
  69. 69. MAKE DESIGN TANGIBLE RULES OF DESIGN THINKING Taken from: https://c4model.com/
  70. 70. MAKE DESIGN TANGIBLE RULES OF DESIGN THINKING Taken from: https://medium.com/zenuml/zenuml-sequence-diagram-examples-4e54e3bdca3b
  71. 71. MAKE DESIGN TANGIBLE RULES OF DESIGN THINKING Taken from: https://martinfowler.com/bliki/BoundedContext.html
  72. 72. MAKE DESIGN TANGIBLE RULES OF DESIGN THINKING Taken from: http://www.bredemeyer.com/whatis.htm
  73. 73. 7 4 DESIGN MINDSETS
  74. 74. DESIGN MINDSET
  75. 75. DESIGN MINDSET
  76. 76. DESIGN MINDSET Taken from: Design it! - From programmer to Software Architect, 1st Edition, Page 19 The four design mindset according to the Design it! Book (order does not matter): - Understand - Explore - Make - Evaluate
  77. 77. Original diagram in Design it! - From programmer to Software Architect, 1st Edition, Page 22 DESIGN MINDSET (Diagram removed) The diagram shows that you need to understand business goals, explore technology, make prototype and evaluate prototype against business goals
  78. 78. DESIGN MINDSET: UNDERSTAND ● Empathy ○ Choose one thing / Trade-off slider ○ Empathy map ○ Stakeholder map ○ Interview stakeholders ○ CFR requirements gathering Taken from: https://pragprog.com/book/mkdsa/design-it
  79. 79. DESIGN MINDSET: EXPLORE ● Vision / Big picture ○ Divide and Conquer ○ Group Poster ○ Round Robin Design ○ Whiteboard jam ○ Event Storming ○ Concept Map Taken from: https://pragprog.com/book/mkdsa/design-it
  80. 80. DESIGN MINDSET: MAKE ● Concept to artefacts. Models, prototypes, documents. ○ Architecture Decision Records ○ Greatest hits reading list (curated list) ○ Inception deck ○ Spike (prototype to learn / decide) ○ Sequence diagram ○ Modular decomposition diagram Taken from: https://pragprog.com/book/mkdsa/design-it
  81. 81. DESIGN MINDSET: EVALUATE ● Risks analysis ○ Architecture Briefing ○ Code Review ○ Risk Storming ○ Decision Matrix ○ Sanity Check ○ Scenario Walkthrough Taken from: https://pragprog.com/book/mkdsa/design-it
  82. 82. 8 3 DECISION MAKING
  83. 83. WHO MAKES DECISIONS?
  84. 84. WHO MAKES DECISIONS? R A C I Responsible Who is performing the task? Accountable Who makes decisions and liable? Consulted Who has information to help? Informed Who needs to be updated on progress?
  85. 85. WHO MAKES DECISIONS? Accountable Consulted Responsible
  86. 86. ©ThoughtWorks 2019 Commercial in Confidence - Michael Keeling “Software Architecture is a set of significant design decisions about how the software is organised to promote desired quality attributes and other properties." Design it! - From programmer to Software Architect, 1st Edition, Page 7
  87. 87. Quality Attributes WHO MAKES WHAT DECISIONS? Accountable Consulted Responsible
  88. 88. Inertia WHO MAKES WHAT DECISIONS? Accountable Consulted Responsible
  89. 89. Risk WHO MAKES WHAT DECISIONS? Accountable Consulted Responsible
  90. 90. ARCHITECTURAL GUARDRAIL “Manual Fitness Functions”
  91. 91. SENSIBLE DEFAULTS “f.a.q.”
  92. 92. DESIGN DECISIONS: HOW? Quality attr. Risk Inertia
  93. 93. 9 4 TIME INVESTMENT
  94. 94. TIME INVESTMENT Original Equation can be found in Design it! - From programmer to Software Architect, 1st Edition, Page 29 (Equation removed) There is an equation here that shows total project time as a sum of architecture time, development time and rework time.
  95. 95. Original diagram can be found in Design it! - From programmer to Software Architect, 1st Edition, Page 30 TIME INVESTMENT (Diagram removed) There is a diagram here that shows the sweet spot of how much time you should spend on architecting type activities. The sweet spot really depends on the size of the project. The larger the project, the more time you should spend due to the reduction in rework time.
  96. 96. TIME INVESTMENT However, please consider: ● Cost of change: ○ Sunk cost of analysis effort ○ Sunk cost of existing work ● Wrench in the works: ○ Incomplete information “We did not know..” ○ Incorrect assumptions “We thought we knew..” ○ Changing environments “What we knew is obsolete..”
  97. 97. 99 Let’s sum up
  98. 98. ©ThoughtWorks 2019 Commercial in Confidence 100 Did you get what you came here for? Did you uncover: ● What an architect is? ● What software architecture is? ● How design fits into architecture? ● When the right time to make technical decisions is? ● Who makes what technical decisions? ● What the primary focus for technical decision making is? Was is worth your 45+ minutes?
  99. 99. WHAT IS AN ARCHITECT Original diagram can be found in Design it! - From programmer to Software Architect, 1st Edition, Page 4 (Diagram removed) There is a diagram here that shows an architect as someone sitting in the intersection between business, technology and users.
  100. 100. WHAT IS AN ARCHITECT Investigator Butcher Tactician Judge Instructor Entrepreneur
  101. 101. WHAT IS SOFTWARE ARCHITECTURE Software architecture: ● Significant design decisions ○ Significant = cost of change ○ Design = intentional ● Software organisation (patterns) ● Quality attributes
  102. 102. RULES OF DESIGN THINKING PRESERVE AMBIGUITY ALL DESIGN IS REDESIGN MAKE DESIGN TANGIBLE DESIGN FOR HUMANS Adapted from: Design it! - From programmer to Software Architect, 1st Edition, Page 16
  103. 103. PRESERVE AMBIGUITY RULES OF DESIGN THINKING Past Future Option C Option B Option A Option C will no longer be viable beyond this time
  104. 104. PRESERVE AMBIGUITY RULES OF DESIGN THINKING Delay in decision starts to have cost (Blocked) Past Future
  105. 105. DESIGN MINDSET Taken from: Design it! - From programmer to Software Architect, 1st Edition, Page 19 The four design mindset according to the Design it! Book (order does not matter): - Understand - Explore - Make - Evaluate
  106. 106. WHO MAKES WHAT DECISIONS? Accountable Consulted Responsible Quality attr. Risk Inertia
  107. 107. Design it! - From programmer to Software Architect, 1st Edition, Page 30 TIME INVESTMENT (Diagram removed) There is a diagram here that shows the sweet spot of how much time you should spend on architecting type activities. The sweet spot really depends on the size of the project. The larger the project, the more time you should spend due to the reduction in rework time.
  108. 108. SOURCE MATERIAL
  109. 109. 111 Questions?
  110. 110. ©ThoughtWorks 2019 Commercial in Confidence Thank you 112 Liauw Fendy lfendy@thoughtworks.com @lfendy
  111. 111. 113 Feedback.. bit.ly/2XcsWIx

×