Let’s start by busting a myth. Architecture doesn’t necessarily mean a big design upfront
This was probably true in the waterfall days but not any more.
Large designs upfront or no designs at all. These are two extremes on the spectrum. 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
Another notable thing is that the design should be alive and evolving.
- 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
- At the begining focus on the significant things like the, Programing Language, platforms. The choice between monolith, microservices, or modular monoliths.
- Less significant issue like Tabs or spaces, Brace positions etc can be handled later.
Validate your architecture with concrete experiments.
- Test the architecture with actual code
- 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 in the team as well as the code base
- Big ball of mud components
- Spaghetti code
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 — just like pair programmers
- Soft skills
- Architects should write production code. It’s better to have a hand on the pulse of the code base.
Architecture Documentation
UML is not necessary. Nobody likes it anyways. Then what should we use? Whiteboards?
- A ubiquitous language
- C4 model Link
- Context, containers, components and code
- Different diagrams at different levels of abstraction
- Diagram as code Link, Structurizr
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.
This article is based on a talk given by Simon Brown.
Source, GOTO 2020 * Five Things Every Developer Should Know about Software Architecture * Simon Brown
A recent book by Simon, Software Architecture for Developers
Originally published at https://www.hashjar.dev.
