---
title: "The Cloud Solution Architect role"
chapter: "00"
---

# The Cloud Solution Architect role

A Cloud Solution Architect turns business goals into a safe, useful cloud design.

## Explain it like I am five

Imagine a company is a busy city. SAP is the warehouse, Salesforce is the sales
office, Workday is the people office, and the customer website is the shop.
The architect does not personally build every room. The architect decides where
the roads go, who gets keys, what happens when a road closes, and how much the
city can afford.

## The role in one loop

1. **Discover** the business outcome, users, data, rules, scale, and deadlines.
2. **Design** a few viable options, including failure and security behavior.
3. **Decide** with stakeholders by making trade-offs visible.
4. **Enable** delivery with diagrams, guardrails, examples, and a roadmap.
5. **Verify** the result with tests, telemetry, cost data, and reviews.
6. **Improve** after learning from production.

## What this role owns

| Responsibility | The practical question |
|---|---|
| Architecture | What parts exist, and how do they communicate? |
| Integration | How do SAP, Salesforce, Workday, data, and channels exchange truth? |
| Security | Who may do what, and how will we know? |
| Reliability | What fails, how far does failure spread, and how do we recover? |
| Scalability | What happens when demand becomes ten times larger? |
| Cost | What business value do we buy with each major cost? |
| Sustainability | Can we do the same work with fewer resources? |
| Communication | Can engineers and executives understand the decision? |

## What the role does not mean

It is not memorizing hundreds of service names. It is not drawing a diagram and
leaving. It is not choosing a fashionable technology before discovering the
problem. A strong architect can say: “Here are the constraints, here are three
options, here is the decision, and here is how we will prove it works.”

## Role evidence to build

- A one-page context diagram and a deployment diagram.
- An architecture decision record with alternatives and consequences.
- A threat model and a least-privilege access model.
- A failure-mode table with RTO and RPO.
- A monthly cost estimate with the largest cost drivers.
- An observability plan with service-level objectives.
- A migration roadmap with reversible steps.

## Your learning target

By the end of this fieldbook you should be able to take a scenario, ask the
missing questions, select a small set of AWS services, explain the trade-offs,
and defend the design against the six AWS Well-Architected pillars.