Software architecture 101

SAF meta-framework for designing software

Transcript

1. Software Design, Architecture and the secrets of the universe (WIP) Arnon Rotem-Gal-Oz
2. The Vasa
4. What is software design?
5. What is software architecture?
6. That thing that software architects do
7. Decisions we wish we got right
8. Software architecture is the fundamental concepts or properties of a system, embodied in its elements, relationships [to each other and the environment], and in the principles of its design and evolution (IEEE 42010:2022 Software, systems and enterprise — Architecture description)
9. Software design Software architecture is the concepts or properties of a component, embodied in its elements, relationships [to each other and the environment], and in the principles of its design and evolution within the constraints of the system architecture
10. Can you design something that doesn’t work with the overall architecture?
11. The differnece between Theory and Practice
12. Scope of design • Dog house • Dream house • Sky scrapper
13. Architecture Quality Attributes Technology Patterns & Anti-patterns Principles Community experience Stakeholders Design Constraints Requirements
14. The Usual Suspects Customer End-User Project Manager Management Developers Maintainers Security Analysts Project New comers Testers Customer’s IT group
15. Principles, Heuristics and Constraints
16. Amdahl’s law maximum potential improvement to the performance of a system is limited by the portion of the system that cannot be improved
17. Gall’s Law • “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a simple system.”
18. Conway’s Law https://netmind.net/en/prisoners-of-the-organization-chart-how-the-configuration-of-teams-conditions-software-development/
19. And there are always some constraints
20. Attributes
21. Quality Attributes • Performance • Availability • Usability • Security • Maintainability • Portability • Reusability • Testability End User’s view Developer’s view • Time To Market • Cost and Benefits • Projected life time • Targeted Market • Integration with Legacy System • Roll back Schedule Business Community view A list of quality attributes exists in ISO/IEC 9126-2001 Information Technology – Software Product Quality
22. The secret to Quality Attribute Analysis is writing down Scenarios
23. Utility Performance Response Under normal conditions - update of an entity in the persistent storage <0.5 Second Latency Under normal or stress conditions, critical alert generated by the system will be displayed in less than 1 seconds (for generation) Data Loss under all conditions, a message acknowledged by the system will not be lost Availability Hardware Issues Under all conditions, when a server crash, the system will resume operation in less than 30 seconds Usability Compliance The system should comply with maritime data standards (e.g. Mercator projection) Operability The system should handle user request without impeding the user's ability to continue controlling the system (e.g. initiate additional requests) Security Unauthorized users under normal conditions and connectivity the system should alert an unauthorized login attempt (intrusion) within 1 minute Adaptability More Users When additional users need access to the system, add new /more hardware (to support load) under 4 man weeks Identify and prioritize scenarios
24. Anatomy of a scenario Under normal system load an activity upsert should take under 10ms 50th percentile, 50ms 99th percentile , 100ms 99.5th percentile Context Stimulus Response
25. Modeling/Design
26. Simple != Easy Rick Hickey “Simple made easy” https://www.youtube.com/ watch?v=LKtk3HCgTa8
28. Law of demeter • Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. • Each unit should only talk to its friends; don't talk to strangers. • Only talk to your immediate friends.
29. It is always a trade-off
32. Patterns – because you don’t need to re-invent the wheel
33. How can you efficiently provide a level of guarantee in a loosely coupled manner while maintaining the autonomy and consistency of the services? Implement the Reservation pattern and have the services provide a level of guarantee on internal resources for a limited time.
34. If you want the architecture to be followed 
 it has to be communicated
35. 
 Two roads diverged in a yellow wood, 
 And sorry I could not travel both 
 And be one traveler, long I stood 
 And looked down one as far as I could 
 To where it bent in the undergrowth (The road not taken, Robert Frost 1915)
36. When you present consider your 
 target audience
39. Technology 
 Mapping
41. Architecture Quality Attributes Technology Patterns & Anti-patterns Principles Community experience Stakeholders Design Constraints Requirements Where are we at?
42. OK then, so we are all set
43. The architecture has to be Evaluated to make sure it is any good
44. Consider Risk vs. Time to invest
45. All we have to do now is to deploy the architecture
46. Stakeholders Principles Attributes Modeling Mapping Evaluation Deployment
47. It is “easy” in waterfall & incremental
48. Can Agile and Architecture work together?
49. Building in small iterations 
 can be dangerous
50. Winchester Mystery House
51. How much design we need? “Design Stamina Hypothesis” Martin Fowler
52. Just enough design up-front Component A Component B Component C Component D Component F Component H Component I
53. Walking Skeleton
54. Evolve the 
 architecture 
 
 
 http://www.flickr.com/photos/hyperclouds/459716791/
55. Leap
56. Parallel
57. Simplification
58. Stepping Stone