Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Agile Software Architecture

Agile Software Architecture

Containing a review of "Why?" software architecture exists as a discipline; a fleet discussion of Fairbanks' risk driven architecture approach; and 2 Top Techniques from Coplien & Bjørnvig's Partitioning Principles for Architecture for Agile Delivery.

Culminating in a Proposal for how an architecture can enable continuous agile delivery.

Also some Ways To Do It Wrong.

Featuring the amazing Conway's Law, and such Horrors as the 15 Layer Architecture.

Agile Software Architecture

  1. 1. http://agilenorth.org/2016-conference Chris F Carroll Agile Software Architecture
  2. 2. 2 things it might mean “agile software architecture” is? doing the architect’s job in an “agile” way? creating a software architecture to support agile development? — or —
  3. 3. agilenorth.org/2016-conference/ Chris F Carroll ✤ Software Architecture: Why & What?
 ✤ What is different about the (software quality) requirements in a business where “agility” is important?
 ✤ How do we express those priorities in architecture, design & code?
  4. 4. agilenorth.org/2016-conference/ Chris F Carroll Software Architecture : why & what?
  5. 5. the value-add of software architecture Software Architecture claims “to enable reasoning 
 about the quality attributes 
 of software systems” Why software architecture?
  6. 6. What is a Quality Attribute? What does “Reasoning about” mean? just two questions… The promise of Software Architecture
  7. 7. What is a Quality Attribute? Who defines quality? “It’s not what you do, it’s the way that you do it” affordability, availability, correctness, deployability,efficiency, evolvability, extensibility, fault-tolerance, main- tainability, modifiability, reliability, resilience, responsiveness, robust-ness, safety, scalability, securability, testability, usability, …
  8. 8. What is a Quality Attribute? ISO 25010 “It’s not what you do, it’s the way that you do it” accessibility, accountability, accuracy, adaptability, administrability, affordability, agility, auditability, autonomy, availability, compatibility, composability, configurability, correctness, credibility, customizability, debugability, degradability, determinability, demonstrability, dependability, deployability, discoverability, distributability, durability, effectiveness, efficiency, evolvability, extensibility, failure transparency, fault-tolerance, fidelity, flexibility, inspectability, installability, integrity, interchangeability, interoperability, learnability, maintainability, manageability, mobility, modifiability, modularity, operability, orthogonality, portability, precision, predictability, process capabilities, producibility, provability, recoverability, relevance, reliability, repeatability, reproducibility, resilience, responsiveness, reusability, robustness, safety, scalability, seamlessness, self-sustainability, serviceability, supportability, securability, simplicity, stability, standards compliance, survivability, sustainability, tailorability, testability, timeliness, traceability, understandability, upgradability, usability
  9. 9. why architecture? because … “… No-one re-writes a system because of deficient functionality. It’s always because of some quality failing – performance or reliability, usability, or ease of modifiability”
  10. 10. and even to predict“Reasoning” is analytical thinking estimate measure risk-evaluate account for cost-benefit-analyse calculate quantify validate budget }everything
  11. 11. the value-add of software architecture Software Architecture claims “to enable reasoning 
 about the quality attributes 
 of software systems” Why software architecture?
  12. 12. Abstraction is often the key Which goes faster? It depends…
  13. 13. Abstraction is often the key Maths: Reason by abstraction 220kW 12T
  14. 14. But get the right requirements The cost of change is high 1 60
  15. 15. Many ways to get from A to B …understand your context
  16. 16. the value-add of software architecture ✤ Understand what qualities you need
 ✤ Define them precisely, using abstractions
 ✤ Measure & Test Why software architecture?
  17. 17. Software qualities, agile style Reliability / Availability Story: “Our service should still be available even if a machine fails” Acceptance test #1: Pull the plug. Does the service still work? ISO 25010
  18. 18. Software qualities, agile style User Stories & Acceptance Tests 
 works well as a format to define and measure software qualities: Story: “The search should be fast” Acceptance test #1: Run 1000 automated searches for each of the 50 most popular terms. 95% should return in less than 2 seconds. ISO 25010
  19. 19. Software qualities, agile style Story: “User accounts should be secure against brute force attacks” Acceptance Tests #1: After 10 incorrect password entries, the system should refuse even a correct password for 20 minutes (& show message) #2 After 21 minutes, a correct password should work #3 Even if 10 guesses are from 10 different IP addresses ISO 25010
  20. 20. Some Special Software Qualities Security: Is complicated. Usually analysed as 3 different qualities (“CIA”), applied to specific Assets (e.g. data and/or systems). Oh and there’s authenticity, non-repudiation & accountability & … Scalability: is not, imho, a software quality. But it is a nearly-magic bullet: one tactic for performance, reliability/availability & volume/load in one go. Maintainability/Evolvability: Is often your agile developers’ favourite concern for some meaning of “special”
  21. 21. Modifiability, Extensibility, Evolvability
  22. 22. Modifiability & Extensibility Quality: Modifiability/Evolvability Story: A new font format or output format becomes popular Acceptance test #1: Using the new format should require change to only 1 component and no interfaces
  23. 23. Load balancing as a tactic for scaling
  24. 24. Load balancing as a tactic for scaling Quality: Availability (under load) Story: Lots of users Acceptance test #1: the system should support 1000 simultaneous users without loss of any other quality or function
  25. 25. multiple architectural views each view has its own vocabulary
  26. 26. 4+1 (Kruchten, 1995) IBM developerworks
  27. 27. 20 years on … “6 + 0 + 1” Rozanski & Woods, Software Systems Architecture, 2nd ed
  28. 28. Why software architecture? Why Software Architecture ? because it enables reasoning 
 about the quality attributes 
 of a software system the “Value-Add”
  29. 29. agilenorth.org/2016-conference/ Chris F Carroll Software Architecture : What?
  30. 30. Architecture is ... Bass, Clements, Kazman, 1997-2012 The Software Engineering Institute
 (ca 2001AD) : “The structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”
  31. 31. Architecture is ... Kruchten, updated 2009 Kruchten 2009 
 The Significant Decisions about:
 • the organisation of a software system, • the selection of the structural elements and their interfaces by which the system is composed together with their behaviour as specified in the collaboration among those elements, • the composition of these elements into progressively larger subsystems,the architectural style that guides this organisation, these elements and their interfaces, their collaborations, and their composition
  32. 32. architecture has design decisions http://www.enterpriseintegrationpatterns.com/gregor.html
  33. 33. What is “The Architecture” of a system? rough cut definitions “the fundamental structures or organisation of your code” “all the rules & design decisions you have get right up-front, because they are too expensive to change later.”
  34. 34. “Shearing layers” views a building as components that evolve in different timescales. 
 Frank Duffy: “Our basic argument is that there isn't any such thing as a building. A building properly conceived is several layers of longevity of built components.”lower shearing layers are too expensive to change
  35. 35. Agile Software Architecture photo: http://d.lib.ncsu.edu ua023_025 copyright not known
  36. 36. Agile vs Architecture Destined to Fight? Individuals & interactions over processes and tools Working software vs comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan ITABOK ISO 42010 40 years of experience!
  37. 37. Agile & Architecture Common Priorities “Our highest priority is to satisfy the customer ...” ISO42010 Systems & Software Engineering — Architecture Description
  38. 38. http://agilemanifesto.org together with /principles.html Manifesto for Agile Software Development We are uncovering better ways of developing
 software by doing it and helping others do it.
 Through this work we have come to value: Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
 That is, while there is value in the items on the 
 right, we value the items on the left more.
  39. 39. Manifesto for Agile Software Development We are uncovering better ways of developing
 software by doing it and helping others do it.
 Through this work we have come to value: Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
 That is, while there is value in the items on the 
 right, we value the items on the left more. learning through doing together CONTINUOUS LEARNING RELATIONSHIPS together with /principles.html FOCUS ON THE GOAL
  40. 40. Cargo Cult Agile “the outward form, but not the power”
  41. 41. Cockburn’s “Heart of Agile” alistair.cockburn.us/HeartOfAgile
  42. 42. We don’t need no stinkin’ architecture
  43. 43. The Architect vs. the Agile Team Threats “The chief measure of progress is working software” so what value are you adding? “Your up-front design won’t solve our actual problems or help us respond to change”
  44. 44. ! Story of a failure !  Large re-engineering of a complex distributed world-wide system; 2 millions LOC in C, C++, Cobol and VB !  Multiple sites, dozens of data repositories, hundreds of users, 24 hours operation, mission- critical ($billions) !  xP+Scrum, 1-week iterations, 30 then up to 50 developers !  Rapid progress, early success, features are demo-able !  Direct access to customer , etc. !  A poster project for scalable agile development https://pkruchten.files.wordpress.com/2009/07/kruchten-090608-agile-architecture-usc.pdf P Kruchten 2009
  45. 45. Hitting the wall !  After 4 ½ months, difficulties to keep with the 1-week iterations !  Refactoring takes longer than one iteration !  Scrap and rework ratio increases dramatically !  No externally visible progress anymore !  Iterations stretched to 3 weeks !  Staff turn-over increases; Project comes to a halt !  Lots of code, no clear architecture, no obvious way forward https://pkruchten.files.wordpress.com/2009/07/kruchten-090608-agile-architecture-usc.pdf P Kruchten 2009
  46. 46. Hitting the wall !  After 4 ½ months, difficulties to keep with the 1-week iterations !  Refactoring takes longer than one iteration !  Scrap and rework ratio increases dramatically !  No externally visible progress anymore !  Iterations stretched to 3 weeks !  Staff turn-over increases; Project comes to a halt !  Lots of code, no clear architecture, no obvious way forward https://pkruchten.files.wordpress.com/2009/07/kruchten-090608-agile-architecture-usc.pdf P Kruchten 2009
  47. 47. how much architecture you need depends on what you are building
  48. 48. depends on what you are building
  49. 49. Software without architecture? P.S. option 1 is a lie Two options for doing software without doing architecture: 1) Build something very small and simple
 – or –
 2) Rely on someone else’s architecture
  50. 50. Software without architecture? Simple software … public static void Main() { System.Console.WriteLine("Hello, World!"); }
  51. 51. Software without architecture? …means someone did architecture public static void Main() { System.Console.WriteLine("Hello, World!"); }
  52. 52. Fairbanks, 2010 How
 about
 “Just Enough” Architecture? enough to cover your risk
  53. 53. Fairbanks, 2010Software Quality Risk of Failure 1) Identify and prioritise risks 2) Select and apply a set of architecture techniques 3) Evaluate risk reduction http://static1.1.sqspcdn.com/static/f/702523/9359219/1289413590470/201011-Fairbanks.pdf
  54. 54. how much architecture you need depends on how much RISK you have
  55. 55. architecture & iterative delivery “Risk Driven Development” The Fairbanks’ Quick Test: ☛ Are your risks written down?
  56. 56. Rational Unified Process & OpenUP http://epf.eclipse.org/wikis/openup/ Unified Process proposed that on a greenfield project, the highest risk is usually the architecture On paper Coded & on hardware
  57. 57. Skeleton is the first deliverable grow the functionality on it also called “Spike” or “Tracer Bullet” Hence, the Skeleton Architecture
  58. 58. Skeleton is the first deliverable but identify where functionality will go The Agile Growable Walking Skeleton identify WHERE the muscle will go
  59. 59. Partitioning for Agile Development http://epf.eclipse.org/wikis/openup/ How do you make a skeleton “growable”? ☛ Architectures have a hammer for this kind of problem, before which everything is a nail; and the name of this hammer shall be called,
 
 “Partition the System”
  60. 60. Just the right architecture “building software as if people mattered”
  61. 61. Coplien & Bjørnvig, 2010 • The right architecture enables 
 rapid agile development. • “Lean” means thinking ahead
  62. 62. Lean Architecture for Agile Software: Coplien & Bjørnvig's Partitioning Steps An example of
 “Partition by rate of change” 
 The domain is stable, 
 sometimes over centuries! 
 The functionality is volatile, and requirements can change daily
  63. 63. get the domain right good 
 old-
 fashioned OO “Respect the Domain”
  64. 64. Domain Driven Design means… ☛ Care more about the business (domain) you are targeting than the technology ☛ If the domain is complex, model it accurately & don’t stop refining and correcting the model ☛ Ubiquitous Language: the same vocabulary everywhere ☛ Bounded Context: Models, like words, only have meaning in a context https://www.infoq.com/interviews/domain-driven-design-eric-evans
  65. 65. Lean Architecture for Agile Software Coplien & Bjørnvig's Partitioning Steps 2) Partition to maximise the autonomy of self- organising teams • Agile organisations organise by teams • You can't fight Conway’s Law
 “Organisations which design systems ... are constrained to produce designs which are copies of the communication structures of those organisations” ☛ Let the human considerations drive the partitioning, with software engineering concerns secondary
  66. 66. Implications of Conway’s law dependencies: code & people Your architecture will follow your teams. If your teams are organised in layers like this, then 
 (whatever you try to make it) 
 your architecture will look like this too.
  67. 67. Layers means dependencies dependencies: code & people If teams 
 match layers… 
 dependencies go outside the team…
 
 no team is ever able to deliver easily
  68. 68. match teams to business domain rather than skill-oriented teams http://www.full-stackagile.com/2016/02/14/team-organisation-squads-chapters-tribes-and-guilds/ Don’t fight Conway’s law. The law will win. But a team
 that can cover all the bases 
 (& layers!)
 can deliver indepen- dently
  69. 69. principles behind the agile manifesto agilemanifesto.org/principles.html Autonomous, Self Organising Teams “Build projects around motivated people. 
 Give them the environment and support they need, 
 and trust them to get the job done.” “The best architectures, requirements, and designs 
 emerge from self-organizing teams.”
  70. 70. Lean Architecture for Agile Software Coplien & Bjørnvig's Partitioning Steps 2) Partition to maximise the autonomy of self- organising teams • Enable teams to deliver • If you fight Conway’s Law, the Law will win ☛ Let the human considerations drive the partitioning, with software engineering concerns secondary
  71. 71. each url is almost a separate business with its own webapp 
 (possibly on a separate server)
  72. 72. (microservices not the only way) https://msdn.microsoft.com/en-us/magazine/mt595752.aspx Auto-
 nomous 
 teams can 
 deliver faster by avoiding complex dependencies Autonomous teams reduce dependencies
  73. 73. Q: how stable are capabilities? SOA example: services map to business capabilities
  74. 74. Lean Architecture for Agile Software Coplien & Bjørnvig's Partitioning Steps Respect Domain Knowledge • Partition around domains. Domains should in fact match business structure • Don't split a domain across geographic locations or across architectural units • Re-use existing products & product lines to bolster domain partitioning Respect Conway’s Law • It shouldn't take a village to raise a module. • 1 team can deliver & change a module fast. 3 teams can’t.
  75. 75. Lean Architecture for Agile Software: What the system is vs. what the system does Having “Partitioned by rate of change” and created a stable domain we now deal with … 
 The functionality is volatile, and requirements can change daily
  76. 76. create Spaces for what-the-system-does tactics for agility Consider how the architecture for a hotel enables the functionalities of hotelling, e.g. eating and sleeping. ☛ It does so by providing spaces within which the functions can take place ☛ Build a software architecture which provides a space for things to happen: the functionality
  77. 77. functionality goes in here
  78. 78. grand central terminal
  79. 79. royal palace, venaria http://www.dreamstime.com/zanico_info
  80. 80. two metaphors, but the same idea make space for functionality
  81. 81. define a space for what-the-system-does make space for functionality ☛ The growable skeleton has identified places where a growing series of use- cases can be added. ☛ The building-creates-spaces idea provides space within which the functionality can be coded and easily changed or even replaced
  82. 82. the application layer can be expandable “layer” does not mean layered architecture Aim for stability in the domain model: it only goes here if it’s true “forever” Let the application layer change & expand to your customers’ heart’s content UI layer is usually at least as volatile as application layer
  83. 83. works even better with hexagons hexagonal architecture http://www.methodsandtools.com/archive/archive.php?id=97 Domain Model 
 in the middle ApplicationLayerForUseCases Application 
 “Layer”
  84. 84. some thoughts on SOA IANA Service Architect No change here: still aiming for a long term stable domain model Event handlers one option for where you easily change behaviour SOA: You may be more concerned with business processes than with Use Cases
  85. 85. “Shearing layers” views a building as components that evolve in different timescales. 
 Frank Duffy: “Our basic argument is that there isn't any such thing as a building. A building properly conceived is several layers of longevity of built components.”lower shearing layers are too expensive to change
  86. 86. agility as a software quality tactics to achieve it • An early walking skeleton with identifiable space for use-cases to expand in • Match teams to business domain • Partition by Domain • Partition for Autonomous Teams • Architect the spaces for adding functionality
  87. 87. how many ways can I do it wrong? how to do it wrong
  88. 88. My Favourite Anti Patterns … let me count the ways 15 Layer Architecture
 Distributed objects for hipsters
 Re-use that isn’t
 Un-autonomous teams
 It’s the wrong abstraction, Grommit!
  89. 89. 15 Layer Architecture Step 1 to a 15 layer architecture Step 1: Start with a good old-fashioned 20th century 3-tier or layered application architecture
  90. 90. Here’s one I made earlier Step 2: Jump on Services Bandwagon but don’t study any service oriented architecture patterns
  91. 91. distributed objects were popular once there’s a reason they’re history
  92. 92. A SOA reference architecture is very different to layers
  93. 93. in summary, three principles… Chris F Carroll Agile Software Architecture
  94. 94. prioritise your software qualities define, measure and test
  95. 95. Don’t Fight Conway’s Law Partition for Domains, and for Autonomous Teams Respect The Domains
  96. 96. Make Spaces for functionality
  97. 97. http://cafe-encounter.net @chrisfcarroll Agile Software Architecture

×