Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Software Architecture for Humans

Software Architecture for Humans

Software architecture is only appearing to be a technical topic. Of course, software needs to have technologies and structures, but people have to be at the focus of the architecture. After all, the key challenge of software development and software architecture is that the software systems the we build are too complex for a single human to understand. However, the organization and management of people can also solve problems that relate to software architecture. Thus, the talk shows the dependencies between architecture, people, and organization - and how to use them to develop software more successfully.

Eberhard Wolff

May 10, 2023
Tweet

More Decks by Eberhard Wolff

Other Decks in Technology

Transcript

  1. Software Architecture for
    Humans – not Computers!
    Eberhard Wolff
    Head of Architecture
    https://swaglab.rocks/
    https://ewolff.com/

    View Slide

  2. Is this a Great Architecture?

    View Slide

  3. Why are we Doing Architecture?
    •Human have limited mental capacity
    •Humans must be able to modify the system
    •Architecture should allow humans to
    change a system with limited knowledge

    View Slide

  4. Is this a Great Architecture?

    View Slide

  5. Is this a Great Architecture?
    For whom?

    View Slide

  6. 👍

    View Slide

  7. Is this a Great Architecture?
    •Can only review architecture when
    considering the people, too.
    •There is no “absolute great architecture”!
    •Use metrics with care!

    View Slide

  8. Is this a Great Architecture?
    •Interviews: Where are the problems?
    •Support findings by metrics
    •Think about improvements

    View Slide

  9. Consider Social Aspects
    •Who changes what?
    •What is changed frequently?
    •What is changed seldomly?
    •…

    View Slide

  10. https://software-architektur.tv/2023/06/07/folge168.html

    View Slide

  11. How Do You Improve
    an Architecture?

    View Slide

  12. Obvious: Optimize Dependencies

    View Slide

  13. Traditional Fix: Reduce Complexity
    👎

    View Slide

  14. Traditional Fix: Reduce Complexity
    👍

    View Slide

  15. Broken?
    •Team fine with one system
    •Team: This other system is really bad!
    •Metric: Other system is well-structured
    …but it was handed over to the team.
    •Team never really learned the system.

    View Slide

  16. Obvious: Optimize Dependencies
    Good luck!

    View Slide

  17. Improve People not Software
    •Figure out why developers don’t understand the
    system.
    •Educate about the architecture!

    View Slide

  18. Fix: Education

    View Slide

  19. Reading Code
    •Code is read more frequently that written.
    •Learn how to read code!
    •Felienne Hermans researches this subject.
    https://codereading.club/
    https://software-
    architektur.tv/2021/10/13/epsiode81.html

    View Slide

  20. Legacy: A Social Problem?

    View Slide

  21. Legacy: Traditional Explanation

    View Slide

  22. Legacy: Social Explanation

    View Slide

  23. Legacy: A Social Problem

    View Slide

  24. Fix: Education

    View Slide

  25. Big Ball of Mud
    Icon: Lisa Moritz

    View Slide

  26. 👍
    Increasing Complexity: Fine?

    View Slide

  27. Increasing Complexity: Fine?
    •Must stay efficiently maintainable!
    •Careful: Consequences of too low quality might be
    disastrous!
    •But: There is no such thing as a perfect system.

    View Slide

  28. https://software-architektur.tv/2023/03/31/folge159.html

    View Slide

  29. Would you like to be called
    a good developer?

    View Slide

  30. Would you like to be praised
    for being a good developer?

    View Slide

  31. View Slide

  32. Good developers
    Average
    developers

    View Slide

  33. Good developers
    Average
    developers

    View Slide

  34. Good developers
    Average
    developers
    You saved
    the day!
    You are great
    developers!

    View Slide

  35. EN https://youtu.be/3MP-4UcAYJU
    DE https://youtu.be/p7r6IE7TkpU

    View Slide

  36. Those are not good
    developers!

    View Slide

  37. Those are not good
    developers!
    I would love to agree!

    View Slide

  38. Java Certification

    View Slide

  39. https://www.heise.de/blog/Entwickler-innen-natuerliche-
    Feinde-der-Softwarearchitektur-8971097.html

    View Slide

  40. Micro- / Macro-
    Architecture

    View Slide

  41. Micro- / Macro-Architecture
    •Delegate decisions
    •Macro architecture:
    Binding for all modules
    •Micro architecture:
    Potentially different for all modules
    •Micro architecture can be left to the teams

    View Slide

  42. Micro- / Macro-Architecture:
    Static Code Analysis

    View Slide

  43. Static Code Analysis

    View Slide

  44. Should Static Code Analysis be Part of the
    Macro Architecture?
    •Vote:
    Yes, pre-defined metrics
    Yes, teams decides about metrics
    No

    View Slide

  45. Micro- / Macro-Architecture
    •Delegate decisions
    •Macro architecture:
    Binding for all modules
    •Micro architecture:
    Potentially different for all modules
    •Micro architecture can be left to the teams

    View Slide

  46. Should Static Code Analysis be Part of the
    Macro Architecture?
    •Ideally: No
    •Goals: Teams should act autonomously.
    •Teams must deliver a certain quality.
    •They decide how to do that.
    …with or without static code analysis.

    View Slide

  47. Trust
    •I trust the teams to deliver quality
    •They will choose the means to do that.
    •That might or might not include static code analysis

    View Slide

  48. Limit: Trust
    •Teams may not be trusted.
    •E.g. external teams that are known to deliver poor
    quality.
    •Manage quality via static code analysis?

    View Slide

  49. Goodhart’s Law
    •Every measure which becomes a target becomes a
    bad measure.
    •https://en.wikipedia.org/wiki/Goodhart%27s_law

    View Slide

  50. Micro- / Macro-Architecture:
    Requirements Approach

    View Slide

  51. Requirements: Different Approach
    •Document that talks about requirements
    …and how to handle them.

    View Slide

  52. Chapters
    Scaling
    Security
    Work with
    Multiple Teams

    View Slide

  53. Scaling: Requirements
    •Plan for growth!
    •Refer to the business
    goals for details.
    •Business goals are usually
    increased.
    •Prepare for unplanned
    peaks!
    Scaling
    Security
    Work with
    Multiple Teams

    Requirements
    Possible
    Solutions

    View Slide

  54. Scaling: Requirements
    •Scale up
    •Horizontal scaling
    •Sharding
    •Graceful degradation
    •Asynchronous integration
    Scaling
    Security
    Work with
    Multiple Teams

    Requirements
    Possible
    Solutions

    View Slide

  55. Scaling: Requirements
    •Description
    + List of experts
    + Advantages /
    disadvantages
    Scaling
    Security
    Work with
    Multiple Teams

    Requirements
    Possible
    Solutions

    View Slide

  56. Requirements: Take Away
    •Communicates trade-offs – the essence different
    solutions.
    •Allows teams to make their own decisions – the
    essence of architecture.
    •Actually focuses on supporting teams.
    •More autonomy

    View Slide

  57. Trust
    •Trust teams fully to solve the problem
    …or speak up.
    •Support teams.
    •Control?

    View Slide

  58. Micro- / Macro-
    Architecture: Conclusion

    View Slide

  59. When Chose What?
    •Depends on persons, culture, and trust
    •Some need to be controlled ☹️
    •Some want to be told what to do
    Guidance / support
    •Some want to decide by themselves
    Really autonomous teams

    View Slide

  60. Inverse Conway

    View Slide

  61. Inverse Conway Maneuver
    •Architecture should drive organization
    •I.e. set up the organization
    •Architecture will follow

    View Slide

  62. 🙂 😬 🙁
    Developers, Designers …
    😬
    😬
    🙁
    🙁
    🙂
    🙂
    😬
    🙂
    🙁

    View Slide

  63. 🙂 😬 🙁
    Chaos
    😬
    😬
    🙁
    🙁
    🙂
    🙂
    😬
    🙂
    🙁

    View Slide

  64. 😐 😐 😐
    Order
    😐
    😐
    😐
    😐
    😐
    😐
    😐
    😐
    😐

    View Slide

  65. 😐
    😐😐
    Order
    😐
    😐
    😐
    😐😐
    😐
    😐
    😐
    😐

    View Slide

  66. 😐
    😐😐
    Order
    😐
    😐
    😐
    😐😐
    😐
    😐
    😐
    😐
    Modul
    Modul
    Modul

    View Slide

  67. Inverse Conway: Simplification
    •Inverse Conway changes the org chart
    •Org chart is not communication!
    •Assumption: Org chart team will collaborate on
    module & communicate more internally
    •Does it work that way?

    View Slide

  68. Inverse Conway: Simplification
    •Do you think people will just follow a reorg?
    •Do you think people in the same room will work more
    closely together?
    •Why I am doing the presentation? What is the news?
    •We know but we don’t use the knowledge

    View Slide

  69. Irritating the Organization
    •Sociology: “irritating” organizations.
    •New org chart: irritation
    •Can lead to new communication structure
    •Can lead to org chart teams working on modules.
    •Might also be completely ignored.
    •https://software-
    architektur.tv/2020/09/10/folge016.html

    View Slide

  70. What Now?

    View Slide

  71. Conclusion
    •Architecture is for people to better understand
    software.
    •So: There is no absolute good / bad architecture.
    •It depends on people.

    View Slide

  72. Understand Your Problem!
    •Software or Humans?
    •Legacy because humans left?

    View Slide

  73. Fix the Organization?
    •I want to develop software
    …not fix the organization
    •Agile has the same problem

    View Slide

  74. Live with It
    •If you don’t want to / can’t fix the organization, you
    will have to live with it.
    •You might need to adjust your architecture

    View Slide

  75. Humans, not Robots
    •Computers should be deterministic
    (Yes, I know it doesn’t seem like it)
    •Humans are not deterministic.
    •Don’t simplify like the inverse Conway Maneuver!
    •Actually, we all know but are not explicit about this.

    View Slide

  76. Psychological Safety
    •Without feedback no progress
    •So: Need to create an environment where people feel
    safe to provide and receive feedback
    •Psychological safety

    View Slide

  77. https://software-architektur.tv/tags.html#Organisation

    View Slide

  78. https://www.socreatory.com/de/trainers/eberhard-wolff

    View Slide

  79. 60-Minuten-Consulting
    •Online
    •Inkl. Abschluss-Bericht
    •99€
    •https://swaglab.rocks/60-min-consulting/

    View Slide

  80. Send email to [email protected]
    Slides
    + Sample Microservices Book DE / EN
    + Sample Practical Microservices DE/EN
    + Sample of Continuous Delivery Book DE
    Powered by Amazon Lambda
    & Microservices
    EMail address logged for 14 days,
    wrong addressed emails handled manually

    View Slide