System Architecture Overview — The Skeleton You Decide First

About this article

This article is the entry point of the “System Architecture” category in the Architecture Crash Course for the Generative-AI Era series. It surveys the entire skeleton — hardware, software, network — together. In construction terms it corresponds to the foundation and the structural framing, and across all architectural layers it is the one where redo-ing is the hardest.

This article surveys what gets decided here, why it must be decided first, and the AI-driven-development selection criteria.

A full list of all articles in this category, with summaries and learning points, is available at the following page.

System Architecture — Article Indexen.senkohome.com/arch-intro-index-system/

What is system architecture in the first place

Imagine a house’s foundation work. If you say “actually, I want a basement” after the foundation is poured, redoing the foundation costs almost as much as rebuilding the house. You can change the floor plan and wallpaper later, but the foundation and structural framing must be decided correctly from the start.

System architecture is the domain that decides the overall skeleton encompassing hardware, software, and network. Cloud or your own data center, OS, DB, container platform, network design — of all architectural layers, this is the one where redo is hardest.

If you neglect system architecture, situations like switching cloud vendors mid-project = effectively “rebuilding” arise, and every other design decision is reduced to nothing.

Why it is decided first

This domain is a concentration of One-way Doors (Bezos’s term for “decisions hard to reverse”). Downstream judgments are bound by what’s settled here. Changing the skeleton later means tasks like:

• Switching cloud vendor mid-project is essentially “rebuild from scratch.”
• Switching between on-prem and cloud later is also major construction work.
• OS and DB product changes propagate widely.

Even on small projects, deciding the broad strokes up front is the rule. “We’ll think about that later” becomes more fatal the smaller the project — by the time code and operations have grown into the skeleton, peeling them apart is the work.

The mindset of “MVP, so just wing it” turns into the most expensive choice in retrospect. System architecture should be sketched out in week 1 of the project; deferral is most fatal at smaller scale.

What gets decided — three groups

For each of the following, articulate your project’s answer in 1-2 sentences. Leaving them ambiguous now will always come back as “why did we decide that?” later.

The decisions in this domain split into three groups:

The first group is the platform itself.

This layer is covered in articles 01-06 below. The substrate of all later decisions — get this wrong and everything downstream goes off the rails.

The second is network, security and operations.

Network, security, and monitoring are extremely difficult to bolt on after the fact; they need to be built into the design. Articles 07-09 in this category.

The third is BCP, cost and operational automation.

Business continuity and cost management appear in articles 10-11. CI/CD, IaC, and configuration management — the development-process layer — are consolidated in the separate “DevOps Architecture” category.

System configurations by scale and phase

Optimal system architecture changes with org scale. The conclusion up front: from individuals to mid-sized SaaS, single cloud + managed services + IaC is the default. Hybrid and multi-cloud should be limited to large enterprises in 2026.

The practical floor for multi-cloud or hybrid is 3+ dedicated infra engineers. Going below that just melts the team in operations.

The courage to lean on a single cloud is what reconciles operations with AI productivity. Startups copying enterprise topologies is a textbook failure pattern — they exhaust themselves in months and end up rolling back. An out-of-scale architecture is purely debt.

AI decision axes — Can it be expressed as code?

IaC-managed infrastructure is “readable code” for AI

Infrastructure defined in Terraform or CDK is treated as ordinary source code by AI. VPC configuration, security-group rules, and IAM policies all exist as text files, so AI can understand the topology and submit change proposals as PRs.

In contrast, infrastructure built through the management console GUI is invisible to AI. Configuration is only accessible via API, change history can’t be tracked, and it falls outside the scope of AI review and auto-remediation.

Why a single cloud is structurally advantaged for AI adoption

AWS’s information volume is several times that of Azure and GCP, and AI training data follows suit. For instance, there are enormous public samples of AWS IAM policies and CloudFormation templates, so AI can generate accurate code. A multi-cloud configuration forces dual management of each vendor’s IaC, IAM, and network design, doubling the context load on AI as well.

Multi-cloud is justified only when there are regulatory requirements, M&A constraints, or a specific service’s exclusive advantage (e.g., BigQuery).

The judgments that “feel intuitively right” deserve the most scrutiny. The habit of always cross-checking against scale and assumptions levels you up by a tier within a year as a system architect.

Pitfalls and forbidden moves

Of the forbidden moves covered across the individual articles, here are the six that matter at chapter level.

Summary

This article served as the entry point of the “System Architecture” category, surveying the domain.

System architecture is the least reversible domain. Locking down scale, upstream-first ordering, IaC, and security as standard equipment at the start determines your operations cost and AI-era readiness for the next 5-10 years.

The next article begins the deep dive: how to choose the application form (Native / Web / Hybrid).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.