1. How much design?
Òscar Vilaplana
Paylogic, winter 2013

2. How much talk?

3. Know How Much & What It Means
What matters
Love the risks
Risks of Models
Architecture-Evident Code

4. What matters

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. Issues
Organization of a system as a composition of components
Global control structures
Protocols
Physical distribution
Scaling, performance
Evolution
Design alternatives

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. 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. 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. 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. -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. 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. When is it important?
How bad would it be to get the architecture wrong?

14. Basic approaches
Ignore
Embrace
Hoist

15. Architecture-indifferent design
Degrades.
No shared architectural visiaon.
Increasing complexity.

16. Architecture-focused design
Seeks architectural solutions.
Entails reasoning.
Uses abstractions, views.

17. Architecture hoisting
Choose a suitable architecture.
The architecture does the work for you.

18. Example

19. (made up)

20. Requirement
The system must respond to requests within 50ms.

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. 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. 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. Example

25. (real)

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. 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. Recap

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. 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. How much?

32. Love the risks

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. Failure considerations
and proactive failure analysis
are essential for achieving success.

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. Common approaches
No front-up design
Yardstick
Upfront documentation
Ad-hoc
Risk-driven

37. No up-front design
Just write code.
Design happens together with coding.
Impractical when failure risks are high.

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. Upfront documentation
Choose appropriate design techiques.
Write a design documentation upfront.
Impractical when failure risks are low.

40. Ad-hoc
React to the project needs.
Decide on the spot how much design to do.
Subjective.
No enduring lessons.

41. Risk-driven
Risks are considered as seriously as features.
Identify and prioritize risks.
Select and apply techniques.
Evaluate risk reduction.

42. Are you risk-driven?
What are your primary failure risks and
corresponding engineering techniques?

43. What are risks?

44. What are risks?
risk = perceived probability of failure × perceived impact

45. Risk descriptions
Actionable.
Testable failure scenarios.

46. Engineering Risks
Analysis
Design
Implementation

47. Project Management Risks
Schedules
Sequencing of work
Delivery
Team size

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. Treating risks with agility
1. Identify risks.
2. Evaluate mitigation.
3. Write remaining risks in testable form.
4. Prioritize risks together with features.

50. Identifying risks
Qualities difficult to achieve.
Incomplete requirements?
Quality Attribute Workshop
Taxonomy-Based Questionnaire
Accept risks.

51. Prototypical risks
Risks inherent in the domain.
Checklist.
Know them.
Notice when deviating from the norm.

52. Prioritizing risks
Priority to stakeholders.
Perceived difficulty by developers.

53. Reduce Risks

54. Risk reduction process
Explicit.
Repeatable.
Choose technique based on risk.
Risk cannot be avoided.
Understand the problem.

55. Models: Analogic vs Analytic
Analogic: each element has an analogue in the domain.
Analytic: direct computational analysis.

56. Choose model based on risk
Understanding relationship between domain entities: Analogic.
Calculate response time distributions: Analytic.

57. Stop!

58. Know when to stop
effort ∝ risk
Desing risky parts
Subjective evaluation

59. Evolutionary vs Planned

60. Planned design
Detail before construction.
Not sure it can be built.
Shared architecture.

61. Minimal planned design
Plan to address biggest risks
Evolve rest

62. Evolutionary design
Grows with system.
Refactoring.
Test-driven design.
Continuous Integration.

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. Fun with Models

65. Focus on risks
Trade-off architecture risks vs time, acceptance…
Map risks and techniques.

66. Understand
Why did you take this decision?
Why did you follow this process?

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. 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. X is a priority,
so we chose design Y
and accepted downside Z

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. 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. Example

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. 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. Tradeoffs
Efficiency
Interface segregation.

76. –Robert C. Martin
Many client specific interfaces are better than
one general purpose interface

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. Tradeoffs
Efficiency
Interface segregation.

79. Risks
Extensibility:
Adding a custom API for a client (e.g for efficiency purposes) requires rewriting
the business logic.

80. Communication
HTTP API
HTTP interface
PTA
Python simple types interface
Paylogic Core Interface
Interface to the core, guarantee business rules
Paylogic Core

81. Communication’
Fast Frontoffice HTTP API
Python interface that provides an efficient HTTP interface for the Frontoffice
PTA
Paylogic Core Interface
Paylogic Core

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. Remaining Challenges

84. Estimating Risks
Unforeseen risks (checklists help).
Risk priority.

85. Evaluating Alternatives
Costly.
Balance of detail:
Enough detail to represent usefulness.
Work required.

86. Reusability of models
Not always possible.
Safely ignored details may be important when reusing.

87. Issues Spanning Other Teams
Dilemma:
Solve problem in Engineering, or
Buy tool for Customer Support to solve on their own.

88. Risks of Models

89. Solving Problems
Sometimes abstractions are needed.
Sometimes they aren’t.
Good choice: efficiency + good results!

90. Abstractions
Size, complexity.
Focus on essence.
Reason about system qualities.

91. -George E. P. Box
All models are wrong,
but some are useful.

92. Reasoning
One model, different purposes.
Amplify reasoning.
Standards: spot errors.
Question first!
What to ask?
Details
Abstraction level

95. Risks of Model Everything
Wasted effort.
Analysis paralysis.

96. 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.

97. Don’t Blindly Model Thoroughly
Is there a reason?
Is there a risk?

98. Code first?
Reveal risks.
Prototype, test, measure.

99. Models
Domain: Truths.
Design: System. Commitments (incomplete)
Code: Implementation structure. Commitments (complete).
Business: What the business does, why. Goals.

101. Common objections
Already know the domain.
Too simple.
Irrelevant for architecture.
Someone else’s job.
Learn by coding.
Analysis paralysis.

102. 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>!

103. Avoid Paralysis
Begin with questions
…about failure risks!
Decide ahead depth and breadth
Know when to stop.

104. Architecture
Evident
Code

105. Code-Model Gap
Abstraction
Commitments
Intensional elements

106. Work Through the Gap
Understand both the architecture models and the code.
Keep models and code in sync.
Write architecture-evident code.

107. When to update the model?

108. Architecture Evident Code
Code: solution.
Decisions?
Embed architectural intent.
Go beyond “it works”.

109. Why?
Evolution.
Maintainability.
Developer efficiency.
Lower documentation burden.
Easy to get started.

110. 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.

111. 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.

112. Conclusion

113. Care About
Architecture.
Risks.
Right measure.
Re-evaluate.
Sync model and code.
Make model evident.

114. Thanks!