案例09｜HR Policy Chatbot：從簡單 REST Endpoint 到五層 Enterprise Architecture

一、案例定位

本案例依原書第 4 章 A Tale of Two Architectures 重組，並非原書正式案例研究。

比較部門級 HR Policy Chatbot 與 Enterprise Architecture，理解規模化後為何需要 Load Management、API、Processing、Storage、Monitoring 等專門層。

二、學習目標

區分 Simple Architecture 與 Enterprise Architecture。
掌握五個主要架構層。
理解 Layered Architecture 如何支援可靠性與 Scale。

三、案例情境

原書先描述簡單 HR Chatbot：Web Chat、Basic Authentication／Session、Simple REST Endpoints、直接呼叫單一 AI Model、Basic Prompt。企業級版本則改為多層專門服務，讓流量、身分、文件、Prompt、搜尋、模型、快取、儲存與監控各自管理。

四、開始資料

Enterprise Layer	主要職責	代表能力
Load Management	流量分配與彈性 Scale	Load Balancer、Closest Server、Failure Redirect
API Layer	企業入口與服務治理	Authentication、Session、RBAC、Document Service
Processing Layer	AI Intelligence at Scale	Prompt Management、Search、Model Pool、Response Cache
Storage Layer	Enterprise Data Management	Document Store、Audit Logs、Vector Store Cluster
Monitoring Layer	可靠營運	Health、Availability、Alerts、Performance Analytics

五、Excel／AI 分析方法

Excel 可建立元件清冊與 Layer Mapping，記錄每層服務、Owner、SLA 與依賴；AI 可協助檢查遺漏能力，但不能因存在五層就宣稱架構已 Production-ready。

六、計算結果

本案例為架構比較，原書沒有固定元件數或容量門檻。

七、結果分析與管理解讀

Enterprise Architecture 的複雜度是用來處理真實規模問題，而不是單純堆疊元件。每一層都對應部門級簡單架構在 Scale、Security、Reliability 上的缺口。

八、AI 提問詞

請把我的 HR Chatbot 元件映射到 Load Management、API、Processing、Storage、Monitoring 五層，指出缺失的 Enterprise Capability。只依現有架構資料判斷，不要自行宣稱已符合 Production Requirements。