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.
Patterns of
Evolutionary
Architecture
Chris Gow and Shawn Button
Toronto Agile - 2017
Patterns of
Evolutionary
Architecture
Chris Gow and Shawn Button
Toronto Agile - 2017
Evolutionary Architecture
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
Principle - Design for Change
Change
Change in an application is inevitable.
We need to support:
1. New business requirements (“We need to sell a new
ty...
Principle - Design for Change
Since change is inevitable, let’s design our
architecture to expect change, harnessing it fo...
manageability
modifiability
modularity
operate
ability
orthogonality
portability
precision
predictability
producibility
pr...
Principle - Evolvability as
First Class Concern
Principle - Evolvability as First-Class Architectural Concern
Architecture involves a series of trade-offs. There are many...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
To-Do Doing (1) Done
Intro
Guiding
PrinciplesCoupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
People...
Principle - Coupling
Coupling in software occurs whenever a change in one component requires
changes in another component and this affects the ...
Anti-pattern: Big Ball of Mud
Anti-pattern: Big Ball of Mud
“A Big Ball of Mud is a casually, even haphazardly, structured system. It’s
organization and...
Inappropriate and Appropriate Coupling
Inappropriate and Appropriate Coupling
Coupling can either hamper the evolution of your architecture or help
accelerate it...
Inappropriate Coupling
Risky changes, long periods of instability, developers afraid to make changes
to parts of the code, unable to adapt to a n...
Anti-Pattern: Spooky Action At A Distance
Anti-Pattern: Spooky Action At A Distance
- Not applying the DRY Principle: Every piece of knowledge must have a
single, u...
Anti-Pattern: Misapplying the DRY Principle
Anti-Pattern: Misapplying the DRY Principle
In many architectures it is common to have a small set of core classes or type...
Developing Cohesive Systems
Cohesive Systems - Appropriate Coupling
When a change in one thing does not affect any other thing then the system is
exhi...
Principle: Keep coupling isolated and at system
boundaries
Eliminate effects between unrelated things
Principle: Keep coupling isolated and at system
boundaries
Pattern: Bounded Contexts
Pattern: Bounded Contexts
Multiple models exist within a large project, when code based on distinct
models is combined sof...
Pattern: Abstraction / Anti-Corruption
layer
A layer that permits only the information your model needs to pass through
when other models (or systems) are communicatin...
To-Do Doing (1) Done
Intro
Guiding
PrinciplesCoupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
People...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
Principle - Changeable/Deferred Decisions
Principle: Changeable/Deferred Decisions
Changeable Decisions
Whenever possible we want to make our decisions changeable. ...
Anti-Pattern: Big Design Up Front
Anti-Pattern: Big Design Up Front
We are afraid of making mistakes in design, so we spend a lot of time
analyzing and desi...
Anti-Pattern: NO Design
Pattern: Lightweight Collaborative Design
Pattern: Lightweight Collaborative Design
While we want to minimize up-front design, we still have to think about the
arch...
Pattern: Build
Throwaway Prototypes
Pattern: Build Throwaway Prototypes
In order to see if a technology decision is correct, make a quick prototype.
We stress...
Pattern: Sacrificial Architecture
Pattern: Sacrificial Architecture
Since we understand that it is difficult and expensive to get our architecture
perfect u...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
Principle: YAGNI
(You Ain’t Gonna Need It!)
Principle: YAGNI (You Ain’t Gonna Need It)
As engineers we have the desire to build a robust framework that will handle ev...
Anti-Pattern: Enterprise Platform
Anti-Pattern: Enterprise Platform
The company creates a platform for all teams to use, with the best of intentions:
● Fast...
Anti-Pattern: If Framework is Good, Use It All!
Anti-Pattern: If Framework is Good, Use It All!
E.g. Spring :)
Really, it’s the urge for over-complication that’s the prob...
Anti-Pattern: Vendor
King / Last 10% Trap
Anti-Pattern: Vendor King / Last 10% Trap
Buying a product from a big vendor can seem very attractive. They
promise you th...
Anti-Pattern: Premature Micro-Services
Anti-Pattern: Premature Micro-Services
Microservices are a great way to encourage decoupling components.
But they come wit...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
Principle - Frequent Delivery
Principle - Frequent Delivery
Principle - Frequent Delivery
Focus on delivering more frequently.
In order to evolve your architecture you need
the infra...
Pattern - Automate All The Things
Pattern: Automate All The Things
Delivering frequently will require a lot of re-work and will be dangerous, unless
you can...
Pattern - Invest In
Practices
Pattern: Invest in Practices
Delivering frequently requires discipline and heavy investment in modern
technical practices....
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
Evolving a Legacy App
http://bonkersworld.net/building-software
Anti-Pattern: The Rewrite Trap
- Always harder than you expected
- Takes longer
- While we are re-writing we still have to...
Principle - Improve Incrementally
Pattern: Improve Incrementally
To avoid the dangerous and risky rewrite trap improve your legacy application
incrementally...
Pattern: The Strangler
All transactions
Strangler Pattern in Action - The Interceptor
Client
Scary
Legacy
App
Backend
System
Interceptor
/ Facade...
Pattern - The Strangler
Don’t rewrite your legacy application in one go. Incrementally move features
over to your new arch...
Pattern - Sprout Component
Client
Scary
Legacy
App Backend
System
New
Business
Logic
New
Some “Seam”
Pattern - Sprout Component
From Michael Feathers “Working Effectively With Legacy Code.” Feathers
described it as a way to...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
Principle - People First
Principle - People First
As technologists we have an instinct to try to solve our problems through
processes or tools.
Unf...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
Conway’s law
“Any organization that designs a system
(defined broadly) will produce a design
whose structure is a copy of ...
Consequence of Conway’s Law
Your company’s organization structures will exert pressure on the architecture
of your applica...
Principle - Organize to take advantage of Conway’s Law.
Principle - Organize to take advantage of Conway’s
Law.
Define an org structure that supports your real or desired applica...
Pattern - Feature Teams
Pattern - Autonomous Feature Teams
A feature team has all of the necessary resources, skills and autonomy to
complete end-...
Pattern - Product over Project
Pattern - Product over Project
People working on a “project” expect that they are on a temporary
assignment. When it’s don...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
Principle - Work Collaboratively
● Good architecture can’t be done in a isolation
● Different perspectives make a better product
● Avoid the us against the...
Anti-Pattern - Internal
Vendor/Customer Relationship
Anti-Pattern - Internal Vendor/Customer
Relationship
Everyone that’s necessary to produce value for the customer (business...
Pattern - Shared Prioritization
Pattern - Shared Prioritization
We make an artificial distinction between “business features” and
“architecture.” In reali...
Anti-Pattern - Ivory Tower Architecture
Anti-Pattern - Ivory Tower Architecture
Architecture that is devised hidden away in relative isolation from the
day-to-day...
Pattern - Architect as Coach
Being the repository of all knowledge and decision making makes them into a
dependency, and an impediment to teams deliver...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
Unix Principles:
1. Make each program do one thing well. To do a new job, build afresh
rather than complicate old programs...
Books
Thanks!
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
To-Do Doing (1) Done
Intro
Guiding
Principles
Coupling
Changeable
Decisions
Y.A.G.N.I.
Frequent
Delivery
Legacy
Apps
Peopl...
Questions?
Patterns of Evolutionary Architecture
Patterns of Evolutionary Architecture
Patterns of Evolutionary Architecture
Upcoming SlideShare
Loading in …5
×

Patterns of Evolutionary Architecture

940 views

Published on

From Toronto Agile Conference 2017
Chris Gow and Shawn Button
Learn principles and patterns to help you create and maintain evolvable systems.

Published in: Software
  • Slide #56 Anti-Pattern: Enterprise Platform. What do you call Google, Facebook, Amazon, Uber, Airbnb? Aren't they all platforms?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Patterns of Evolutionary Architecture

  1. 1. Patterns of Evolutionary Architecture Chris Gow and Shawn Button Toronto Agile - 2017
  2. 2. Patterns of Evolutionary Architecture Chris Gow and Shawn Button Toronto Agile - 2017
  3. 3. Evolutionary Architecture
  4. 4. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  5. 5. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap UpWrap Up
  6. 6. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  7. 7. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  8. 8. Principle - Design for Change
  9. 9. Change Change in an application is inevitable. We need to support: 1. New business requirements (“We need to sell a new type of widget”) 2. Updates to existing technologies (“We need to patch our platform’s security hole ASAP”) 3. New technologies (“This database doesn’t support our needs, we need to move to a NoSQL db”) 4. New non-functional needs (Yah, our business is booming. Oh SH*T, our business is booming!)
  10. 10. Principle - Design for Change Since change is inevitable, let’s design our architecture to expect change, harnessing it for the customer’s advantage.
  11. 11. manageability modifiability modularity operate ability orthogonality portability precision predictability producibility probability recoverability relevance reliability repeatability reproducibility resilience responsiveness The Architecture “-ilities” deployability discoverability distributability durability effectiveness efficiency usability extensibility failure-transpar ency fault-tolerance fidelity flexibility inspectability Installability Integrity interoperability learnability maintainability accessibility accountability accuracy adaptability administrability affordability auditability autonomy availability compatibility composability configurability correctness credibility customizability debugability degradability determinability dependability reusability robustness safety scalability seamlessness self-sustainability serviceability secure ability simplicity stability standards-compliance survivability sustainability tailorability testability timeliness traceability List from “Building Evolutionary Architectures”
  12. 12. Principle - Evolvability as First Class Concern
  13. 13. Principle - Evolvability as First-Class Architectural Concern Architecture involves a series of trade-offs. There are many different concerns that you need to juggle. Non-functional requirements (NFRs) like scalability, performance, security. As well there are business features are the point of the application. The requirement to deliver quickly, and to be able to evolve our application over time should prioritized against our need for performance, etc. They because “first class citizens” in all architectural tradeoffs. Alongside concerns such as scalability, performance, security, etc. Frequent Delivery and Evolvability and should be primary concern.
  14. 14. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  15. 15. To-Do Doing (1) Done Intro Guiding PrinciplesCoupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  16. 16. Principle - Coupling
  17. 17. Coupling in software occurs whenever a change in one component requires changes in another component and this affects the evolvability of your application. Some degree of coupling may be necessary, you want to minimize the coupling and keep it isolated and at system boundaries. When coupling is uncontrolled you can get yourself into a big ball of mud situation. Some examples of coupling are 3rd party systems, communication patterns and data structures. Principle - Coupling
  18. 18. Anti-pattern: Big Ball of Mud
  19. 19. Anti-pattern: Big Ball of Mud “A Big Ball of Mud is a casually, even haphazardly, structured system. It’s organization and structure appears to be dictated more by expediency than design. A quick fix here, a bandaid there, a temporary solution on top of another and what was once tidy becomes overgrown as piecemeal growth allows elements of the system to sprawl in an uncontrolled fashion” - Brian Foote - 1999
  20. 20. Inappropriate and Appropriate Coupling
  21. 21. Inappropriate and Appropriate Coupling Coupling can either hamper the evolution of your architecture or help accelerate it if applied appropriately. Coupling is inappropriate when your architecture is being constrained by previous design choices or external libraries and frameworks. When changes and fixes are isolated and generally not risky; components are small with minimal dependencies then coupling is appropriate.
  22. 22. Inappropriate Coupling
  23. 23. Risky changes, long periods of instability, developers afraid to make changes to parts of the code, unable to adapt to a new framework. These are types of inappropriate coupling and they really affect how your architecture can evolve and change as business requirements change. Often coupling hides behind the promise of speed and utility but when not looked out for, your architecture can run off the rails Some examples of inappropriate coupling are ● Utility classes - sticking functions such as formatting functions (date format, number format, money format) in a single class ● Single object type representation throughout application (e.g.. A canonical Product type) ● Using a 3rd party’s data type throughout your application (eg. A Facebook User type) Inappropriate Coupling
  24. 24. Anti-Pattern: Spooky Action At A Distance
  25. 25. Anti-Pattern: Spooky Action At A Distance - Not applying the DRY Principle: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system - - Changing one thing affects something else, potentially unrelated - Changes to the UI should not have any effect on the database and many database changes should not affect the UI
  26. 26. Anti-Pattern: Misapplying the DRY Principle
  27. 27. Anti-Pattern: Misapplying the DRY Principle In many architectures it is common to have a small set of core classes or types that represent core domain concepts in your organization. It is tempting to have only one such type for each concept (eg. A single Product class type or Customer class), however different parts of your organization will have different interpretations of what each of these concepts. Attempting to have a single model to put all of these interpretations in a single type leads to ambiguity and a model that is more difficult to understand.
  28. 28. Developing Cohesive Systems
  29. 29. Cohesive Systems - Appropriate Coupling When a change in one thing does not affect any other thing then the system is exhibiting an appropriate level of coupling or cohesiveness. A highly cohesive system exhibits reduced risk, increased productivity, and components are simplified and generally “Do one thing really, really well”. Testing of components is much simpler as the degree of cohesiveness increases, the amount dependencies decreases. As individual components become simplified and more cohesive their interactions with other components may become more complex. A message passing function call from type to another type is highly coupled, passing the same message over a message bus requires a higher degree of infrastructure complexity.
  30. 30. Principle: Keep coupling isolated and at system boundaries
  31. 31. Eliminate effects between unrelated things Principle: Keep coupling isolated and at system boundaries
  32. 32. Pattern: Bounded Contexts
  33. 33. Pattern: Bounded Contexts Multiple models exist within a large project, when code based on distinct models is combined software becomes buggy, unreliable and difficult to understand. It’s also often unclear which context a model should not be applied. A Bounded Context gives team members a clear and shared understanding of what has to be consistent and what can develop independently. Explicitly set boundaries and keep model strictly consistent within these bounds
  34. 34. Pattern: Abstraction / Anti-Corruption layer
  35. 35. A layer that permits only the information your model needs to pass through when other models (or systems) are communicating to it. Permit information through the anti-corruption layer in a format that works best for your model and discard the external model’s representation. This allows your model to evolve in a manner that works best for it and not be affected by changes in the external model’s own evolution. An anti-corruption layer can also abstract away dependencies when working with frameworks and existing legacy code bases Pattern: Abstraction / Anti-Corruption layer
  36. 36. To-Do Doing (1) Done Intro Guiding PrinciplesCoupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  37. 37. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  38. 38. Principle - Changeable/Deferred Decisions
  39. 39. Principle: Changeable/Deferred Decisions Changeable Decisions Whenever possible we want to make our decisions changeable. If we can change our decisions it protects us from the risk of future unknowns. Deferred Decisions For changes that are hard to reverse, figure out ways that we can defer the decisions as much as possible. The longer we wait the more we know about what we actually need.
  40. 40. Anti-Pattern: Big Design Up Front
  41. 41. Anti-Pattern: Big Design Up Front We are afraid of making mistakes in design, so we spend a lot of time analyzing and designing up front, in order to make sure we get it right the first time. Unfortunately: ● We won't get it right. No matter how much effort we put into it. ● We will add things to our architecture that we will not need. ● It will delay our ability to deliver something quickly to customers to get early value and feedback.
  42. 42. Anti-Pattern: NO Design
  43. 43. Pattern: Lightweight Collaborative Design
  44. 44. Pattern: Lightweight Collaborative Design While we want to minimize up-front design, we still have to think about the architecture. Create lightweight, collaborative, living design. For example, do it in front of a white-board with the entire team.
  45. 45. Pattern: Build Throwaway Prototypes
  46. 46. Pattern: Build Throwaway Prototypes In order to see if a technology decision is correct, make a quick prototype. We stress that they should be throwaway, because we need to keep them light, and just do the minimum that we need in order to learn if it is suitable. If you are faced with a choice between several architectures, do prototypes for both and learn which works best for you. Do “set-based” design, where you explore multiple alternatives at once.
  47. 47. Pattern: Sacrificial Architecture
  48. 48. Pattern: Sacrificial Architecture Since we understand that it is difficult and expensive to get our architecture perfect up front, be prepared to throw away any architectural element. A great example is Twitter. They started with Ruby on Rails, which allowed them to quickly get into the market. When they needed to scale they changed their architecture. Yes it was painful to change, but they were able to get into the market quickly, and as they scaled they had a much better idea of their needs.
  49. 49. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  50. 50. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  51. 51. Principle: YAGNI (You Ain’t Gonna Need It!)
  52. 52. Principle: YAGNI (You Ain’t Gonna Need It) As engineers we have the desire to build a robust framework that will handle everything that we ever need to handle, forever into the future. The problem is that only a subset of the cool features we add will ever get used. The rest just add complexity and slow us down. When you design your architecture keep YAGNI in mind. Only add something if you need it to deliver a feature for a needed non-functional requirement. If you’ve built an evolvable architecture you can always add it later!
  53. 53. Anti-Pattern: Enterprise Platform
  54. 54. Anti-Pattern: Enterprise Platform The company creates a platform for all teams to use, with the best of intentions: ● Faster delivery by providing the plumbing. ● People can move between teams because the platform is the same. ● We can enforce governance, monitoring, etc. Unfortunately this is a form of coupling that can slow teams down. ● They are dependent on a framework, and they can’t change. ● In order to make it work for everyone’s needs it will get bigger and bigger, and then it won’t really work well for anyone.
  55. 55. Anti-Pattern: If Framework is Good, Use It All!
  56. 56. Anti-Pattern: If Framework is Good, Use It All! E.g. Spring :) Really, it’s the urge for over-complication that’s the problem. Find the simplest way to do something. Do it. Maybe that’s enough. If not you can come back and add to it later (see also YAGNI) As much as possible keep your domain logic agnostic of the framework you are using! Build an abstraction layer between you and your framework.
  57. 57. Anti-Pattern: Vendor King / Last 10% Trap
  58. 58. Anti-Pattern: Vendor King / Last 10% Trap Buying a product from a big vendor can seem very attractive. They promise you that they give you the features you want without needing those nasty developers. ● First 80% is easy. Next 10% is hard. Last 10% is impossible. ● Might not support for rapid delivery (no automated tests, poor code control practices, hard to deploy) ● Might be hard to evolve (locked into a someone else’s architecture) ● Vendor Lock-in - Makes it hard to change your mind ● Look for vendors that allow This also might apply to the frameworks you use. There lock-in pressure when you choose to use Drupal, Rails, Spring, Angular, etc. As much as possible keep your domain logic agnostic of the framework you are using!
  59. 59. Anti-Pattern: Premature Micro-Services
  60. 60. Anti-Pattern: Premature Micro-Services Microservices are a great way to encourage decoupling components. But they come with extra complexity around design, code management, deployment, testing, operations. They might also not be appropriate when you are in MVP stage. This doesn’t mean don’t do it, but realize that you need to build the infrastructure, the discipline and the practices to support it. Start slow with a couple of services. Grow your services as you learn how to do it.
  61. 61. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  62. 62. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  63. 63. Principle - Frequent Delivery
  64. 64. Principle - Frequent Delivery
  65. 65. Principle - Frequent Delivery Focus on delivering more frequently. In order to evolve your architecture you need the infrastructure, discipline and practices to allow you to deploy frequently with safety. (Side benefits: gives us opportunities for earlier value and feedback. You know, agility).
  66. 66. Pattern - Automate All The Things
  67. 67. Pattern: Automate All The Things Delivering frequently will require a lot of re-work and will be dangerous, unless you can automate your repetitive tasks: ● Testing (unit -> end-to-end) ● Deployment ● Environment provisioning ● Performance testing ● Production monitoring ● Tech debt measures (test coverage, complexity, etc.) ● etc….
  68. 68. Pattern - Invest In Practices
  69. 69. Pattern: Invest in Practices Delivering frequently requires discipline and heavy investment in modern technical practices. You will need This might require: ● Creating new “Devops” infrastructure ● Training/coaching/mentoring in the new practices ● Hiring new people with the new skills ● Slowing down a little until you gain the ability to speed up (relief from deadlines)
  70. 70. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  71. 71. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  72. 72. Evolving a Legacy App
  73. 73. http://bonkersworld.net/building-software
  74. 74. Anti-Pattern: The Rewrite Trap - Always harder than you expected - Takes longer - While we are re-writing we still have to keep the old system updated, so making changes in two places - Faced with the same compromises that you made the first time - Using the same people and the same practices, we will end up with the same mess Company killing examples: Lotus 123, Mozilla
  75. 75. Principle - Improve Incrementally
  76. 76. Pattern: Improve Incrementally To avoid the dangerous and risky rewrite trap improve your legacy application incrementally. Pull out a small bits of behaviour, while keeping the existing application running. The new pieces can be built with modern architectural concerns, including evolvability. Eventually you may have moved everything over to the new architecture, and can decommission the legacy application.
  77. 77. Pattern: The Strangler
  78. 78. All transactions Strangler Pattern in Action - The Interceptor Client Scary Legacy App Backend System Interceptor / Facade New Business Logic Some transactions
  79. 79. Pattern - The Strangler Don’t rewrite your legacy application in one go. Incrementally move features over to your new architecture, while keeping the old one running. Gradually evolve a new system over the edges of the old. Intercept transactions going to your legacy system, and route them to the new. It works best if the old and new systems are not aware of each other.
  80. 80. Pattern - Sprout Component Client Scary Legacy App Backend System New Business Logic New Some “Seam”
  81. 81. Pattern - Sprout Component From Michael Feathers “Working Effectively With Legacy Code.” Feathers described it as a way to refactor existing code. Find a “seam” into the existing app, and write new behaviour in a new method or class. But this could also be used at a higher architectural level. Potential seams: ● Method calls in code ● Events on a message Bus ● Significant business events ● Table updates ● Log files ○ 3rd party integrations ○ File extracts (eg. Excel, CSV) There’s lots of options. Be Creative!
  82. 82. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  83. 83. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  84. 84. Principle - People First
  85. 85. Principle - People First As technologists we have an instinct to try to solve our problems through processes or tools. Unfortunately a lot of our problems are only solvable through individuals and interactions.
  86. 86. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  87. 87. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  88. 88. 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.” - Melvin Conway
  89. 89. Consequence of Conway’s Law Your company’s organization structures will exert pressure on the architecture of your applications. For example, if you have “back-end,” “middle-tier,” and “front-end” hierarchies, and you are attempting trying to move to a micro-service architecture you will find it difficult. And in fact you might end up building “micro-services” that are “middle-tier” and “back-end” services, rather than being organized around your domain.
  90. 90. Principle - Organize to take advantage of Conway’s Law.
  91. 91. Principle - Organize to take advantage of Conway’s Law. Define an org structure that supports your real or desired application structure. Minimize dependencies between teams (which slow you down) by organizing to match your architecture.
  92. 92. Pattern - Feature Teams
  93. 93. Pattern - Autonomous Feature Teams A feature team has all of the necessary resources, skills and autonomy to complete end-to-end customer features on their own. They work across all components and disciplines. (As opposed to a “component team” that only delivers one of many pieces that are needed to deliver customer value). By organizing into feature teams you lessen the dependencies that will slow down delivery.
  94. 94. Pattern - Product over Project
  95. 95. Pattern - Product over Project People working on a “project” expect that they are on a temporary assignment. When it’s done, they will move on to other projects. The application is seldom treated as a 'product', that needs to live in production for many years after the project is completed. This encourages short-term thinking - deliver the next set of features - rather than taking attempting to maximize the the long-term value of the product. This leads to problems such as the accumulation of technical debt. Long-term, product thinking is essential for people from both business and technology.
  96. 96. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  97. 97. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  98. 98. Principle - Work Collaboratively
  99. 99. ● Good architecture can’t be done in a isolation ● Different perspectives make a better product ● Avoid the us against them mentality “Business doesn’t know what they’re talking about”, instead work together to reach your shared goal Principle - Work Collaboratively
  100. 100. Anti-Pattern - Internal Vendor/Customer Relationship
  101. 101. Anti-Pattern - Internal Vendor/Customer Relationship Everyone that’s necessary to produce value for the customer (business, technology, operations, etc.) should have the shared goals of the maximizing value delivered to the customer. Unfortunately we often find an antagonistic relationship between these groups. It seems that it becomes more important to “win” or to assign blame the other groups, than to work together to create valuable software.
  102. 102. Pattern - Shared Prioritization
  103. 103. Pattern - Shared Prioritization We make an artificial distinction between “business features” and “architecture.” In reality both are necessary to deliver value to our customers. Prioritize architectural concerns (such as performance, security, technical quality, evolvability, etc), UX requirements (usability, accessibility), alongside business requirements as peers. This is fractally collaborative - it applies at team, product, and portfolio level.
  104. 104. Anti-Pattern - Ivory Tower Architecture
  105. 105. Anti-Pattern - Ivory Tower Architecture Architecture that is devised hidden away in relative isolation from the day-to-day development activities suffers from significant problems. The models in this type of architecture are often designed with little or no input from the development teams who will be charged with coding the architecture “vision”. Perfect in theory, but often unproven and incomplete, ivory tower architectures often fall victim to over complications and reflect features from every system the architects were involved with instead of what is necessary to solve your business problem.
  106. 106. Pattern - Architect as Coach
  107. 107. Being the repository of all knowledge and decision making makes them into a dependency, and an impediment to teams delivering rapidly. Architects might struggle with finding their new role in an environment where autonomous feature teams are rapidly delivering. They need to transition to being a coach and mentor. They need to teach teams how to create good architecture, and eventually empower the teams to make their own architectural decisions. Pattern - Architect as Coach
  108. 108. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  109. 109. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  110. 110. Unix Principles: 1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”. 2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. 3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. 4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them. Doug McIlroy, E. N. Pinson, B. A. Tague (8 July 1978). "Unix Time-Sharing System Forward". The Bell System Technical Journal. Bell Laboratories. pp. 1902–1903. None of This Is New!
  111. 111. Books
  112. 112. Thanks!
  113. 113. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  114. 114. To-Do Doing (1) Done Intro Guiding Principles Coupling Changeable Decisions Y.A.G.N.I. Frequent Delivery Legacy Apps People Patterns Conway’s Law Work Together Wrap Up
  115. 115. Questions?

×