Architecture Workshop（架构工作坊）

知识库位置：FDE Knowledge Base/07 Playbooks/05-Architecture-Workshop.md

Playbook Metadata（手册元数据）

Playbook ID: PB-005

Stage（所属阶段）:
Solution Design（方案设计）

Primary Goal（主要目标）:
Build shared understanding of target architecture and key decisions.
（对目标架构与关键决策形成共同理解。）

Typical Duration（典型时长）:
90–120 minutes

Primary Audience（主要使用者）:
FDE + Solution Architect + Customer IT

Difficulty（难度）:
Advanced（高级）

Status: Core
Version: v0.1

Objective（目标）

Architecture Workshop 的目标不是：

现场把每个组件都设计完。

而是：

对目标架构形成共同理解。
明确关键技术决策。
识别需要验证的风险。
确认 Prototype（原型）/ Pilot（试点）如何实现。

Inputs（输入）

进入 Workshop 前需要：

Business Use Case（业务用例）
Requirements（需求）
Target Workflow（目标工作流）
System Landscape（系统全景）
Data Inventory（数据清单）
Security Constraints（安全约束）
Technical Risks（技术风险）

Participants（参与者）

FDE
Solution Architect（解决方案架构师）
Engineering Lead（工程负责人）
Customer IT（客户信息技术部门）
Security（安全团队）
Data Owner（数据责任人）
Business Representative（业务代表）

Workshop Flow（工作坊流程）

Step 1 — Restate the Problem（重述问题）

第一张图不要是架构。

先写：

User（用户）:
Problem（问题）:
Business Outcome（业务结果）:
Constraints（约束）:

Step 2 — Define Boundaries（定义边界）

明确：

哪些系统属于 Solution（解决方案）
哪些是 External Dependency（外部依赖）
哪些是 Existing Enterprise Systems（既有企业系统）

Step 3 — Select Architecture Pattern（选择架构模式）

参考：Reference Architecture Selection Guide（参考架构选型指南）

例如：

Knowledge Problem（知识问题）
→ RAG（检索增强生成）

Known Process + AI（已知流程 + AI）
→ Workflow Automation（工作流自动化）

Dynamic Actions（动态动作）
→ Agent（智能体）

Step 4 — Draw High-Level Architecture（画总体架构）

先控制在：

5–10 major components（5–10 个主要组件）

避免一上来画 50 个框。

Step 5 — Data Flow（数据流）

明确：

Where does data enter?（数据从哪里进入？）
Where is it transformed?（在哪里转换？）
Where is it stored?（存储在哪里？）
Who can see it?（谁能看到？）
Where does it leave?（从哪里离开？）

Step 6 — Identity & Security（身份与安全）

必须明确：

User（用户）
↓
Identity（身份）
↓
Authorization（授权）
↓
Data / Tool（数据 / 工具）

Step 7 — Failure Paths（失败路径）

逐个问：

LLM（大语言模型）不可用？
CRM 不可用？
Search（搜索）不可用？
Queue（队列）积压？
Human Reviewer（人工复核员）不在？

Step 8 — Key Decisions（关键决策）

记录 ADR（Architecture Decision Record，架构决策记录）。

例如：

Use RAG instead of fine-tuning.（用 RAG 而非微调。）
Use workflow instead of autonomous agent.（用工作流而非自主智能体。）
Use batch instead of streaming.（用批量而非流式。）

模板见 Architecture Decision Record Template（架构决策记录模板）。

Step 9 — Prototype Boundary（原型边界）

明确：

哪部分现在验证？

Prototype 不应该把整个 Production（生产）Architecture 全做完。

Outputs（产出）

High-Level Architecture（总体架构）
Data Flow（数据流）
Integration Map（集成图）
Security Model（安全模型）
ADRs（架构决策记录）
Technical Risks（技术风险）
Prototype Scope（原型范围）
Open Questions（待解问题）

Facilitation Principle（引导原则）

如果团队开始争论具体技术：

Kafka 还是某个 Queue（队列）？

先问：

这个组件需要满足什么业务和非功能要求？

避免工具先行。