Tell me why - About the purpose of architectural work

Slide 1

Slide 1 text

Tell me why About the purpose of architectural work Uwe Friedrichsen – codecentric AG – 2006-2022

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Why we need architectural work

Slide 4

Slide 4 text

Architectural work without asking “why” …

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

… results in a mess

Slide 7

Slide 7 text

And how do we try to address the problem?

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

… which results in even worse archetypes

Slide 10

Slide 10 text

Hype-driven architecture

Slide 11

Slide 11 text

Tunnel-vision architecture

Slide 12

Slide 12 text

Blast-from-the-past architecture

Slide 13

Slide 13 text

One-size-fits-all architecture

Slide 14

Slide 14 text

Accidental architecture

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Let’s (re-)establish focus

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Eh, WTF?

Slide 20

Slide 20 text

Architecture attempts to satisfy quality attributes

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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)

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Another perspective …

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

A final stance …

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Wrap-up

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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