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.

Building Evolutionary Architectures (N26 NYC Meetup August 2018)

1,139 views

Published on

An understanding of how to approach building software that can evolve over time. Hosted at the N26 NYC Meetup in August 2018)

Published in: Software

Building Evolutionary Architectures (N26 NYC Meetup August 2018)

  1. 1. @patkua 
 N26 NYC Meetup - August 2018 Building Evolutionary Architectures { }
  2. 2. I am building the technology group behind the modern bank designed for the digital age. We are looking for people to join us on that journey: https://n26.com/jobs/ (NYC) #leader #coach #architect #developer #life-long-learner #speaker #author CTO of N26
  3. 3. CTO of N26 thekua.io/evolarch thekua.io/twtl thekua.io/retrobook
  4. 4. EVOLUTION
  5. 5. … is inevitable NGECHA
  6. 6. Technical Domain NGECHA
  7. 7. Technical Programming languages Libraries Frameworks Tools Operating environments Technical constraints
  8. 8. Technical Domain NGECHA
  9. 9. Domain Revenue models Base technology adoption Competitors Customer needs Markets Products
  10. 10. … is inevitable NGECHA
  11. 11. … is inevitable NGECHA then If
  12. 12. WHAT IF… we architected a system for change?
  13. 13. DEFINITION
  14. 14. DEFINITION An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensionsmultiple dimensions incremental guided
  15. 15. GENERATIONS incremental Architectures are evolved through releases
  16. 16. GENERATIONS incremental releases representI
  17. 17. GENERATIONS 6 months 3 months 1 month daily?
  18. 18. GENERATIONS
  19. 19. GENERATIONS Time taken to get a simple change into production repeatably reliably = CYCLE TIME
  20. 20. GENERATIONS = CYCLE TIME
  21. 21. GENERATIONS = CYCLE TIME Continuous Integration Automate everything Keep everything in source control “Done” means released (into production) Shared release responsibility Improve continuously
  22. 22. Architect Develop Release BUILDING ARCHITECTURE
  23. 23. ARCHITECTUREWHAT IS ?
  24. 24. WHAT IS ARCHITECTURE? “Software architecture is the decisions which are both important and hard to change.” - Martin Fowler Source: https://www.youtube.com/watch?v=DngAZyWMGR0
  25. 25. WHAT IS ARCHITECTURE? “…architecture is about understanding what you need to build, creating a vision for building it and making the appropriate design decisions” - Simon Brown Source: Architecture for Software Developers
  26. 26. WHAT IS ARCHITECTURE? “Architecture is the decisions
 that you wish you could get right early in a project” - Ralph Johnson Source: Who needs an Architect? (Fowler 2003)
  27. 27. Architect Develop Release How hard is that? Easy stuff here Make important decisions here
  28. 28. Architect Develop Release How hard is that? Easy stuff here Make important decisions here What appears important here may not be important We learn a lot more
 about the problem space and false assumptions Much harder than we thought!
  29. 29. Architect Develop Release
  30. 30. Architect Develop Release Reflect
  31. 31. Architect Develop Release Reflect Cycle time = constraint
  32. 32. DEFINITION An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensionsmultiple dimensions incremental guided
  33. 33. FITNESS FUNCTIONS guided Evolutionary architectures withare
  34. 34. FITNESS FUNCTIONS “An objective function that measures how close a given solution fits to a particular goal”
  35. 35. IMPORTANT UNIMPORTANT NFRs CFRs Quality Attributes Low response time Large # of users Strong audit trail Availability Heavy legal compliance Internationalisation & Localisation Monitoring Mobile responsive FITNESS FUNCTIONS
  36. 36. IMPORTANT UNIMPORTANT NFRs CFRs Quality Attributes Low response time Large # of users Strong audit trail Availability Heavy legal compliance Internationalisation & Localisation Monitoring Mobile responsive FITNESS FUNCTIONS
  37. 37. FITNESS FUNCTIONS Metrics, Tests and Process “An objective function that measures how close a given solution fits to a particular goal”
  38. 38. FITNESS FUNCTIONS Metrics, Tests and Process atomic continuousholistic
  39. 39. atomic FITNESS FUNCTIONS /** * Ensure codebase does not contain cyclic dependencies */ public void testAllPackages() { Collection packages = jDepend.analyze(); assertFalse(“Cycles exist”, jDepend.containsCycles(); } Source: https://github.com/clarkware/jdepend
  40. 40. FITNESS FUNCTIONS public void testAllPackages() throws Exception { JDepend jDepend = buildNewJDepend(); DependencyConstraint constraint = new DependencyConstraint(); JavaPackage web = constraint.addPackage(“com.thekua.web”); JavaPackage util = constraint.addPackage(“com.thekua.util”); JavaPackage repository = constraint.addPackage(“com.thekua.dao”); web.dependsOn(util); repository.dependsOn(util); web.dependsOn(repository); jDepend.analyze(); assertTrue(“Dependency mismatch”, jDepend.dependencyMatch(constraint)); } Source: https://github.com/clarkware/jdependatomic
  41. 41. FITNESS FUNCTIONS atomic continuousholistic
  42. 42. FITNESS FUNCTIONS Performance was particularly critical Build a CD pipeline of performance tests Sanity performance test Memory soak test Detected unusual behaviour in a test run Found that disk controller had been misconfigured holistic
  43. 43. FITNESS FUNCTIONS atomic continuousholistic
  44. 44. FITNESS FUNCTIONS continuous
  45. 45. FITNESS FUNCTIONS & CD “If it hurts, do it more often” - Continuous Delivery Metrics, Tests and Process
  46. 46. FITNESS FUNCTIONS & CD “If it hurts, do it more often” - Continuous Delivery Metrics, Tests and Process There are known knowns There are known unknowns - Donald Rumsfeld BUT There are also unknown unknowns
  47. 47. In house data centres Cloud computing Serverless computing ???
  48. 48. DEFINITION An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensionsmultiple dimensions incremental guided
  49. 49. DIMENSIONS OF CHANGE
  50. 50. TECHNICAL CHANGES Library, Tool, Framework, Platform Introduce Upgrade Replace RemoveConfigure
  51. 51. DOMAIN CHANGES Business flow Features Conditions Interface changes New applications New domain New interfaces
  52. 52. ARCHITECTURAL APPROACHES
  53. 53. BIG BALL OF MUD LAYERED ARCHITECTURE MICRO KERNEL MICROSERVICES
  54. 54. classes coupling connections BIG BALL OF MUD
  55. 55. !55 PRESENTATION BUSINESS PERSISTENCE DATABASE SERVICE COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT LAYERED ARCHITECTURES
  56. 56. !56 PRESENTATION BUSINESS PERSISTENCE DATABASE SERVICE COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT request LAYERED ARCHITECTURES
  57. 57. LAYERED ARCHITECTURES
  58. 58. PLUGIN PLUGIN PLUGIN PLUGIN PLUGIN PLUGIN CORE SYSTEM MICROKERNEL
  59. 59. MICROKERNEL
  60. 60. API CUSTOMER MODULE MODULE MODULE USER/ROLE MODULE MODULE MODULE ACCOUNT MODULE MODULE MODULE PRODUCT MODULE MODULE MODULE INVENTORY MODULE MODULE MODULE FULFILLMENT MODULE MODULE MODULE CLIENT REQUESTS CLIENT REQUESTS CLIENT REQUESTS MICROSERVICES
  61. 61. DEFINITION An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensionsmultiple dimensions incremental guided
  62. 62. PRACTICES
  63. 63. Conway’s Law: Org Design-Architecture
  64. 64. User Interface Server-side DBAs
  65. 65. Catalog Orders Shipping
  66. 66. Catalog Orders ShippingInverse Conway Manoeuvre
  67. 67. PRINCIPLE-DRIVEN over
  68. 68. PRODUCTS over PROJECTS Projects: Products: ‘s “You build it, you run it”
  69. 69. LAST RESPONSIBLE MOMENT Internalcode
  70. 70. LAST RESPONSIBLE MOMENT Internalcode
  71. 71. LAST RESPONSIBLE MOMENT Internalcode ADAPTER
  72. 72. LAST RESPONSIBLE MOMENT Domain Adapters Ports and Adapters
  73. 73. SENSE AND PROBE over
  74. 74. BUT Not an excuse to abstract all the things
  75. 75. !75 Think like a town planner If a lot about architecture is about making decisions, help people make better decisions. Avoid making the decisions for them.
  76. 76. ARCHITECTURAL BRIEFINGS Design decision Tool Implementation …
  77. 77. ARCHITECTURAL BRIEFINGS Design decision Tool Implementation …?? ??
  78. 78. ARCHITECTURAL BRIEFINGS Design decision Tool Implementation
  79. 79. ARCHITECTURAL BRIEFINGS Design decision Tool Implementation …
  80. 80. ARCHITECTURAL BRIEFINGS
  81. 81. ARCHITECTURAL BRIEFINGS
  82. 82. ARCHITECTURAL BRIEFINGS
  83. 83. ARCHITECTURAL BRIEFINGS
  84. 84. ARCHITECTURAL BRIEFINGS Everyone becomes
 an architect
  85. 85. Technical Domain Continuous Delivery Support fast feedback Appropriate coupling Ports and Adapters Automated fitness functions Matches business capabilities Products over projects Cross functional team Enables experimentation Decentralised governance
  86. 86. ANTI-PATTERNS
  87. 87. ANTI-PATTERN The last 10% trap
  88. 88. ANTI-PATTERN Coding via Configuration
  89. 89. ANTI-PATTERN Product Customisation
  90. 90. ANTI-PATTERN Exuberant Coupling
  91. 91. CHOOSING STYLES
  92. 92. Build Buy
  93. 93. Build Buy
  94. 94. Build Buyand/or Libraries Frameworks COTS or Software Products Custom code Functionality
  95. 95. Build Buyand/or Libraries Frameworks COTS or Software Products Custom code Functionality Ability to Change
  96. 96. 96 Strategic Commodity Need for rapid change High Low Low HighValuegenerating Support Experimental
  97. 97. CONCLUSION
  98. 98. DEFINITION An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensionsmultiple dimensions incremental guided
  99. 99. TO CONSIDER Architectural choices Decision making process + thinking Organisational and Cultural aspects
  100. 100. @patkua Patrick Kua, CTO of @n26 Thank you Psst. We’re hiring in NYC https://n26.com/jobs { }

×