5 Things You Should Know About Software Architecture: Simon Brown

Let’s start with a myth. Architecture doesn’t necessarily mean a big design upfront

  • This was probably true in the waterfall days but not any more.
  • These are two extremes on the spectrum. Big designs upfront vs no designs at all. The first one is dumb but the other one is probably dumber.
  • We should start with just enough architecture design. How do we find out how much is enough?
    • As most things do, this depends on the use case. It depends on whether the application that you are building is for a,
      • Big enterprise
      • Startup with a new product
      • Or something in the middle
    • Evolutionary design
      • Creating a static (dead) architecture document that no one even refers to anymore is not of much use.
      • The design should represent the current state of the application and it evolves with the changing requirements.
  • Architecture represents the significant decisions, where significance is measured by cost of change - Grady Booch
    • Significant
      Programing Language, platforms
      Monolith, microservices, or modular monoliths
    • Less significant
      • Tabs or spaces
      • Brace positions
      • You get the idea
  • Concrete experiments
    • Test the architecture with actual code
      • Spike, tracers, vertical slice
    • Identify and mitigate the highest priority risks (RUP)

Architecture is not something reserved just for large scale systems like the International space station’s control system. Every application has an architecture, whether or not it is well designed and thought out.

  • Perils of not designing an architecture.
    • Chaos
    • Big ball of mud
    • Spaghetti code
  • Every team needs technical leadership.

An Architects role - Coding, coaching and collaboration.

  • Not to be an Aaas - (Architecture as a service). Building an architecture should be a collaborative process, not a directive one.
  • It is a continuous role, when you stop designing the architecture it starts designing itself.
  • Pair Architects
  • Soft skills
  • Architects should write production code. It’s better to have a hand on the pulse.

Architecture Documentation

  • UML is not necessary. Nobody likes it anyways. Then what should we use? Whiteboards?
  • A ubiquitous language (Not related to DDD)
  • C4 model Link Link, https://c4model.com/
    • Context, containers, components and code
    • Different diagrams at different levels of abstraction
    • Diagram as code Link, https://structurizr.com/

Architecture enables agility

  • We have all been there. Started with the best intentions, but somewhere along the way the code turned into a big ball of mud.
  • Well structured and highly modular applications are easy to change and manage.

Source,

GOTO 2020 • Five Things Every Developer Should Know about Software Architecture • Simon Brown, https://www.youtube.com/watch?v=9Az0q2XHtH8

A recent book by Simon, https://softwarearchitecturefordevelopers.com/

HashJar

HashJar