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

More Decks by Eberhard Wolff

Other Decks in Technology


  1. 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
  2. Is this a Great Architecture? •Can only review architecture when

    considering the people, too. •There is no “absolute great architecture”! •Use metrics with care!
  3. Is this a Great Architecture? •Interviews: Where are the problems?

    •Support findings by metrics •Think about improvements
  4. Broken but Well-Structured? •Well-structure code is not enough •Developers must

    understand the system. •Ever tried to understand a system you developed a few years back? 😬
  5. 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
  6. 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.
  7. Big Ball of Mud: Pattern A Big Ball of Mud

    is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. Why is this architecture so popular? You need to deliver quality software on time, and under budget. Therefore, focus first on features and functionality, then focus on architecture and performance. Big Ball of Mud, Brian Foote & Joseph Yoder http://www.laputan.org/mud/ Icon: Lisa Moritz
  8. Vs. Good Architecture •Good architecture: changeable •Big Ball of Mud:

    Not really changeable •Every architecture has weak spots. •How many weak spots are acceptable?
  9. Big Ball of Mud •Developers should really be afraid of

    complexity. •Being able to handle it might actually be bad.
  10. 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
  11. Should Static Code Analysis be Part of the Macro Architecture?

    •Vote: Yes, pre-defined metrics Yes, teams decides about metrics No
  12. 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
  13. 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.
  14. 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
  15. Limit: Trust •Teams may not be trusted. •E.g. external teams

    that are known to deliver poor quality. •Manage quality via static code analysis?
  16. Goodhart’s Law •Every measure which becomes a target becomes a

    bad measure. •https://en.wikipedia.org/wiki/Goodhart%27s_law
  17. 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
  18. 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? •What if members of different teams sit in the same room?
  19. 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
  20. 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. •DE https://software- architektur.tv/2020/09/10/folge016.html
  21. Inverse Conway: Assumptions •People will follow the org chart. •People

    will communicate according to the org chart. •Too simplistic
  22. Conclusion •Architecture is for people to better understand software. •So:

    There is no absolute good / bad architecture. •It depends on people.
  23. Fix the Organization? •I want to develop software …not fix

    the organization •Agile has the same problem
  24. 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
  25. 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.
  26. Psychological Safety •Without feedback no progress •So: Need to create

    an environment where people feel safe to provide and receive feedback •Psychological safety
  27. 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