Notes on Building Evolutionary Architectures, Support Constant Change by Neal Ford, Rebecca Parsons & Patrick Kua

Chapter 1: Software Architecture

• "An evolutionary architecture consists of three primary aspects: incremental change, fitness functions, and appropriate coupling."
• Inverse Conway Maneuver (p12)
  • Build cross-functional team to match an intended micro-service to have the team organized against the intended architecture.

Chapter 2: Fitness Functions

• Fitness Functions
  • May be useful to use a common term and have a common lens, but not a new concept.
  • Fitness Function Categories (p18)
    • Examples: Atomic v. Holistic, Triggered v. Continual, Static v. Dynamic, etc.
    • Would have liked to see more examples for common -ility use-cases.
    • Sample gaps at edX (which have come up before):
      • Code complexity
      • Dependency checking (see JDepend example, p30)
      • Performance
    • Potential Discussion (Robert Raposa): automation as a requirement for providing high value (versus docs or OEPs without teeth).
• "Without guidance, evolutionary architecture becomes simply a reactionary architecture."
• "Monitoring-driven development (MDD) is another testing technique gaining popularity. Rather than relying solely on tests to verify system results, MDD uses monitors in production to assess both technical and business health."  New Relic has a lot of functionality to support this.
  

Chapter 3: Engineering Incremental Change

• Example of introducing a new version of a service and automatically garbage collecting the old version when it is out of use.
  • Is this possible?  Is this worth the effort of automation?  What about legacy code?
  • Mentions "Version Services Internally", discussed on p119, but lacking details.
  • Potential Discussion (Robert Raposa)
• Feature Toggles
  • Reminder of using feature toggles to test in Production for individuals. (p35)
• Github Scientist (p37)
  • Interesting concept for refactoring and ensuring it works as it used to.
  • Potential Discussion (Robert Raposa)
• JDepend is mentioned for automating checks of coupling and dependency directionality; we can use snakefood and related tools to do the same in Python.  We already have some scripts in edx-platform that start to do this, we should automate them and expand on this. (Jeremy Bowman (Deactivated))
• "We prefer building unit tests to catch architecture violations over using strict development guidelines"
• Do we want to try using Simian Army and/or Conformity Monkey? (Jeremy Bowman (Deactivated))

Chapter 4: Architectural Coupling

• Architectural Quanta (p48)
  • "An architectural quantum is an independently deployable component with high functional cohesion, which includes all the structural elements required for the system to function properly."
  • I personally don't love the term (Robert Raposa).  IDA is the closest that edX might have to a term for this, but the architectural soundness isn't part of the definition of an IDA.
  • DDD "Bounded Context" is mentioned.  I prefer this term (Robert Raposa).
• Microservices (p68) (their exemplar)
  • Appropriate coupling (p72)
    • Typically two kinds of coupling: integration and service template.
    • "By defining the appropriate technical architecture coupling points in service templates, an infrastructure team can manage that coupling while freeing individual service teams from worrying about it."
  • Isolate failure
    • Circuit Breakers
    • Bulkhead Pattern
    • Other resources:
      • Netflix Hystrix Implementation
      • Google: Addressing Cascading Failures
    • Potential Discussion (Robert Raposa): Relates to new service maturity model.  In what cases is this good enough?

Chapter 5: Evolutionary Data

• "Architects sometimes err in trying to build an architecture with a smaller level of granularity than is natural for the business."
• "don’t take the name microservices too literally—each service doesn’t have to be small, but rather capture a useful bounded context."

Chapter 6: Building Evolvable Architectures

• Refactoring v Restructuring (p99)
  • Humorous Nit: They attempt to clarify the difference between these two terms, but they provide a definition for "refactoring" that contains the term "restructuring", but the definition doesn't use it the way they are trying to define "restructuring."
• Fluid v Guarded Dependencies (p118-119)
  • Sounds interesting.  Mentions tooling isn't available.  Could we automate more package updates than we do now?
• Version Services Internally (p119)
  • May make sense, but missing detail regarding how the logic is to "determine the context of the caller" to choose the version.  Mentions "request type".
• "Cycle time is the Continuous Delivery measure of engineering efficiency. Part of the responsibility of developers on projects that support evolutionary architecture is to maintain good cycle time."
• "Architects must vigilantly watch for situations where nonfunctional requirements break and retrofit the architecture with fitness functions to prevent future problems."
• "While Continuous Delivery practices don’t guarantee evolutionary architecture, it is almost impossible without them."
• "We encourage architects to start thinking of all kinds of architectural verification mechanisms as fitness functions, including things they have previously considered ad hocly."
• "Most developers would rather write a framework than use a framework to create something useful: Meta-work is more interesting than work."

• "All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections. --Dave Wheeler and Kevlin Henney"

• "The abstraction distraction anti-pattern describes the scenario where a project “wires” itself too much to an external library, either commercial or open source." - resolve via anticorruption layers.
  
• "Because frameworks are a fundamental part of applications, teams must be aggressive about pursuing updates."
• Guidelines for building evolutionary architectures
  • Make decisions reversible
  • Evolvable over predictable
  • Anti-corruption layer
  • Service template (shared libraries, etc)
  • Sacrificial architectures

Chapter 7: Evolutionary Architecture Pitfalls and Antipatterns

• Antipattern: Code Reuse Abuse (p128)
  • Reusing domain model code is risky.
• Goldilocks Governance (p134)
  • Small, Medium, and Large recommended technology stacks.
  • Makes sense that you'd want some balance other than a free for all.
  • Technology Radar
• Pitfall: Planning Horizons
  • "Beware of long planning cycles that force architects into irreversible decisions and find ways to keep options open. Breaking large programs of work into smaller, early deliverables tests the feasibility of both the architectural choices and the development infrastructure."
• Pitfall: Lack of speed to release

Chapter 8: Putting Evolutionary Architecture into Practice

• Product over Project (p144)
  • Mentions importance of organizing by product and not by project.
  • We do not do this and the pain is clear. It is not clear what pain or benefits we would see if we tried this.
• "The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor."
• Culture of Experimentation
  • Several good ideas in this section (Jeremy Bowman (Deactivated))
  • "The real measure of success is the number of experiments that can be crowded into 24 hours. --Thomas Alva Edison"
• Start with low-hanging fruit
• "All the practices we call incremental change improve automation and efficiency."