Visual Architecting Ruth Malan Talk Outline 92 03 Decision - - PowerPoint PPT Presentation

visual architecting
SMART_READER_LITE
LIVE PREVIEW

Visual Architecting Ruth Malan Talk Outline 92 03 Decision - - PowerPoint PPT Presentation

Ruth Malan Visual Architecting Ruth Malan Talk Outline 92 03 Decision Template Title: short noun phrase Context: describe the forces at play, probably in tension Decision: describe our response to these forces Status: proposed,


slide-1
SLIDE 1

Ruth Malan

Visual Architecting

Ruth Malan

slide-2
SLIDE 2

Talk Outline

slide-3
SLIDE 3

’92

slide-4
SLIDE 4

’03

slide-5
SLIDE 5
slide-6
SLIDE 6

Title: short noun phrase Context: describe the forces at play, probably in tension Decision: describe our response to these forces Status: proposed, accepted, deprecated or superseded Consequences: describe the resulting context, after applying the decision

— Michael Nygard, Documenting Architecture Decisions, Nov 2011

Decision Template

slide-7
SLIDE 7

Architecturally Significant Decisions!

@RuthMalan #SATURN17

slide-8
SLIDE 8
slide-9
SLIDE 9

@RuthMalan #SATURN17

“If you think good architecture is expensive, try bad architecture” – Brian Foote

slide-10
SLIDE 10

Big Ball of Mud Architecture

“Big Ball of Mud”, Brian Foote and Joseph Yoder http://www.laputan.org/mud/

@RuthMalan #SATURN17

slide-11
SLIDE 11

Big Ball of Mud Architecture

“You reach for the banana, and get the entire gorilla” – Michael Stahl

slide-12
SLIDE 12

Actually, it looks more like this

slide-13
SLIDE 13
  • Isolate impact of change
  • Isolate arenas of uncertainty and experiment
  • Increase reversibility, replaceability,
  • Increase responsiveness/adaptability
  • Reduce complexity

– Divide and conquer – we have to keep it crisp, disentangled, and simple if we refuse to be crushed by the complexities of

  • ur own making...” – Dijkstra

Modular Structure(s): ↓ Cost of Change!

slide-14
SLIDE 14

’03

slide-15
SLIDE 15

’92

slide-16
SLIDE 16

@RuthMalan #SATURN17

Software architecture refers to the high level structures of a software system [..] Each structure comprises software elements, relations among them, and properties of both elements and relations. — wikipedia/Clements et al

slide-17
SLIDE 17

“Everything that needs to be said has already been said. But since no

  • ne was listening, everything must

be said again. — André Gide

@RuthMalan #SATURN17

slide-18
SLIDE 18
slide-19
SLIDE 19
slide-20
SLIDE 20

We design to get more what we want!

slide-21
SLIDE 21

So about those elements and relations

and those (much maligned) box and line diagrams…

How do we design (Better) Boxes?

slide-22
SLIDE 22

“I go along wit h t he nat ural makeup” …

“when I come to the tricky parts, I slow down”

— Chuang Tzu: “The Dexterous Butcher”

@RuthMalan #SATURN17

Finding the (Natural) Shape

slide-23
SLIDE 23

— Ambrose Bierce, Devil’s Dictionary

ABATIS, n. [1.] Rubbish in front of a fort, to prevent the rubbish outside from molesting the rubbish inside.

Image: Engineering and the Mind’s Eye

“Design things to make their performance as insensitive to the unknown or uncontrollable external influence as practical.” — Eb Rechtin

slide-24
SLIDE 24

Image: alistair.cockburn.us/Hexagonal+architecture

Separation of Concerns Hexagonal Architecture

Ports and adapters

slide-25
SLIDE 25

As programmers we deal with abstractions all the time and we have to invent them in order to solve our problems — Michael Feathers

Abstractions

slide-26
SLIDE 26

Image: martinfowler.com/bliki/BoundedContext.html

Bounded Contexts in DDD Separation of Concerns

slide-27
SLIDE 27

Components and Responsibilities

27

@RuthMalan #SATURN17

slide-28
SLIDE 28

Factor and Refactor

“The responsibility of architecture is the architecture of responsibility.” — Jan van Til/Tom Graves

@RuthMalan #SATURN17

Does this component have a cohesive identity or purpose — a single responsibility at the level of abstraction of the abstraction?

slide-29
SLIDE 29

The architect’s SCARS:

  • Separation of Concerns
  • crisp and resilient

Abstractions

  • balanced distribution of

Responsibilities

  • strive to Simplify

— Grady Booch

Booch #SATURN16

Fundamentals that remain fundamental

slide-30
SLIDE 30

“disorder is easier and more permanent than order, which is difficult and temporary” — Jeremy Campbell

Separate Concerns — and keep separate

slide-31
SLIDE 31

Boundaries: Conway’s Law

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” —Melvyn Conway (in 1968!)

Keep Concerns Separate

slide-32
SLIDE 32
slide-33
SLIDE 33

“The defining properties

  • f any system, are

properties of the whole, which none of the parts

  • have. If you take the

