Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Software Architecture Clues

1 221 vues

Publié le

Clues (which may range from hints, heuristics, tips, ... patterns, ... checklists, ...) for architects, creating good, right successful systems (and the architectures that enable them).

Publié dans : Logiciels
  • Soyez le premier à commenter

Software Architecture Clues

  1. 1. The architect's clue bucket @DanaBredemeyer @RuthMalan
  2. 2. “Architecture represents the significant design decisions that shape a system” — Grady Booch Architecture Decisions
  3. 3. “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 Decisions Image source: wikipedia
  4. 4. “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. We can call these Type 1 decisions.” — Jeff Bezos, letter to shareholders, 2015 Irreversible Decisions
  5. 5. “But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 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
  6. 6. 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 • System outcomes • cross-cutting concerns • require organizational will • First/early/before/not yet • create “ground under the feet” • reversible/irreversible
  7. 7. Super hella important decisions of great consequence to • Structural integrity • Design integrity • Strategic impact Architecture Decisions Need clues – stat!
  8. 8. Kinds of clues: • tips, hints, heuristics, … principles, laws • patterns, designs, … • analogies, … And clues on getting clues What Do We Want? Clues! Image source: Matthew Jones
  9. 9. Good, right, successful Architecture Good: technically sound Right: meets stakeholder needs Successful: delivers value What Do We Want?
  10. 10. Good: technically sound Right: meets stakeholder needs Successful: delivers value Architecture What Do We Want? Clues!
  11. 11. The architect’s SCARS: • Separation of Concerns • crisp and resilient Abstractions • balanced distribution of Responsibilities • strive to Simplify — Grady Booch Good: Architecture
  12. 12. “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
  13. 13. ABATIS, n. [1.] Rubbish in front of a fort, to prevent the rubbish outside from molesting the rubbish inside. — Ambrose Bierce, Devil’s Dictionary 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 SCARS: Separation of Concerns
  14. 14. Image: alistair.cockburn.us/Hexagonal+architecture SCARS: Separation of Concerns Hexagonal Architecture Ports and adapters
  15. 15. Image: martinfowler.com/bliki/BoundedContext.html Bounded Contexts in DDD SCARS: Separation of Concerns
  16. 16. SCARS: crisp Abstractions "The responsibility of architecture is the architecture of responsibility.“ — Tom Graves (as paraphrased by Jan van Til)
  17. 17. 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
  18. 18. Single Responsibility at the level of abstraction of the abstraction SCARS: crisp Abstractions “The responsibility of architecture is the architecture of responsibility.” -- Jan van Til
  19. 19. SCARS: crisp Abstractions "To find the right abstraction, guess. If it exhibits the right properties, stop. "— Jessica Kerr
  20. 20. Factor and Refactor Posit responsibilities SCARS: crisp Abstractions
  21. 21. “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
  22. 22. Resilient under change SRP: each software module should have one and only one reason to change (Uncle Bob Martin) Retrospective (Feathers) Prospective (thought experiments) SCARS: resilient Abstractions
  23. 23. “disorder is easier and more permanent than order, which is difficult and temporary” — Jeremy Campbell SCARS: resilient Abstractions
  24. 24. “There was a wall. It did not look important. It was built of uncut rocks roughly mortared. An adult could look right over it, and even a child could climb it. Where it crossed the roadway, instead of having a gate it degenerated into mere geometry, a line, an idea of boundary. But the idea was real. It was important. For seven generations there had been nothing in the world more important than that wall. Like all walls it was ambiguous, two-faced. What was inside it and what was outside it depended upon which side of it you were on.” — Ursula K. Le Guin, The Dispossessed Image: welshwaller.files.wordpress.com/2013/01/llwest-and-elan-valley-017.jpg SCARS: Separation of Concerns
  25. 25. 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!) Separate, and Keep Separate
  26. 26. No “god” component SCARS: balanced distribution of Responsibilities
  27. 27. “Simplify, simplify” — H. D. Thoreau ‘One “simplify” would have sufficed’ — Ralph Waldo Emerson, in response SCARS: strive to Simplify
  28. 28. “Simplify, simplify, Simplify” “Communicate, Communicate, Communicate” — Eberhardt Rechtin SCARS: strive to Simplify
  29. 29. “disorder is easier and more permanent than order, which is difficult and temporary” — Jeremy Campbell SCARS: strive to Simplify
  30. 30. SCARS: strive to Simplify “An evolving system increases its complexity unless work is done to reduce it.” — Meir Lehman
  31. 31. SCARS: strive to Simplify “Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.” — Jamie Zawinski
  32. 32. “Do the simplest thing that could possibly work” Occam’s Razor: the simplest solution is usually the correct one YAGNI SCARS: strive to Simplify
  33. 33. Chad Fowler: “The older I get, the more I realize the biggest problem to solve in tech is to get people to stop making things harder than they have to be.” Michael Feathers: “It's not that easy.” SCARS: strive to Simplify
  34. 34. SCARS: strive to Simplify
  35. 35. focusing is saying “no”— Steve Jobs SCARS: strive to Simplify
  36. 36. “old code doesn’t die; you have to kill it” — Grady Booch SCARS: strive to Simplify
  37. 37. StranglerApplication: “An alternative route is to gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.” — Martin Fowler SCARS: strive to Simplify
  38. 38. The architect’s SCARS: • Separation of Concerns • crisp and resilient Abstractions • balanced distribution of Responsibilities • strive to Simplify — Grady Booch Good: Architecture
  39. 39. Good: Architecture 💔 “You reach for the banana, and get the entire gorilla” – Michael Stahl
  40. 40. Image: from Undoing the harm of layers by Bjørn Bjartnes Good: Architecture 💔 Actually, it looks more like this
  41. 41. “we have to keep it crisp, disentangled, and simple if we refuse to be crushed by the complexities of our own making...” — Dijkstra SCARS: Crisp, disentangled
  42. 42. “Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change” — Grady Booch Architecture Decisions
  43. 43. • Pay more attention to consequential irreversible decisions • Make more decisions reversible
  44. 44. Decoupled modular structure  Reversible • Isolate impact of change • Isolate arenas of uncertainty and experiment • Increase replaceability • Increase responsiveness/adaptability • Reduce complexity • separate concerns, reveal intent: increase comprehensibility
  45. 45. Decouple  Reversible • Event driven • flow control is moved from sender to receiver
  46. 46. “If you're good at course correcting, being wrong may be less costly than you think” — Jeff Bezos Image source: wikipedia  Reversible
  47. 47. Small changes, quick feedback, easy to undo  Reversible • Development servers. Each engineer has their own copy of the entire site. Engineers can make a change, see the consequences, and reverse the change in seconds without affecting anyone else. • Code review. Engineers can propose a change, get feedback, and improve or abandon it in minutes or hours, all before affecting any people using Facebook. • Internal usage. Engineers can make a change, get feedback from thousands of employees using the change, and roll it back in an hour. • Staged rollout. We can begin deploying a change to a billion people and, if the metrics tank, take it back before problems affect most people using Facebook. • Dynamic configuration. If an engineer has planned for it in the code, we can turn off an offending feature in production in seconds. Alternatively, we can dial features up and down in tiny increments (i.e. only 0.1% of people see the feature) to discover and avoid non-linear effects https://m.facebook.com/notes/kent-beck/taming-complexity-with-reversibility/
  48. 48. “Architecture represents the significant design decisions that shape a system” — Grady Booch Architecture Decisions
  49. 49. “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 Good: Shape a System
  50. 50. Essence of systems is: • Relationships • Interfaces • Form • Fit • Function — Eberhardt Rechtin Systems
  51. 51. Essence of systems is: • Relationships • Interfaces “Relationships among the elements are what give systems their added value” “The greatest leverage in architecting is at the interfaces” “It is inadequate to architect up to the boundaries or interfaces of a system; one must architect across them.” – Robert Spinrad, quoted by Eb Rechtin Systems: Interfaces architect across
  52. 52. “A lock is a lock because of the key [--] when we design abstractions for lock, we are also [in parallel] designing abstractions for key” — Shripad Agashe Systems: Interfaces
  53. 53. “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
  54. 54. Posit structure Explore behavior Revise structure Explore — with sketches “Design is not just what it looks like and feels like. Design is how it works.” — Steve Jobs Systems: How it Works
  55. 55. Essence of architecture is: • Structuring • Simplification • Compromise • Balance — Eberhardt Rechtin Systems
  56. 56. “dependencies are a tradeoff between the cost of maintaining the code yourself (and implementing it) & the cost of the risk of breakage” — Kent Beck Systems: Tradeoffs/Compromise
  57. 57. Good: technically sound Right: meets stakeholder needs Successful: delivers value Architecture What Do We Want?
  58. 58. "Always design a thing by considering it in its next larger context" -- Eliel Saarinen Context System-in-Context (use, dev, ops) System (Ecosystem) Architecture structure and mechanisms “Requirements” design of system capabilities Strategy ecosystem interventions Right: Fit to Context
  59. 59. Architecture Decisions 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 Right: Fit to Context
  60. 60. Context: Forces Source: Grady Booch
  61. 61. 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
  62. 62. Getting Clues: Look/Change PoV “A change of perspective is worth 80 IQ points” — Alan Kay
  63. 63. Getting Clues: Look/Change PoV “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
  64. 64. “If you haven’t thought of three possibilities, you haven’t thought enough.” — Jerry Weinberg Rule of Three Getting Clues: Look/Change PoV
  65. 65. 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 Getting Clues: Look/Change PoV Image source: Donella Meadows Institute
  66. 66. Good: technically sound Right: meets stakeholder needs Successful: delivers value Architecture What Do We Want?
  67. 67. What does it take to be successful?
  68. 68. An Architecture Story Signing of the Constitution (painting by Louis S. Glanzman)
  69. 69. Architecture Story The Articles of Confederation Created 1777 Ratified 1781 Image source: wikipedia
  70. 70. The Virginia Plan Image: ourdocuments.gov Architecture Story
  71. 71. The Constitution of the United States Architecture Story
  72. 72. Architecture Story “I confess that there are several parts of this constitution which I do not at present approve, but I am not sure I shall never approve them: For having lived long, I have experienced many instances of being obliged by better information, or fuller consideration, to change opinions even on important subjects, which I once thought right, but found to be otherwise. It is therefore that the older I grow, the more apt I am to doubt my own judgment, and to pay more respect to the judgment of others.” — Benjamin Franklin
  73. 73. “it seems to have been reserved to the people of this country, [..], to decide the important question, whether societies of men are really capable or not, of establishing good government from reflection and choice, or whether they are forever destined to depend, for their political constitutions, on accident and force.” Federalist No.1 Architecture Story
  74. 74. The Federalist Papers, No. 51 addresses • checks and balances • separation of powers Architecture Story
  75. 75. 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 be successful
  76. 76. Ask • What does the code need? • What does the system need • What does the ecosystem need? to be successful “Systems develop goals the minute they come into being” — John Gall
  77. 77. What (system view) HowWhat (user view) SYSTEM ARCHITECTURE STRUCTURALBEHAVIORAL CAPABILITIESCONTEXT Why How well FUNCTIONALPROPERTIES good?right?successful? to be successful
  78. 78. The Clue-Space: More than Technical Personal Organizational Technical Strategic “Architecture is a way of thinking that is inescapably concerned with everything” — Dana Bredemeyer
  79. 79. Where to Go for More Clues Personal Organizational Technical Strategic Strategic Effectiveness • Strategic context and situational awareness • Mapping, ecosystems, value networks and differentiation • Technology radars, capability evolution and trends • Operating models • How we create value • How we make money(/survive)
  80. 80. Strategy: Why go there? Personal Organizational Technical Strategic • You’re leading; where to? • Inform/influence business direction, given technology capabilities and challenges • Shape technical direction, to enable business direction • Architecture decisions • Understand shaping forces, differentiating value/outcomes • Achieve fit to context / purpose
  81. 81. Where to Go for More Clues Personal Organizational Technical Strategic Organizational Effectiveness • Leadership and social dynamics • Building relationships, trust and teams • Working across the organization • Persuasion and influence; negotiation, disagreement • Decision making, judgment, effects of groups • …
  82. 82. Where to Go for More Clues Personal Organizational Technical Strategic Personal Effectiveness • How we work: cognition (4Es), .. • Empathy and design imagination • Cognitive amplifiers, fallibilities and biases • Perception and meaning making • Opportunity discovery; problem solving and problem framing • …
  83. 83. More Clues @RuthMalan @DanaBredemeyer Web: bredemeyer.com Personal Organizational Technical Strategic
  84. 84. More Clues Personal Organizational Technical Strategic Software Architecture Workshop November 12-15, 2018 Chicago-Schaumburg, IL More: bredemeyer.com

×