SalienceNotes.dev
Writing / Article

The 7 Golden Rules of System Architecture

A structured set of ideas and general guidelines that collectively define and guide IT solution architecture, focusing on scalability, security, and resiliency.

Solly · 3 min read

“Everything should be made as simple as possible, but not simpler.” ~ Albert Einstein

This is another blog post about IT solutions design principles, which are general guidelines. Whether you’re a seasoned pro or just starting out, get ready to discover some fresh ideas that will take your IT solution architecture game to the next level!

Use first principles thinking to break these rules down and understand why they work from the ground up.

Enjoy!

When it comes to solution design principles, we all have some ideas in mind, right? Here are some of mine.

You don’t need all of them, but some of them are just necessary. However, each of them should be clearly related back to business objectives and key architecture drivers:

Key Concept: Scaling Methods (Horizontal vs. Vertical)

Horizontal: Scale Out

Load Balancer

Instance 3

Instance 1

Instance 2

Vertical: Scale Up

Add CPU/RAM

Small VM

Large VM

  • Scalability - a solution must be capable of (dynamically) increasing itself according to the demand (horizontal or vertical). We’re in 2023 now people, and this is crucial when planning cloud native scalability and modernization paths.
  • Security (all about CIA) - a solution must be secure regarding the communication between components, data at rest/in motion, accessibility of service administrations etc.
  • Resiliency - a solution must be capable of being stable also at times of intense load and can recover from exceptional states.
  • Fail-over capability - a solution must be able to continue working even if instances of components are not available.
  • SPOF (Single Point of Failure) - it must be clear which components are crucial to mitigate potential risks.
  • Accessibility, Availability - a solution must be deployed as close as possible to users (low latency) and must guarantee a high up-time SLA.
  • Ownership - All components must have clear ownership / accountability.
  • Build comprehensive documentation (HLD/LLD) - Ensure design layouts and diagrams are well-documented (see a practical example in my post on real-world system design for this static website).
  • Technology independence - a solution should be independent of specific technology and should be able to operate on a variety of technology platforms.

So, besides those functional requirements, there are several other things that a solution architect can consider listed as below:

  • Cost optimization - finding the perfect mix of technologies and infrastructure to solve the problem, and to spend a minimum of money. (Reuse before buy, buy before build)
  • User Experience - supporting the UX team to find the ideal user interface if you are building a product/process/service or software, guiding users intuitively through the solution.
  • Performance - support with load testing to ensure the expected number of concurrent users and client services.

There are more based on TOGAF, but hey, those are a structured set of ideas that collectively define and guide our organization, from values through actions and results.

Thanks for reading my blog!