system apart, it loses its essential properties” — Russell Ackoff

slide-34
SLIDE 34

trying to be an airplane” — Wim Roelandts

slide-35
SLIDE 35

Minimalist Architecture

35

Decisions that must be made from a system perspective

  • system outcomes
  • across boundaries

Dana Bredemeyer

slide-36
SLIDE 36

Structure and Behavior

Posit structure Explore behavior Revise structure

slide-37
SLIDE 37

Structure and Behavior

Posit structure Explore behavior Revise structure

How will this work? What is it made (up) of? How does this contribute to/ inhibit desired properties?

slide-38
SLIDE 38

Remember! Responsibilities!

38

Posit responsibilities Refine as explore behavior and different views Patterns Metaphors Experience Existing stuff

slide-39
SLIDE 39

“at least they’re looking at it”

  • sketch prototype
  • try alternatives on

the cheap

  • “mob modeling”
  • “test drive”

@RuthMalan #SATURN17

Visual models

slide-40
SLIDE 40

“Architects must have self-repairing egos”

— Dana Bredemeyer

@RuthMalan #SATURN17

slide-41
SLIDE 41

“A change of perspective is worth 80 IQ points” — Alan Kay

slide-42
SLIDE 42

“You don't understand something until you understand it more than one way” — Marvin Minsky

Image: en.wikipedia.org/wiki/Marvin_Minsky#/media/File:Marvin_Minsky_at_OLPC b.jpg

slide-43
SLIDE 43

“If you haven’t thought of three possibilities, you haven’t thought enough.”

— Jerry Weinberg

Rule of Three

slide-44
SLIDE 44

What ARCHITECTURE STRUCTURE Logical Conceptual Execution

slide-45
SLIDE 45

Design across

“Design is not just what it looks like and feels like. Design is how it works.” — Steve Jobs

slide-46
SLIDE 46

What ARCHITECTURE STRUCTURE interfaces elements and relationships How BEHAVIOR Logical Conceptual

slide-47
SLIDE 47

What (system view) How What (user view) SYSTEM ARCHITECTURE STRUCTURAL BEHAVIORAL CAPABILITIES CONTEXT Why v v How well FUNCTIONAL PROPERTIES architecturally significant mechanisms “Design quality is not a property of the code. It's a joint property of the code and the context in which it exists.” – Sarah Mei

slide-48
SLIDE 48

Architecturally significant? The demands (forces, properties, …)

  • n the system that are challenging,

push the limits, require design attention

slide-49
SLIDE 49

Source: Martin Fowler http://martinfowler.com/articles/lmax.html

LMAX Disruptor Mechanism

Challenges: A trading platform needs very low latency - trades have to be processed quickly because the market is moving rapidly. A retail platform adds complexity because it has to do this for lots of people.

slide-50
SLIDE 50

“The Federalist Papers are arguments that support different parts of the design

  • f the Constitution.”

– Alan Kay, 1995

slide-51
SLIDE 51

Federalist 51

addresses

  • separation of powers
  • checks and balances
slide-52
SLIDE 52

52

slide-53
SLIDE 53

53

slide-54
SLIDE 54

Take note(s)!

Leonardo da Vinci’s notebooks

Develop and share theory

  • of operation (interactions,

resolution of forces,

  • utcomes)
  • of relation of structure to

function/properties

slide-55
SLIDE 55

55

System Design Intention (what should be) System Design Reflection (what is)

slide-56
SLIDE 56

Static structure

slide-57
SLIDE 57

from Pollock

slide-58
SLIDE 58

to Kandinsky?

slide-59
SLIDE 59

Your Code as a Crime Scene

http://www.adamtornhill.com

slide-60
SLIDE 60

Your Code as a Crime Scene

http://www.adamtornhill.com

slide-61
SLIDE 61

61

System Design Intention (what should be) System Design Reflection (what is)

slide-62
SLIDE 62

Context System-in-Context (use, dev, ops) System (Ecosystem) Architecture

structure and mechanisms

“Requirements”

design of system capabilities

Strategy

ecosystem interventions

"Always design a thing by considering it in its next larger context" —Eliel Saarinen

slide-63
SLIDE 63
slide-64
SLIDE 64

Architecturally Significant — also:

Structurally significant

  • Organizing structure
  • Architecturally significant

mechanisms

  • Structural integrity and sustainability

Strategically significant

  • game shapers and game changers

What is make or break? What impacts how we compete?

"I wasn't the one pushing things in the wrong direction, but I should have been the one to stop it." — Chad Fowler

slide-65
SLIDE 65

Just enough

  • Not “big design” that we just spread out over time
  • using judgment, assessing what’s architecturally significant
  • where do we need “cognitive assist”
  • to “see,” to draw out (assumptions, relationships,…)
  • try out alternatives cheaply to decide where to run code experiments

to test out ideas

  • where do we need to work together
  • involve others, convey and persuade, inform and coach by showing

how we resolve interplay of forces and context to create solutions, …

slide-66
SLIDE 66

SATURN 2017

Visual Architecting

@RuthMalan Bredemeyer Consulting