Learning Roadmap — Where to Start, by Role

About this article

This article is the learning roadmap for the Architecture Crash Course for the Generative-AI Era series. It cuts the 80+ articles into five reading routes by reader type so you can answer “where do I start?” for yourself.

The shared move across all routes: read the two “everyone reads these” articles first, then enter your specialist route.

flowchart TB
    START([Common start<br/>IT Architect Overview + Glossary])
    A[A: Manager / PM<br/>4-6 articles]
    B[B: Backend<br/>System -> Software -> App]
    C[C: Frontend<br/>Frontend 8 + API + Auth]
    D[D: New grad / 1-3yr<br/>Category overviews only]
    E[E: Aspiring architect<br/>3-phase full coverage]
    START --> A
    START --> B
    START --> C
    START --> D
    START --> E
    classDef start fill:#fef3c7,stroke:#d97706,stroke-width:2px;
    classDef mgr fill:#dbeafe,stroke:#2563eb;
    classDef eng fill:#f0f9ff,stroke:#0369a1;
    classDef arch fill:#fae8ff,stroke:#a21caf;
    class START start;
    class A mgr;
    class B,C,D eng;
    class E arch;

Everyone starts here (common start)

Whichever route you pick, I recommend reading these two first:

• What an IT Architect Actually Does — what an architect does, ADRs, One-way Door reasoning.
• Glossary — a single reference for the specialist terms used across the series.

Read these two before entering the route closest to you. Whichever route you take, the vocabulary and decision frame from these two will be your foundation.

The common-start pair is “the map and compass for reading everything else.” Skipping them makes the specialist articles feel abstract.

Route A — Managers, PMs, consultants

For people who “want the map and the decision criteria, not the technical detail.” The route is designed so that 4-6 articles give you the full picture.

The core of this route is the enterprise view, the solution view, and the cost / vendor selection lenses. You don’t need to dive into technical detail — what you need is the basis for decisions.

Reading order:

1. Enterprise Architecture Overview — architecture as a corporate map.
2. Bridging requirements to design — turning business requirements into design.
3. Non-functional requirement design — quantifying availability, performance, security.
4. Estimation and ROI — investment-recovery thinking for getting approvals.
5. Cloud vendor selection — the main axes of vendor selection.
6. Cost management — why cloud bills explode, and how to control them.

Once you have the decision criteria, conversations with engineers go a layer deeper, and the quality of your proposals and approvals shifts. For managers, even just 1-3 of these articles should noticeably change the resolution at which you sit through internal technical decisions.

Route B — Backend engineers

For specialists who want to “design across the system, not just my layer.”

Read from outside-in: System -> Software -> Application. This way the assumptions of each decision are settled by the time you reach the next article.

Reading order:

1. System Architecture, all articles (01-11) — infra, runtime, cloud, network, security foundation, monitoring, BCP, cost management.
2. Software Architecture, all articles (01-07) — language, framework, API, transactions, auth sessions.
3. Application Architecture, all articles (01-04) — class design, domain, naming, errors.
4. Data Architecture — focus on datastore selection and modeling.
5. DevOps Architecture, all articles (01-14) — development process through SRE, end to end.
6. Security Architecture — focus on authentication, authorization, encryption.

10 -> 20 -> 25, working from outside in, lets each article hand the next one a settled set of assumptions.

For backend specialists, anything outside backend is usually thin. The three areas worth investing extra time in are Data, Operations, and Security.

Route C — Frontend engineers

For people who want to “see architecture from frontend’s neighborhood.”

Frontend selection couples tightly to “API,” “Auth,” and “Hosting” on the outside. Knowing the adjacent territory makes frontend decisions sharper.

Reading order:

1. Frontend Architecture, all articles (01-08) — hosting, rendering, state management, CSS, BFF, SEO.
2. API design — when to use REST / GraphQL / gRPC.
3. Auth and sessions — how to hold login state.
4. Auth design and IAM (Security) — the policy layer.
5. Application form, deployment model — where things actually run.
6. Monitoring and observability — the link to Core Web Vitals.

