$30 off During Our Annual Pro Sale. View Details »

Tell me why - About the purpose of architectural work

Tell me why - About the purpose of architectural work

We face lots of often fierce and confusing debates about architectural work - not only in the agile community. But while all the people endlessly argue about the what, how, when and how much, they forget to ask the most important question: Why?

Why are we doing architectural work in the first place? What is its purpose? Answering this question would render more than 90% of all the debates pointless.

After a short introduction, this slide deck offers three different complementing point of view why we need architectural work, what its purpose is - or at least should be. These points of view can be used to determine if suggested architectural activities really add to the purpose of software architecture or if they are just habits, opinions or beliefs.

As always, the voice track is missing (which can be a bit tricky especially for the third perspective because the accompanying slides consist just of a single quote). Nevertheless, I hope it contains some useful ideas for you.

Uwe Friedrichsen

September 09, 2022
Tweet

More Decks by Uwe Friedrichsen

Other Decks in Technology

Transcript

  1. Tell me why About the purpose of architectural work Uwe

    Friedrichsen – codecentric AG – 2006-2022
  2. Uwe Friedrichsen Works @ codecentric https://twitter.com/ufried https://www.speakerdeck.com/ufried https://ufried.com/

  3. Why we need architectural work

  4. Architectural work without asking “why” …

  5. BDUF architecture Big Design Upfront Stack-overflow architecture closely related to

    Conference-driven architecture Google-driven architecture “Agile” architecture a.k.a. “Emergent” architecture often in conjunction with “Death to all architects!” Developer-centric architecture “Strategic” architecture often found in conjunction with the “Powerpoint architect” “Architect” – step on the company career ladder working as fire accelerant … and many more anti-patterns
  6. … results in a mess

  7. And how do we try to address the problem?

  8. We tend to discuss what architecture is instead of asking

    us why we need it or how to work on architecture
  9. … which results in even worse archetypes

  10. Hype-driven architecture

  11. Tunnel-vision architecture

  12. Blast-from-the-past architecture

  13. One-size-fits-all architecture

  14. Accidental architecture

  15. None
  16. We need to ask why to focus our work Without

    asking why the value of our work will be accidental
  17. Let’s (re-)establish focus

  18. Why do we need architecture? • We need architecture to

    address • an optimization problem over time • with changing constraints
  19. Eh, WTF?

  20. Architecture attempts to satisfy quality attributes

  21. see, e.g., ISO 25010, ISO 9126 or SEI for comprehensive

    collections of quality attributes Maintainability Changeability Availability Performance Scalability Functionality Security … Understandability Accessibility Reliability Usability Portability Operability
  22. Quality attributes can be segmented in two general classes 1.

    Development (incl. build & test) related attributes 2. Runtime (usage and operation) related attributes
  23. Development related attributes • Describe the desired behavior of a

    system from a development perspective • Influence how efficiently the system can be modified • Target “cost of change” • Effectiveness can usually only be measured in hindsight • “Arcane guesswork” – subject of many (heated) debates à Optimization problem over time
  24. Runtime related attributes • Describe the desired behavior of a

    system from a usage and operations perspective • Target “correctness” • Constrain the solution options • Support evaluation of solution options • May change over time à Changing constraints
  25. Correctness of behavior Runtime (usage and operations) related attributes Cost

    of change Development related attributes Maintainability Changeability Availability Performance Scalability Functionality Security … Understandability Accessibility Reliability Usability Portability Operability
  26. Note that cost of change is not sufficient as an

    optimization goal as it neglects all other relevant types of costs. Thus, the optimization goal for architectural work needs to target the cumulative costs instead. (unfortunately, usually not covered by quality attributes)
  27. Why do we need architecture? • With architecture we attempt

    • to minimize the cumulative costs of a system over its lifetime • while ensuring the correctness of behavior at runtime
  28. Another perspective …

  29. Ideally direct mapping Context & needs (Problem domain) Implementation (Solution

    domain)
  30. Context & needs (Problem domain) Implementation (Solution domain) Abundance of

    facts and details Abundance of facts and details Too much information to cover completely Ideally direct mapping
  31. Context & needs (Problem domain) Implementation (Solution domain) Abundance of

    facts and details Abundance of facts and details Can be covered completely Architecture Condense and structure Provide guidance and orientation
  32. Architecture condenses and structures the needs and demands of the

    problem domain to provide guidance and orientation in creating the solution in order to reduce cognitive load. To do so, it typically uses high-level views of required structure and behavior, guiding principles, constraints and alike.
  33. A final stance …

  34. "Ultimately, design is a tool to enhance our humanity” --

    Ilse Crawford
  35. Wrap-up

  36. We need architecture to … • minimize cumulative costs without

    violating correctness • reduce cognitive load • make the lives of the people affected by our solutions better
  37. Uwe Friedrichsen Works @ codecentric https://twitter.com/ufried https://www.speakerdeck.com/ufried https://ufried.com/