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

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

    View full-size slide

  2. Uwe Friedrichsen
    Works @ codecentric
    https://twitter.com/ufried
    https://www.speakerdeck.com/ufried
    https://ufried.com/

    View full-size slide

  3. Why we need architectural work

    View full-size slide

  4. Architectural work without asking “why” …

    View full-size slide

  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

    View full-size slide

  6. … results in a mess

    View full-size slide

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

    View full-size slide

  8. We tend to discuss what architecture is
    instead of asking us why we need it
    or how to work on architecture

    View full-size slide

  9. … which results in even worse archetypes

    View full-size slide

  10. Hype-driven architecture

    View full-size slide

  11. Tunnel-vision architecture

    View full-size slide

  12. Blast-from-the-past architecture

    View full-size slide

  13. One-size-fits-all architecture

    View full-size slide

  14. Accidental architecture

    View full-size slide

  15. We need to ask why to focus our work
    Without asking why the value of our work will be accidental

    View full-size slide

  16. Let’s (re-)establish focus

    View full-size slide

  17. Why do we need architecture?
    • We need architecture to address
    • an optimization problem over time
    • with changing constraints

    View full-size slide

  18. Architecture attempts to satisfy quality attributes

    View full-size slide

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

    View full-size slide

  20. Quality attributes can be segmented in two general classes
    1. Development (incl. build & test) related attributes
    2. Runtime (usage and operation) related attributes

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  24. 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)

    View full-size slide

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

    View full-size slide

  26. Another perspective …

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  31. A final stance …

    View full-size slide

  32. "Ultimately, design is a tool to enhance our humanity”
    -- Ilse Crawford

    View full-size slide

  33. We need architecture to …
    • minimize cumulative costs without violating correctness
    • reduce cognitive load
    • make the lives of the people affected by our solutions better

    View full-size slide

  34. Uwe Friedrichsen
    Works @ codecentric
    https://twitter.com/ufried
    https://www.speakerdeck.com/ufried
    https://ufried.com/

    View full-size slide