Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Visual Design and Architecture

1,257 views

Published on

Part i: Introduction and Context setting around Design in Agile; Decisions and Constraints; Decisions and Trade-offs; Getting to know the domains (contexts of use, development and operations, value partners and others); Design and expressions of system value, capabilities and properties
Part ii: Why Visual Matters to Design, some exemplars we can learn from, and lessons we can draw about why we need to bring visual models back into our design toolkit (some already do, obviously, but why more of us need to)
Part iii: Architectural design -- using visual models to look inside the system, and design the organizing structure, and how it works.
Annotated slides here: https://www.ruthmalan.com/Journal/2019/201902OReillySAConPresentation.htm

Published in: Software

Visual Design and Architecture

  1. 1. Visual Design and Architecture Ruth Malan
  2. 2. Code is Design #OReillySACon
  3. 3. Code as Design 1992 “software [..] design is the source code listings” “programming is about designing software” – Jack Reeves https://www.developerdotstar.com/
  4. 4. Code as Design https://www.developerdotstar.com/ 2005 "In software engineering, we desperately need good design at all levels. [..] Designers should use anything that helps.”
  5. 5. Code as Design https://www.developerdotstar.com/ 2005
  6. 6. @RuthMalan #OReillySACon “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Agile Principles #OReillySACon Source: https://agilemanifesto.org/principles.html
  7. 7. @RuthMalan #OReillySACon Faces of design: • Design of working software: What the system is (requirements: capabilities and properties) • Design of code: How it is built and how it works (architecture and design: structure and dynamics) Design #OReillySACon developer facinguser facing operations facing
  8. 8. Agile Design • users respond to working software with needs/ideas; (co-)evolve to better design • TDD (Test Driven Development/Design) and refactor to better code design Iterative and incremental • get frequent feedback • respond and adapt Agile Design developer facinguser facing codesoftware
  9. 9. the Code is the Design #OReillySACon
  10. 10. @RuthMalan #OReillySACon “The best architectures, requirements, and designs emerge from self-organizing teams.” Agile Principles #OReillySACon Source: https://agilemanifesto.org/principles.html
  11. 11. “Good design doesn’t ‘emerge’ like a welcome ray of sunshine on a cloudy day. —Erik Dietrich Erik Dietrich, Designs Don’t Emerge http://www.daedtech.com/designs-dont-emerge/ Good Design
  12. 12. “It comes coughing, sputtering, screaming and grunting from the mud, like a drowning man being pulled from quicksand, and the effort of dragging it laboriously out leaves you exhausted.” —Erik Dietrich http://www.daedtech.com/designs-dont-emerge/ Art by Amanda Muledy (@EEKitsabug) Good Design
  13. 13. Code is Design #OReillySACon
  14. 14. @RuthMalan #OReillySACon All good. Question is, can we do better? If so, how? What is missing if all we have is code (with tests, obviously)? Or what is code less good at, in terms of helping us do, or express, design? As we do design, can we give ourselves more of a cognitive assist and collective intelligence boost? Agile Design #OReillySACon
  15. 15. @RuthMalan #OReillySACon Alternately put, the code is sufficient design expression for a compiler to build it, but is it sufficient for humans to design and evolve complex systems? We have a lot of “undocumented” code which is abundant existence proof of something; but can we do better? Agile Design #OReillySACon
  16. 16. “The engineer, and more generally the designer, is concerned with how things ought to be - how they ought to be in order to attain goals, and to function.” — Herbert Simon What is Design? What are we talking about, when we talk about design?
  17. 17. “Architecture represents the significant design decisions that shape a system” — Grady Booch What is Architecture?
  18. 18. “Some decisions are consequential and irreversible or nearly irreversible [..] these decisions must be made methodically, carefully, slowly, with great deliberation and consultation” — Jeff Bezos, letter to shareholders, 2015 Irreversible Decisions Image source: wikipedia
  19. 19. “If you walk through and don’t like what you see on the other side, you can’t get back to where you were before.” — Jeff Bezos, letter to shareholders, 2015 Irreversible Decisions
  20. 20. “But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal [reversible] decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through.” — Jeff Bezos, letter to shareholders, 2015 Reversible Decisions
  21. 21. Architecture Decisions “Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.” — Grady Booch
  22. 22. Architecture Decisions • Significant is measured by cost of change • Decisions to reduce cost of change (make reversible) • Decisions that have high cost of change (irreversible)
  23. 23. Architecture Decisions “Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.” – Eoin Woods
  24. 24. Architecturally significant? • Cost of change • Strategic • Address challenges • create systems with desired capabilities and properties • under forces and constraints • that are demanding, push the limits, require design attention Architecture Decisions make or break } “deliberate deliberately” — Dawn Ahukanna
  25. 25. Questions about whether design is necessary or affordable are quite beside the point: design is inevitable. The alternative to good design is bad design, not no design at all. — Douglas Martin The No Decision Decision
  26. 26. Decisions Constrain “Constraints alter the probability distribution of the available alternatives. They make a system diverge from chance, randomness, or equiprobability” ‘Limiting or closing off alternatives is the most common understanding of the term “constraint.”’ — Alicia Juarrero Photo by Will Evans, LeanUX 2015
  27. 27. Constraints Enable But if all constraints restricted a thing's degrees of freedom in this way, organisms (whether phylogenetically or developmentally) would progressively do less and less.’ — Alicia Juarrero
  28. 28. Constraints Enable “constraints not only reduce the alternatives — they also create alternatives. Constraints, that is, can also create properties which a component exhibits in virtue of its embeddedness in a system, properties it would otherwise not have.” — Alicia Juarrero “Causality as Contraint”
  29. 29. “We put ground under our feet, by deciding” Architecture Decisions — Dana Bredemeyer Probe and test design ideas as quickly and cheaply as we can (while still reversible)
  30. 30. @RuthMalan #OReillySACon All good. Question is, can we do better? If so, how? What is missing if all we have is code (with tests, obviously)? Or what is code less good at, in terms of helping us do, or express, design? As we do design, can we give ourselves more of a cognitive and collective intelligence boost? Just Enough Architecture #OReillySACon
  31. 31. @RuthMalan #OReillySACon Title: short noun phrase Context: desired outcomes and the forces at play (probably in tension) Decision: describes our response to these forces Status: proposed, accepted, deprecated or superseded Consequences: describes the resulting context, after applying the decision — Michael Nygard, Documenting Architecture Decisions, Nov 2011 Architecture Decisions #OReillySACon @mtnygard
  32. 32. @RuthMalan #OReillySACon Title: short noun phrase Context: desired outcomes and the forces at play (probably in tension) Decision: statement of the decision Status: proposed, accepted, deprecated or superseded Consequences: describes the resulting context, after applying the decision — Michael Nygard, Documenting Architecture Decisions, Nov 2011 Architecture Decisions #OReillySACon @mtnygard
  33. 33. @RuthMalan #OReillySACon Microservices: Tradeoffs #OReillySACon “Microservices: gain scalability and fault tolerance at the price of additional complexity in managing a distributed system” This! This right here! This is architectural thinking. Perceiving where there are tradeoffs. It takes experience, but also a system perspective. Noticing that what happens in one place, can have non-local or differently timed consequences and implications.
  34. 34. Mattias Petter Johansson, Quora
  35. 35. Mattias Petter Johansson, Quora
  36. 36. @RuthMalan #OReillySACon "The value of every decision we make depends on the context in which we make it. In The Lord of the Rings, Frodo’s journey to destroy the ring is meaningful inside the context of Middle Earth. Otherwise, he’s a short, hairy guy with apocalyptic hallucinations." – Diana Montalion Decisions in Context #OReillySACon
  37. 37. Context: Factors Image source: Sarah Mei on Twitter “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
  38. 38. @RuthMalan #OReillySACon For me, “engineer” means knowing that all decisions are tradeoffs. It means considering both upsides & downsides of each technical choice, and doing so with explicit consideration of the larger system context. – Sarah Mei Decisions: Tradeoffs #OReillySACon @sarahmei
  39. 39. When things get heated, spot the differences in (perceived) context and the tradeoffs being weighed (or ignored)! Decisions: Tradeoffs Image by Dave Grey in “Liminal thinking The pyramid of belief”
  40. 40. @RuthMalan #OReillySACon Title: short noun phrase Context: desired outcomes and the forces at play (probably in tension) Decision: describes our response to these forces Status: proposed, accepted, deprecated or superseded Consequences: describes the resulting context, after applying the decision — Michael Nygard, Documenting Architecture Decisions, Nov 2011 Architecture Decisions #OReillySACon @mtnygard
  41. 41. Architecture Decisions Making Decisions Conveying Decisions How to do this better
  42. 42. @RuthMalan #OReillySACon How Do We Start? • To make a decision, we need to have a (good enough) conception of – Desired outcome(s) – Forces and constraints – Consequences and side-effects
  43. 43. @RuthMalan #OReillySACon How Do We Start? To make a decision, we need to have a (good enough) conception of • Desired outcome(s) • Forces and constraints Arising in context of • development • operations • use • value network [as relevant]
  44. 44. @RuthMalan #OReillySACon Title: short noun phrase Context: desired outcomes and the forces at play (probably in tension) Decision: describes our response to these forces Status: proposed, accepted, deprecated or superseded Consequences: describes the resulting context, after applying the decision Architecture Decisions “formulating the problem is the problem” – Horst Rittel #OReillySACon
  45. 45. As Theory Building
  46. 46. @RuthMalan #OReillySACon Design in Context #OReillySACon “Always design a thing by considering it in its next larger context.” — Eliel Saarinen
  47. 47. in its next larger context Context System-in-Context (use, dev, ops) System (Ecosystem) Strategy Ecosystem interventions Requirements Design of system capabilities Architecture Structure and mechanisms
  48. 48. Ask • [not just] What do users need? • [but also] What do developers and testing need? • [and] What does operations need? • [and] What do others in the value network need? To Develop Theory of “the Problem”
  49. 49. Context: the Landscape Context Map, David Sibbet, Visual Meetings
  50. 50. Context: the Landscape
  51. 51. Context: the Landscape
  52. 52. Context: the Landscape
  53. 53. Context: the Landscape
  54. 54. Context: the Landscape CaringCircles Competitive Landscape
  55. 55. Context: Systems of Systems “sketchprototype” with Rich Pictures Show • structure • value flows and transformations • concerns CaringCircles Rich Picture
  56. 56. Who’s Impacted? Empathy Imaginative entry into the experience of: • Users of various kinds • Developers and testers • Operations • Senior management • Support/call center • Value chain partners
  57. 57. Who’s Impacted? Goals Stakeholder Profile • Stakeholder • Responsibilities • Business/Personal Goals • System Goals • Value Proposition Stakeholder: Business Owner Responsibilities: • Funding model • Securing user data • Hiring good talent
  58. 58. Other Ecosystem Views Business Model Canvas By Alexander Osterwalder and Yves Pigneur Wardley Maps By Simon Wardley
  59. 59. System in Context Customer Journey Maps Event Storming Alberto Brandolini
  60. 60. Exploring System Design Maps, maps and more maps • Impact maps: goal, who can impact goal (+/-) and how can they obstruct/help, what can we deliver to support impact/goal • Assumptions maps: desirable: do they want this; feasible: can we do this; viable: should we do this • User story maps impactmapping.org David Bland agilebuddha.com
  61. 61. What’s Going on Here?? Product Owners and User Experience Designers, step aside — Ruth’s bringing in the architects! Not that! Partner well (but just enough), to bring technology capabilities to design table, and to build up “theory of the problem” to inform design choices/decisions
  62. 62. System on a Page Also! Designing the System: • Significant system capabilities CaringCircles Use Case Diagram Use cases Facilitate caring circle • Enroll members • Inform members Characterize requests View and adopt requests Make offers
  63. 63. System in Context Manage tribe membership Manage user profile View content Assemble content Techtribes Use Case Diagram (UML) Techtribes Context Diagram (Simon Brown’s C4)
  64. 64. Architectural design is system design. System design is contextual design — it is inherently about boundaries (what’s in, what’s out, what spans, what moves between). It reshapes what is outside, just as it shapes what is inside. Contextual Design
  65. 65. System Design “The defining properties of 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
  66. 66. Context: Properties “Quality doesn't happen by magic.” – Rebecca Wirfs-Brock
  67. 67. Context: Properties Quality Attributes Kiviat: Michael Keeling
  68. 68. Context: Properties Landing Zones: Rebecca Wirfs-Brock
  69. 69. System Design: Forces Source: Grady Booch
  70. 70. Just Enough Just in Time “I always say to myself, what is the most important thing we can think about at this extraordinary moment.” – Bucky Fuller
  71. 71. Iterative Design Let go of the need to be “done” Test, iterate and refactor applies to models too Source: wikipedia.org/wiki/OODA_loop OODA is a loop!
  72. 72. @RuthMalan #OReillySACon Recall our question: Can we do better than our already good Agile practices with their focus on code (TDD, refactoring, frequent feedback, …)? If so, how? What is missing from code, or what is code less good at, in terms of design? • Big picture • Structures and relationships; Interactions • Assumptions • Alternatives Agile Design #OReillySACon
  73. 73. @RuthMalan #OReillySACon Visual: Drawing on the Walls • Chauvet Cave • film "Cave of Forgotten Dreams" – 30,000–33,000 years ago • Chauvet Cave Art – only guess at their purpose, meaning – did serve to record Image: wikimedia commons
  74. 74. @RuthMalan #OReillySACon Visual: Drawing on the Walls Image: from film “Hidden Figures” Source: http://daily.gatech.edu • Engineering • the film “Hidden Figures” • Drawing on the walls – To think (together) – To illustrate, communicate
  75. 75. Visual: Drawing in notebooks Leonardo Da Vinci’s notebooks: used sketches to • observe (more attentively) • study, think, reason, to puzzle things out • understand
  76. 76. Visual Notebooks Sketching • To record – to think longer, harder – to show, to teach • To invent, to design, to combine, to make (new) connections • To test ideas – thought experiments Leonardo Da Vinci Notebooks
  77. 77. Constitution of the United States: the architecture of US government Architecture Document
  78. 78. Federalist papers • Arguments describing and motivating mechanisms of government architecture Federalist Papers, No. 51 addresses • checks and balances • separation of powers White Paper
  79. 79. Technical Memo 1995
  80. 80. Visual: Annotated Sketches
  81. 81. @RuthMalan #OReillySACon Visual “The primary use for diagrams and documentation is communication and learning” — Simon Brown @simonbrown
  82. 82. @RuthMalan #OReillySACon Visual Design The primary use for diagrams in design is better design • the act: doing design • the outcome: expressing design
  83. 83. @RuthMalan #OReillySACon Visual Image: theatlantic.com “Does a Spider Use Its Web Like You Use Your Smartphone?” • Cognition – extended into the world • Spider webs – we use the world to think
  84. 84. @RuthMalan #OReillySACon Source: Rudolf Arnheim • Consider the following problem – One morning, exactly at 8 A.M., a monk began to climb a tall mountain. The narrow path, no more than a foot or two wide, spiraled around the mountain to a glittering temple at the summit. The monk ascended the path at varying rates of speed, stopping many times along the way to rest and to eat the dried fruit he carried with him. He reached the temple precisely at 8 P.M. The next day, he began his journey back along the same path, starting at 8A.M. and again walking at varying speeds with many pauses along the way. He reached the bottom at precisely 8 P.M. – I assert that there is at least one spot along the path the monk occupied at precisely the same time of day on both trips. – Is my assertion true? How do you decide?
  85. 85. Visual Thinking Source: Rudolf Arnheim, Visual Thinking, 1969
  86. 86. Visual • To abstract • To reason • To show • To test • To document • To transform To address wicked problems: To deal with complexity - buffer overflow! To work together/collaborate - shared thought-space To communicate - explain, defend, preserve
  87. 87. We value “people and interactions” – collaboration We value convening collaboration, convening the creation of more shared mental models, more shared context and system understanding. Conveying is important – too. We convene to convey. And convey to convene. Visual design is a crucible for conversation. Visual: to Convene and Convey
  88. 88. System Design “A system is an interconnected set of elements that is coherently organized in a way that achieves something” -- Donella Meadows
  89. 89. 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
  90. 90. @RuthMalan #OReillySACon Not Agile? #OReillySACon • Rigid: not able to be changed or adapted • entangled • Inertia: the resistance of the object to any change in its motion, including a change in direction
  91. 91. Good: Architecture 💔 “You reach for the banana, and get the entire gorilla” – Michael Stahl Not
  92. 92. “we have to keep it crisp, disentangled, and simple if we refuse to be crushed by the complexities of our own making...” — Dijkstra Good: Crisp, disentangled
  93. 93. Decoupled modular structure Good: Reversible • Isolate impact of change • Isolate arenas of uncertainty and experiment • Increase replaceability • Increase responsiveness/adaptability • Manage complexity • separate concerns, reveal intent: increase comprehensibility
  94. 94. The architect’s SCARS: • Separation of Concerns • crisp and resilient Abstractions • balanced distribution of Responsibilities • strive to Simplify — Grady Booch Good: Architecture
  95. 95. “I go along with the natural makeup”… “when I come to the tricky parts, I slow down” — Chuang Tzu: “The Dexterous Butcher” SCARS: Separation of Concerns
  96. 96. As programmers we deal with abstractions all the time and we have to invent them in order to solve our problems — Michael Feathers SCARS: Abstractions @mfeathers
  97. 97. SCARS: crisp Abstractions "To find the right abstraction, guess. If it exhibits the right properties, stop. "— Jessica Kerr @jessitron
  98. 98. Recall: Capabilities CaringCircles Use Case Diagram Use cases Facilitate caring circle • Enroll members • Inform members Characterize requests View and adopt requests Make offers View and claim offers Fulfill requests
  99. 99. Components: Guess
  100. 100. Components: Guess Requestor Service CaringCircle Service Requests Service Offers Service Matching Service • Setup requestor account • Inform and update requestor • Setup caring circle • Enroll members • Inform members • Enter offers • Update offers • View offers • Claim offers • View offers status • Enter requests • Update requests • View requests • Claim requests • View requests status • Match requests and offers
  101. 101. Recall: Capabilities CaringCircles Use Case Diagram Use cases Facilitate caring circle • Enroll members • Inform members Characterize requests View and adopt requests Make offers View and claim offers Fulfil requests
  102. 102. SCARS: crisp Abstractions “Things that are cohesive, [..] naturally stick to each other because they are of like kind, or because they fit so well together.[..] the pieces all seem to be related, they seem to belong together, and it would feel somewhat unnatural (it would result in tight coupling!) to pull them apart” — Glenn Vanderburg
  103. 103. Components: Guess Requestor Service CaringCircle Service Requests Service Offers Service Matching Service • Setup requestor account • Inform and update requestor • Setup caring circle • Enroll members • Inform members • Entry offers • Update offers • View offers • Claim offers • View offers status • Enter requests • Update requests • View requests • Claim requests • View requests status • Match requests and offers
  104. 104. Components: Next Guess Requestor Service CaringCircle Service Requests Service Offers Service Matching Service • Setup requestor account • Inform and update requestor • Setup caring circle • Enroll members • Inform members • Enter offers • Update offers • View offers status • Enter requests • Update requests • View requests status • Match requests and offers o Manual match o Automated match Fulfilment Service
  105. 105. Factor and Refactor SCARS: crisp Abstractions “The responsibility of architecture is the architecture of responsibility.” — Jan van Til/Tom Graves Does this component have a cohesive identity or purpose — a single responsibility at the level of abstraction of the abstraction?
  106. 106. “We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.” — David Parnas SCARS: crisp and resilient Abstractions 1972
  107. 107. Recall: System Capabilities Manage tribe membership Manage user profile View content Assemble content Techtribes Use Case Diagram (UML) Techtribes Context Diagram by Simon Brown (in C4)
  108. 108. Techtribes Component Diagram by Simon Brown [in C4] SCARS: Abstractions
  109. 109. SCARS: Separation of Concerns Hexagonal Architecture Alistair Cockburn Ports and adapters
  110. 110. Design across “Design is not just what it looks like and feels like. Design is how it works.” — Steve Jobs
  111. 111. Posit structure Explore behavior Revise structure Explore — with sketches Structure and Behavior
  112. 112. What ARCHITECTURE STRUCTURE interfaces elements and relationships How BEHAVIOR Logical Conceptual
  113. 113. Structure and Behavior
  114. 114. Structure and Behavior :CustomerMgr :HotelMgr :ReservationSystem 1 makeAReservation 1.1 getCustomer 1.2 makeReservation 1.3 notifyCustomer
  115. 115. Exploring Behavior source: VisualParadigm
  116. 116. Systems: Deployment Diagram
  117. 117. “Don’t partition by slicing through regions where high rates of information exchange are required” – Eb Rechtin Systems: Interfaces Image source: Martin Fowler’s bliki
  118. 118. Iterative: Messy, Backtrack
  119. 119. 119 System Design Intention (what should be) System Design Reflection (what is)
  120. 120. “at least they’re looking at it” • sketch prototype • try alternatives on the cheap • “mob modeling” • “test drive” Visual models
  121. 121. “Architects must have self-repairing egos” — Dana Bredemeyer
  122. 122. Expose your mental models to the open air. Remember, always, that everything you know, and everything everyone knows, is only a model. Get your model out there where it can be shot at. Invite others to challenge your assumptions and add their own. Instead of becoming a champion for one possible explanation or hypothesis or model, collect as many as possible. — Donella Meadows Image source: Donella Meadows Institute Change Your Point of View
  123. 123. Change Your Point of View “A change of perspective is worth 80 IQ points” — Alan Kay
  124. 124. “You don't understand something until you understand it more than one way” — Marvin Minsky Image: wikipedia.org/wiki/Marvin_Minsky#/media/File:Marvin_Minsky_at_OLPCb.jpg Change Your Point of View
  125. 125. “If you haven’t thought of three possibilities, you haven’t thought enough.” — Jerry Weinberg Rule of Three Change Your Point of View
  126. 126. Agile Design • in models and code • visual design is also a way to test and refactor to improve Iterative and incremental • get frequent feedback • respond and adapt Agile Design: Now with Pictures developer facinguser facing codesoftware
  127. 127. @RuthMalan #OReillySACon Making It Visual Ruth Malan Web: bredemeyer.com also: ruthmalan.com Twitter: @ruthmalan

×