Going through this route lets you see how decisions chain together behind the screen. The most important thing for frontend engineers is the role split between policy design and implementation tech around auth.

Route D — New grads and engineers in their first 1-3 years

For people who “can write code but have not had to design” — a fast pass through the concepts.

The goal is to read just the “Overview” of each category and walk away with “there are choices.”

Reading order:

1. IT Architect Overview — the big-picture map.
2. System Architecture Overview -> Application Form.
3. Software Architecture Overview -> Programming Languages.
4. Data Architecture Overview -> Datastore selection.
5. Security Architecture Overview.
6. DevOps Architecture Overview.
7. Naming, code conventions, error handling — directly tied to tomorrow’s code.

Don’t try to go deep at first. Knowing what exists is enough. Trying to deep-dive every category at once is how new grads bounce off. Come back to the relevant article when something in real work demands it.

In your first few years, you spend a lot of time writing code without knowing “why my senior picked that.” This route’s goal is to let you put your seniors’ decisions into your own words.

Route E — Aspiring architects (mid-career engineers)

For people with “design experience that has not yet been systematized.” Three phases of slower reading.

Phase 1 (foundation)

The four core technical categories:

1. IT Architect Overview
2. System Architecture, all articles
3. Software Architecture, all articles
4. Application Architecture, all articles

Phase 2 (widen the radius)

The four categories specialists tend to be thin on:

5. Data Architecture, all articles
6. Security Architecture, all articles
7. DevOps Architecture, all articles (process + SRE end-to-end)
8. Frontend Architecture, all articles

Phase 3 (upstream and management)

Connect technical judgment to business judgment:

9. Enterprise Architecture, all articles
10. Solution Architecture, all articles

The 10 -> 20 -> 25 -> 40 -> 50 -> 60 -> 30 -> 70 -> 80 sequence is the canonical route: start in the technical detail, finish at the business interface.

The hardest jump from mid-career engineer to architect is explaining technical decisions in business language. Pushing through Phase 3 builds that bridge.

How to read efficiently

A few tips for actually absorbing the content:

• Follow the related-article links at the end of each article, ping-pong between articles, and the knowledge stitches together.
• Look up specialist terms in the glossary first, then return to the article (every article also has a one-liner the first time a term appears).
• Apply each article’s “What you must decide” checklist to your own project. A consolidated, fillable version lives at Architecture Decision Checklist, where you can fill in answers, save them in the browser, and export to Markdown.
• For self-checks, Architecture Decision Quiz (8 questions) is available.
• One article per day, mapped to your own work sticks much better than binge-reading.

I follow my own “one article per day” rule on technical books too. Binge-reading often ends in “I felt like I read it” with no retention.

Self-check after reading

If you can explain the following from memory, consider that category covered. Retention comes down entirely to “can you reconstruct it in your own words?”

• List three examples of One-way Door decisions an architect makes.
• Explain the selection axes between monolith / microservices / modular monolith.
• Distinguish cases that need ACID consistency from cases that don’t.
• Explain the difference between authentication and authorization, and why passkeys are preferred.
• Explain the difference between SLO / SLI / SLA and the meaning of an error budget.
• Explain what it means to define non-functional requirements numerically (availability, performance, operations).
• Explain when to use RBAC / ABAC / ReBAC.
• Pick the right one out of REST / GraphQL / gRPC for a given situation.

If you can’t yet explain it to someone else, you’re probably still in the “felt like I read it” zone. Try explaining it to a teammate or junior, present one topic at an internal study session, write a blog post — output-driven learning spikes retention.

Summary

This article gave you the learning roadmap for Architecture Crash Course for the Generative-AI Era, in five reader-type routes.

Picking just the articles you need out of 80+ is hard, so use this article as the guide.

Retention boils down to “can you reconstruct it in your own words?” Make output happen after reading.

Next we enter the main content for each category. If you’d like to nail the specialized terms first, the next article — the Glossary — is for you.

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.