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: How Much Design?

Large software projects cannot be built without some amount of analysis and design. But not all parts of the system require the same amount of design. Some may not require any upfront design at all. Others require a few minutes of architecture discussion; some require weeks of analysis, documents and review. A balance is necessary: too much design and you're delaying the project; too little and you will add technical debt which you'll have to pay in future rewrites and painful maintaining.

How do we decide when design is needed and how much of it is needed? How do other Agile projects do it?

In this talk I discuss what the Agile literature has to say about architecture and how we can answer this question.

  • Login to see the comments

  • Be the first to like this

Software Architecture: How Much Design?

  1. 1. How much design? Òscar Vilaplana Paylogic, winter 2013
  2. 2. How much talk?
  3. 3. Know How Much & What It Means What matters Love the risks Risks of Models Architecture-Evident Code
  4. 4. What matters
  5. 5. -Paul Clemens “The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.”
  6. 6. Issues Organization of a system as a composition of components Global control structures Protocols Physical distribution Scaling, performance Evolution Design alternatives
  7. 7. What Counts Macroscopic parts of the design Everything else is cover on detailed designs. Not limited to the biggest parts in the system. e.g. the naming pattern of a method may be architecturally significant. e.g. prohibit threads, set time duration limitations on methods, require jobs to be scheduled…
  8. 8. The Chain of Intentionality Chain from high-level intentions or decisions to low-level details. Most details left open to reasonable implementation, but not all!
  9. 9. Why is it important? Skeleton of the system Influence on quality Mismatch architecture/functionality: difficult to develop. Imposes constraints easy/possible for the system to evolve in a certain way impossible to evolve in other ways
  10. 10. Constraints? Embody judgement: guide other engineers to acceptable solutions without transferring all knowledge of the domain. Conceptual integrity. Reduce needless creativity. Reduce complexity Understand runtime behavior
  11. 11. -Frederik P. Brooks Conceptual integrity of a system is an important goal of system design. A single good idea consistently applied is better than several brilliant ideas scattered across a system.
  12. 12. When is it important? Small solution space, or it’s hard to design any acceptable solution. High failure risk. Difficult quality attributes, such as meeting a very high performance requirement. New domain, even if it’s just new to you. Product lines, in which all products must share a common architecture.
  13. 13. When is it important? How bad would it be to get the architecture wrong?
  14. 14. Basic approaches Ignore Embrace Hoist
  15. 15. Architecture-indifferent design Degrades. No shared architectural visiaon. Increasing complexity.
  16. 16. Architecture-focused design Seeks architectural solutions. Entails reasoning. Uses abstractions, views.
  17. 17. Architecture hoisting Choose a suitable architecture. The architecture does the work for you.
  18. 18. Example
  19. 19. (made up)
  20. 20. Requirement The system must respond to requests within 50ms.
  21. 21. Architecture-indifferent Reuse the distributed architecture from another system. If the communication is too slow: Try to make the code more efficient. Change the architecture.
  22. 22. Architecture-focused Analyze the rest of the requirements of the system. Design an architecture that is compatible with them. Measure: Prototype, stress test, profile.
  23. 23. Architecture hoisting How can the architecture ensure that a 50ms response is always achievable? Peak demand times? Can we get additional processing from the cloud?
  24. 24. Example
  25. 25. (real)
  26. 26. Example: Queue Handle 10.000+ users per second. Stability: keep working if a few (but not all) servers die. Architecture: decentralized, identical nodes. Lower level: distributed synchronization. Benefits: easy scale up with load. Ensure fast response. Fairness with waiting times (within limits). Accepted tradeoffs: difficult to estimate waiting time, difficult to develop and test, limited fairness.
  27. 27. Example: Queue, Improved Keep working even if ALL servers die (with reduced functionality). Recover from errors, don’t fail to the customers. Architecture: client-server Tradeoffs: the client becomes a SPF: requires additional testing, protective coding.
  28. 28. Recap
  29. 29. Software architecture deals with the large-scale decisions and macroscopic elements. These decisions have a deep impact into the code. The archictecture choices are important because the architecture asks as a skeleton of the system and influences all its attributes: if the architecture is suitable for the desired features, it will be easier to build them; if it’s unsuitable, you will struggle. Architecture is just one of many things that require attention. It’s helpful to know ho much attention to pay to it. Architecture is important enough to understand and choose deliberately.
  30. 30. Software Architecture Deals with the large-scale decisions and macroscopic elements. The decisions have a deep impact into the code. The archictecture choices are important. Architecture acts as a skeleton of the system and influences all its attributes. Architecture is important enough to understand and choose deliberately.
  31. 31. How much?
  32. 32. Love the risks
  33. 33. The concept of failure is central to the design process, and it is by thinking in terms of obviating failure that successful designs are achieved.
  34. 34. Failure considerations and proactive failure analysis are essential for achieving success.
  35. 35. It is precisely when such considerations and analyses are incorrect or incomplete that design errors are introduced and actual failures occur. - Petroski, Henry Design Paradigms: Case Histories of Error and Judgment in Engineering.
  36. 36. Common approaches No front-up design Yardstick Upfront documentation Ad-hoc Risk-driven
  37. 37. No up-front design Just write code. Design happens together with coding. Impractical when failure risks are high.
  38. 38. Yardstick Define percentages of time that should be spent an design, coding, integration… Can help plan architecture effort Does not help you choose techniques.
  39. 39. Upfront documentation Choose appropriate design techiques. Write a design documentation upfront. Impractical when failure risks are low.
  40. 40. Ad-hoc React to the project needs. Decide on the spot how much design to do. Subjective. No enduring lessons.
  41. 41. Risk-driven Risks are considered as seriously as features. Identify and prioritize risks. Select and apply techniques. Evaluate risk reduction.
  42. 42. Are you risk-driven? What are your primary failure risks and corresponding engineering techniques?
  43. 43. What are risks?
  44. 44. What are risks? risk = perceived probability of failure × perceived impact
  45. 45. Risk descriptions Actionable. Testable failure scenarios.
  46. 46. Engineering Risks Analysis Design Implementation
  47. 47. Project Management Risks Schedules Sequencing of work Delivery Team size
  48. 48. Shared vocabulary Product may not understand why something doesn’t work. They will understand the risk of its failure. Engineering helps Product understand. Reverse true.
  49. 49. Treating risks with agility 1. Identify risks. 2. Evaluate mitigation. 3. Write remaining risks in testable form. 4. Prioritize risks together with features.
  50. 50. Identifying risks Qualities difficult to achieve. Incomplete requirements? Quality Attribute Workshop Taxonomy-Based Questionnaire Accept risks.
  51. 51. Prototypical risks Risks inherent in the domain. Checklist. Know them. Notice when deviating from the norm.
  52. 52. Prioritizing risks Priority to stakeholders. Perceived difficulty by developers.
  53. 53. Reduce Risks
  54. 54. Risk reduction process Explicit. Repeatable. Choose technique based on risk. Risk cannot be avoided. Understand the problem.
  55. 55. Models: Analogic vs Analytic Analogic: each element has an analogue in the domain. Analytic: direct computational analysis.
  56. 56. Choose model based on risk Understanding relationship between domain entities: Analogic. Calculate response time distributions: Analytic.
  57. 57. Stop!
  58. 58. Know when to stop effort ∝ risk Desing risky parts Subjective evaluation
  59. 59. Evolutionary vs Planned
  60. 60. Planned design Detail before construction. Not sure it can be built. Shared architecture.
  61. 61. Minimal planned design Plan to address biggest risks Evolve rest
  62. 62. Evolutionary design Grows with system. Refactoring. Test-driven design. Continuous Integration.
  63. 63. Plan or Evolve? Planning Global properties Avoid dead ends Team coordination Easier to make mistakes Evolutionary See it working earlier. Identify mistakes. Agile.
  64. 64. Fun with Models
  65. 65. Focus on risks Trade-off architecture risks vs time, acceptance… Map risks and techniques.
  66. 66. Understand Why did you take this decision? Why did you follow this process?
  67. 67. Distribute architecture skills Engineering concern! Efficient communication. Answer questions, relate them to architecture models. Small code details can be architecturally significant. Stick to architecture vs raise flag for change. Architect doesn’t compensate for developer knowledge.
  68. 68. Choices Design involves tradeoffs. Align tradeoffs align with quality attribute priorities. Follow pattern that: Helps understand reasoning Can be evaluated to check if decisions align with priorities
  69. 69. X is a priority, so we chose design Y and accepted downside Z
  70. 70. Risks of Big Design Up Front Unnecessary documentation. Coding starts → new risks or requirements found → documentation outdated. ! Address critical risks. Prototype / implement. Instead:
  71. 71. Risks of Top-Down Design Lower-level patterns ignored. Incompatibility top-level / lower levels. Lost oportunity for great solutions due to premature top-level decisions.
  72. 72. Example
  73. 73. Risks Extensibility
 supporting new use cases part of the domain requires changing the API. Knowledge
 understanding the domain is not enough to understand the API. Discoverability
 clients need to implement API- or domain- logic in order to use the API.
  74. 74. Risks, Addressed Extensibility, Knowledge
 Choice of resources and actions: follow domain, don’t restrict to use cases. Discoverability
 Consistency of resources, representations, actions.
 Machine- (and human-) readable documentation for each entry point.
  75. 75. Tradeoffs Efficiency Interface segregation.
  76. 76. –Robert C. Martin Many client specific interfaces are better than one general purpose interface
  77. 77. Risks Extensibility
 supporting new use cases part of the domain requires changing the API. Knowledge
 understanding the domain is not enough to understand the API. Discoverability
 clients need to implement API- or domain- logic in order to use the API.
  78. 78. Tradeoffs Efficiency Interface segregation.
  79. 79. Risks Extensibility:
 Adding a custom API for a client (e.g for efficiency purposes) requires rewriting the business logic.
  80. 80. Communication HTTP API
 HTTP interface PTA
 Python simple types interface Paylogic Core Interface
 Interface to the core, guarantee business rules Paylogic Core
  81. 81. Communication’ Fast Frontoffice HTTP API
 Python interface that provides an efficient HTTP interface for the Frontoffice PTA Paylogic Core Interface Paylogic Core
  82. 82. Communication’ Frontoffice HTTP Layer
 Simple HTTP layer Fast Frontoffice API
 Python interface that provides an efficient API for the Frontoffice Paylogic Core Interface Paylogic Core
  83. 83. Remaining Challenges
  84. 84. Estimating Risks Unforeseen risks (checklists help). Risk priority.
  85. 85. Evaluating Alternatives Costly. Balance of detail: Enough detail to represent usefulness. Work required.
  86. 86. Reusability of models Not always possible. Safely ignored details may be important when reusing.
  87. 87. Issues Spanning Other Teams Dilemma: Solve problem in Engineering, or Buy tool for Customer Support to solve on their own.
  88. 88. Risks of Models
  89. 89. Solving Problems Sometimes abstractions are needed. Sometimes they aren’t. Good choice: efficiency + good results!
  90. 90. Abstractions Size, complexity. Focus on essence. Reason about system qualities.
  91. 91. -George E. P. Box All models are wrong, but some are useful.
  92. 92. Reasoning One model, different purposes. Amplify reasoning. Standards: spot errors. Question first! What to ask? Details Abstraction level
  93. 93. Risks of Model Everything Wasted effort. Analysis paralysis.
  94. 94. Not every project needs models Models help solve problems and mitigate risks. Some problems are best solved with models. Other problems are best solved directly.
  95. 95. Don’t Blindly Model Thoroughly Is there a reason? Is there a risk?
  96. 96. Code first? Reveal risks. Prototype, test, measure.
  97. 97. Models Domain: Truths. Design: System. Commitments (incomplete) Code: Implementation structure. Commitments (complete). Business: What the business does, why. Goals.
  98. 98. Common objections Already know the domain. Too simple. Irrelevant for architecture. Someone else’s job. Learn by coding. Analysis paralysis.
  99. 99. Common objections Already know the domain: Details! Too simple: Details! Irrelevant for architecture: How do you know! Someone else’s job: Your insight! Learn by coding: Impractical! Analysis paralysis: Indeed, but <next slide>!
  100. 100. Avoid Paralysis Begin with questions …about failure risks! Decide ahead depth and breadth Know when to stop.
  101. 101. Architecture Evident Code
  102. 102. Code-Model Gap Abstraction Commitments Intensional elements
  103. 103. Work Through the Gap Understand both the architecture models and the code. Keep models and code in sync. Write architecture-evident code.
  104. 104. When to update the model?
  105. 105. Architecture Evident Code Code: solution. Decisions? Embed architectural intent. Go beyond “it works”.
  106. 106. Why? Evolution. Maintainability. Developer efficiency. Lower documentation burden. Easy to get started.
  107. 107. Hints Intent: cancel a basket. Not evident: db.query(‘update ord_orders where…’) Evident: pta.basket.cancel(…). As in the domain: Basket resource. Cancel operation.
  108. 108. Model In Code Types and relationships of the domain are still valid in the code. Makes sense in the domain: it makes sense in the code. Easier to allocate responsibilities. Easier to learn about the domain by reading the code.
  109. 109. Conclusion
  110. 110. Care About Architecture. Risks. Right measure. Re-evaluate. Sync model and code. Make model evident.
  111. 111. Thanks!