I highly recommend "Practical (a.k.a. Actually Useful) Architecture" video by Stefan Tilkov where the author presents 10 recommendations for pragmatic architectural work:
✏️Choose your perspective(s) consciously. The author identifies 3 main architecture perspectives:
- Business domain: How the system is divided into logical modules (boxes).
- Integration: How different modules communicate with each other.
- Technology: The technology choices within the boxes.
These perspectives are usually maintained by different people, changed with different frequencies and for different reasons. It's crucial to focus on the right perspective so that decisions at one level don't negatively impact another. For example, a framework usage shouldn't affect integration contracts to prevent dependencies on the wrong level for the wrong reason.
✏️Explicitly architect your team setup. Define team topology based on the domain modules.
✏️Match your organizational setup to project size:
- Single team. Some tasks are architectural with no explicit architecture roles.
- Small number of collaborating teams. Hold an architecture committee meeting once a week with members from each team.
- Large number of independent teams. Establish explicit architecture roles, possibly forming a separate architecture team.
✏️Don't be afraid to decide things centrally. Some decisions need to be made centrally:
- What is centralized vs. what is left to individual teams.
- Team responsibilities.
- Any aspects relevant to more than one team.
- Global policies and strategic aspects.
✏️Pick your battles wisely. Avoid trying to address everything simultaneously. Focus on the most important aspect first and plan other aspects for later.
✏️Enforce the least viable amount of rules, rigidly. Provide teams with the autonomy they need to get things done, but define clear boundaries to avoid chaos. For example, while the choice of programming language can be a team decision, API standards should be centralized. Define a very few critical rules but enforce them strictly.
✏️Balance prescriptive vs. descriptive architecture. The goal of architectural work is to produce decisions, not just documentation. Good decisions might not satisfy everyone, but decisions that do are often bad. Make firm decisions and encourage others to follow them.
✏️Don't aim for perfection - iterate. Architecture is not about creating a snapshot in time but about managing a series of changes. Build systems so they can evolve over time and continuously re-evaluate past decisions.
✏️Architect for delivery flow as much as for runtime quality. Design both the runtime environment and the development pipeline. The quality of a system's architecture is proportional to the number of bottlenecks limiting its evolution, development, and operations. More bottlenecks mean a worse architecture.
✏️Be boring & do more with less. Prefer simple, straightforward solutions to overly clever and complicated cool approaches.
The video offers excellent advice and practical recommendations, with nearly every idea and statement being truly significant. I'll conclude the review with a quote that I really like:
If you get architecture wrong, everything breaks down - yet even if you get it right, success is not guaranteed
#architecture