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 Architecting


Published on

How we think of architecture shapes what we do as architects, and what we do, shapes how we think of architecture. We will explore our conception of architecture in this dual sense, with an emphasis on visualization and visual expression of design (intention and reflection).

Presented at SATURN 2017

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website!
    Are you sure you want to  Yes  No
    Your message goes here

Visual Architecting

  1. 1. Ruth Malan Visual Architecting Ruth Malan
  2. 2. Talk Outline
  3. 3. ’92
  4. 4. ’03
  5. 5. 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
  6. 6. Architecturally Significant Decisions! @RuthMalan #SATURN17
  7. 7. @RuthMalan #SATURN17 “If you think good architecture is expensive, try bad architecture” – Brian Foote
  8. 8. Big Ball of Mud Architecture “Big Ball of Mud”, Brian Foote and Joseph Yoder @RuthMalan #SATURN17
  9. 9. Big Ball of Mud Architecture “You reach for the banana, and get the entire gorilla” – Michael Stahl
  10. 10. Actually, it looks more like this
  11. 11. • 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 our own making...” – Dijkstra Modular Structure(s):  Cost of Change!
  12. 12. ’03
  13. 13. ’92
  14. 14. @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
  15. 15. “Everything that needs to be said has already been said. But since no one was listening, everything must be said again. — André Gide @RuthMalan #SATURN17
  16. 16. We design to get more what we want!
  17. 17. So about those elements and relations and those (much maligned) box and line diagrams… How do we design (Better) Boxes?
  18. 18. “I go along with the natural makeup”… “when I come to the tricky parts, I slow down” — Chuang Tzu: “The Dexterous Butcher” @RuthMalan #SATURN17 Finding the (Natural) Shape
  19. 19. — 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
  20. 20. Image: Separation of Concerns Hexagonal Architecture Ports and adapters
  21. 21. As programmers we deal with abstractions all the time and we have to invent them in order to solve our problems — Michael Feathers Abstractions
  22. 22. Image: Bounded Contexts in DDD Separation of Concerns
  23. 23. Components and Responsibilities 27 @RuthMalan #SATURN17
  24. 24. 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?
  25. 25. The architect’s SCARS: • Separation of Concerns • crisp and resilient Abstractions • balanced distribution of Responsibilities • strive to Simplify — Grady Booch Booch #SATURN16Fundamentals that remain fundamental
  26. 26. “disorder is easier and more permanent than order, which is difficult and temporary” — Jeremy Campbell Separate Concerns — and keep separate
  27. 27. 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
  28. 28. “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
  29. 29. trying to be an airplane” — Wim Roelandts
  30. 30. Minimalist Architecture 35 Decisions that must be made from a system perspective • system outcomes • across boundaries Dana Bredemeyer
  31. 31. Structure and Behavior Posit structure Explore behavior Revise structure
  32. 32. 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?
  33. 33. Remember! Responsibilities! 38 Posit responsibilities Refine as explore behavior and different views Patterns Metaphors Experience Existing stuff
  34. 34. “at least they’re looking at it” • sketch prototype • try alternatives on the cheap • “mob modeling” • “test drive” @RuthMalan #SATURN17 Visual models
  35. 35. “Architects must have self-repairing egos” — Dana Bredemeyer @RuthMalan #SATURN17
  36. 36. “A change of perspective is worth 80 IQ points” — Alan Kay
  37. 37. “You don't understand something until you understand it more than one way” — Marvin Minsky Image: b.jpg
  38. 38. “If you haven’t thought of three possibilities, you haven’t thought enough.” — Jerry Weinberg Rule of Three
  39. 39. What ARCHITECTURE STRUCTURE Logical Conceptual Execution
  40. 40. Design across “Design is not just what it looks like and feels like. Design is how it works.” — Steve Jobs
  41. 41. What ARCHITECTURE STRUCTURE interfaces elements and relationships How BEHAVIOR Logical Conceptual
  42. 42. What (system view) HowWhat (user view) SYSTEM ARCHITECTURE STRUCTURALBEHAVIORAL CAPABILITIESCONTEXT 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
  43. 43. Architecturally significant? The demands (forces, properties, …) on the system that are challenging, push the limits, require design attention
  44. 44. Source: Martin Fowler 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.
  45. 45. “The Federalist Papers are arguments that support different parts of the design of the Constitution.” – Alan Kay, 1995
  46. 46. Federalist 51 addresses • separation of powers • checks and balances
  47. 47. 52
  48. 48. 53
  49. 49. Take note(s)! Leonardo da Vinci’s notebooks Develop and share theory • of operation (interactions, resolution of forces, outcomes) • of relation of structure to function/properties
  50. 50. 55 System Design Intention (what should be) System Design Reflection (what is)
  51. 51. Static structure
  52. 52. from Pollock
  53. 53. to Kandinsky?
  54. 54. Your Code as a Crime Scene
  55. 55. Your Code as a Crime Scene
  56. 56. 61 System Design Intention (what should be) System Design Reflection (what is)
  57. 57. 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
  58. 58. 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
  59. 59. 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, …
  60. 60. SATURN 2017 Visual Architecting @RuthMalan Bredemeyer Consulting