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

1,705 views

Published on

In our industry, one of the only guarantees is change. Many of today’s tools, technologies, and business models will soon cease to exist, only to be replaced by newer ones. Architects face the challenge of planning for today’s systems knowing that the problems of tomorrow will be completely different from the problems of today. Evolutionary architecture is an architectural approach that prioritises change as a first principle but balances this need with delivering value early.

Published in: Technology
  • Be the first to comment

Building Evolutionary Architectures

  1. 1. @patkua Patrick Kua - February 2018 Building Evolutionary Architectures
  2. 2. SPAIN 3% ⬒ Full European banking license ⬒ First fully mobile bank account ⬒ One-touch access to all financial products Digital Solution to Banking
  3. 3. 64% 12% GERMANY ITALY FRANCE 3% SPAIN 3% AUSTRIA 9% 700.000+ users in
 17 countries
  4. 4. Featured as “Editor’s Choice” Featured at Apple WWDC Several promotions through Apple Featured in “Best Apps in 2016” Featuring in the Play Store
 with major releases Consistent strong recognition by Apple and Google
  5. 5. Users love the N26
 experience 5 8,400 Reviews
  6. 6. 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/ (Berlin) #leader #coach #architect #developer #life-long-learner #speaker #author CTO of N26
  7. 7. CTO of N26 thekua.io/evolarch thekua.io/twtl thekua.io/retrobook
  8. 8. EVOLUTION
  9. 9. … is inevitable NGECHA
  10. 10. Technical Domain NGECHA
  11. 11. Technical Programming languages Libraries Frameworks Tools Operating environments Technical constraints
  12. 12. Technical Domain NGECHA
  13. 13. Domain Revenue models Base technology adoption Competitors Customer needs Markets Products
  14. 14. … is inevitable NGECHA
  15. 15. … is inevitable NGECHA then If
  16. 16. A case study The trap many companies fall for
  17. 17. Investigation Shopping List Plan for Change Product Connect them all Start Later… Almost “done” Change!!! Idea
  18. 18. Custom costs Vendor’s schedule 3-6 months Still buggy One precious Environment Change is hard Stop!!!
  19. 19. WHAT IF… we architected a system for change?
  20. 20. DEFINITION
  21. 21. DEFINITION An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensionsmultiple dimensions incremental guided
  22. 22. GENERATIONS incremental Architectures are evolved through releases
  23. 23. GENERATIONS incremental releases representI
  24. 24. GENERATIONS 6 months 3 months 1 month daily?
  25. 25. GENERATIONS
  26. 26. GENERATIONS Time taken to get a simple change into production repeatably reliably = CYCLE TIME
  27. 27. GENERATIONS = CYCLE TIME
  28. 28. GENERATIONS = CYCLE TIME Continuous Integration Automate everything Keep everything in source control “Done” means released (into production) Shared release responsibility Improve continuously
  29. 29. Architect Develop Release BUILDING ARCHITECTURE
  30. 30. ARCHITECTUREWHAT IS ?
  31. 31. 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
  32. 32. 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
  33. 33. 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)
  34. 34. Architect Develop Release How hard is that? Easy stuff here Make important decisions here
  35. 35. 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!
  36. 36. Architect Develop Release
  37. 37. Architect Develop Release Reflect
  38. 38. Architect Develop Release Reflect Cycle time = constraint
  39. 39. DEFINITION An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensionsmultiple dimensions incremental guided
  40. 40. FITNESS FUNCTIONS guided Evolutionary architectures withare
  41. 41. FITNESS FUNCTIONS “An objective function that measures how close a given solution fits to a particular goal”
  42. 42. 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
  43. 43. 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
  44. 44. FITNESS FUNCTIONS Metrics, Tests and Process “An objective function that measures how close a given solution fits to a particular goal”
  45. 45. FITNESS FUNCTIONS Metrics, Tests and Process atomic continuousholistic
  46. 46. 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
  47. 47. 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
  48. 48. FITNESS FUNCTIONS atomic continuousholistic
  49. 49. 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
  50. 50. FITNESS FUNCTIONS atomic continuousholistic
  51. 51. FITNESS FUNCTIONS continuous
  52. 52. FITNESS FUNCTIONS & CD “If it hurts, do it more often” - Continuous Delivery Metrics, Tests and Process
  53. 53. 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
  54. 54. In house data centres Cloud computing Serverless computing ???
  55. 55. SENSE AND PROBE over
  56. 56. DEFINITION An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensionsmultiple dimensions incremental guided
  57. 57. DIMENSIONS OF CHANGE
  58. 58. TECHNICAL CHANGES Library, Tool, Framework, Platform Introduce Upgrade Replace RemoveConfigure
  59. 59. DOMAIN CHANGES Business flow Features Conditions Interface changes New applications New domain New interfaces
  60. 60. ARCHITECTURAL APPROACHES
  61. 61. BIG BALL OF MUD LAYERED ARCHITECTURE MICRO KERNEL MICROSERVICES
  62. 62. classes coupling connections BIG BALL OF MUD
  63. 63. 63 PRESENTATION BUSINESS PERSISTENCE DATABASE SERVICE COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT LAYERED ARCHITECTURES
  64. 64. 64 PRESENTATION BUSINESS PERSISTENCE DATABASE SERVICE COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT COMPONENT request LAYERED ARCHITECTURES
  65. 65. LAYERED ARCHITECTURES
  66. 66. PLUGIN PLUGIN PLUGIN PLUGIN PLUGIN PLUGIN CORE SYSTEM MICROKERNEL
  67. 67. MICROKERNEL
  68. 68. 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
  69. 69. DEFINITION An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensionsmultiple dimensions incremental guided
  70. 70. PRACTICES
  71. 71. Conway’s Law: Org Design-Architecture
  72. 72. User Interface Server-side DBAs
  73. 73. Catalog Orders Shipping
  74. 74. Catalog Orders ShippingInverse Conway Manoeuvre
  75. 75. PRINCIPLE-DRIVEN over
  76. 76. PRODUCTS over PROJECTS Projects: Products: ‘s “You build it, you run it”
  77. 77. LAST RESPONSIBLE MOMENT Internalcode
  78. 78. LAST RESPONSIBLE MOMENT Internalcode
  79. 79. LAST RESPONSIBLE MOMENT Internalcode ADAPTER
  80. 80. LAST RESPONSIBLE MOMENT Domain Adapters Ports and Adapters
  81. 81. BUT Not an excuse to abstract all the things
  82. 82. 82 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.
  83. 83. ARCHITECTURAL BRIEFINGS Design decision Tool Implementation …
  84. 84. ARCHITECTURAL BRIEFINGS Design decision Tool Implementation …?? ??
  85. 85. ARCHITECTURAL BRIEFINGS Design decision Tool Implementation
  86. 86. ARCHITECTURAL BRIEFINGS Design decision Tool Implementation …
  87. 87. ARCHITECTURAL BRIEFINGS
  88. 88. ARCHITECTURAL BRIEFINGS
  89. 89. ARCHITECTURAL BRIEFINGS
  90. 90. ARCHITECTURAL BRIEFINGS
  91. 91. ARCHITECTURAL BRIEFINGS Everyone becomes
 an architect
  92. 92. 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
  93. 93. ANTI-PATTERNS
  94. 94. ANTI-PATTERN The last 10% trap
  95. 95. ANTI-PATTERN Coding via Configuration
  96. 96. ANTI-PATTERN Product Customisation
  97. 97. ANTI-PATTERN Exuberant Coupling
  98. 98. CHOOSING STYLES
  99. 99. Build Buy
  100. 100. Build Buy
  101. 101. Build Buyand/or Libraries Frameworks COTS or Software Products Custom code Functionality
  102. 102. Build Buyand/or Libraries Frameworks COTS or Software Products Custom code Functionality Ability to Change
  103. 103. 103 Strategic Commodity Need for rapid change High Low Low HighValuegenerating Support Experimental
  104. 104. CONCLUSION
  105. 105. DEFINITION An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensionsmultiple dimensions incremental guided
  106. 106. TO CONSIDER Architectural choices Decision making process + thinking Organisational and Cultural aspects
  107. 107. @patkua Patrick Kua, CTO of @n26 Thank you Psst. We’re hiring in Berlin https://n26.com/jobs

×