[Video Note] Charles Aylward - Practical Solution Architecture

# 第 1 節：Introduction ## Introduction ### 成為解決方案架構師的轉職動機與導向 * 適合希望從資深開發者轉職為解決方案架構師的人 * 導入如何理解並實作滿足企業需求的解決方案架構 * 提供導師制學習與實務指導 ### 講師背景簡介 * 擁有約 29 年開發經驗，歷經各種規模的企業 * 9 年擔任解決方案與企業架構師 * 熟悉從業務需求出發的架構設計與實作 ### 解決方案架構的核心重點 * 如何理解業務需求並轉換為技術解決方案 * 提出多種技術選項供企業評估實作方案 * 採用解決方案架構的原則、模式與實務 ### 現代架構實作經驗分享 * 熟悉微服務、容器、Kubernetes 等現代架構 * 曾實作 AWS Fargate、Azure 及 AWS 等雲端平台解決方案 * 擁有跨平台、跨環境（雲端/地端）的實作經驗 ### 課程涵蓋與價值 * 不侷限於特定平台（AWS、Azure、GCP 等） * 強調通用的解決方案架構設計與實務 * 適用於地端部署、雲端部署與各種開發流程（如 Agile） ### 對目標學員的建議與支持 * 協助評估是否持續走技術路線或轉向管理職 * 針對已有開發經驗者提供架構師所需的能力轉換 * 提供與講師互動的機會，強調實戰導向的學習模式 ## Prerequisites and Course Objectives ### 課程概覽與教學方式 * 本課程為實務導向的解決方案架構課程 * 使用專案團隊或 Scrum 團隊為情境，模擬真實情境學習 * 各角色將在後續影片中介紹，並說明各自負責的架構部分 ### 適合對象與必要條件 * IT 領域工作經驗至少 8 年（建議 10–15 年以上） * 至少 8 年以上應用程式開發經驗，不限語言 * 熟悉軟體設計技術（如 UML） * 熟悉資料庫技術（如 SQL 或其他關聯式資料庫） * 熟悉整合技術（如 API、ESB、ETL 工具） * 基本 IT 安全知識（如認證、授權、加密、雜湊等） * 具備網路知識（DMZ、協定、子網等） * 熟悉基礎設施（Windows Server、Linux、Unix 及部署流程） ### 架構師的核心能力 * 必須能與 IT 與業務各方利害關係人溝通 * 應具備說服與引導能力，能夠協助並領導他人 * 具備廣泛知識背景，為全方位協作角色 ### 課程需求與學習資源 * 一台個人電腦 * 穩定的網際網路連線 * 寫筆記工具（白板、筆記紙等） ### 課程目標與內容架構 * 探討解決方案架構實務與基礎原則 * 涵蓋建模技術、架構產出物、範本與文件使用方式 * 說明如何與利害關係人合作 * 建立一個實際的解決方案架構文件，逐步完成 * 展示雲端（Azure）與地端部署架構模型與流程 ### 最終作業與學習成效 * 課程末需完成一份完整的解決方案架構文件 * 將針對每個部分提供改進建議與實務回饋 ### 附加資源與導師支持 * 提供架構視覺化模板與完整範例文件 * 分享講師自身在 Agile 團隊擔任架構師的經驗 * 教授在 Scrum 團隊中擔任架構師的角色與日常活動 * 提供導師指導，協助學員完成職涯轉型 ### 鼓勵參與 * 課程包含豐富實務內容與導師支持，適合希望轉型為架構師的開發者加入學習旅程 # 第 2 節：Software Architecture Practices ## Enterprise Architecture vs Solution Architecture ### 架構師類型總覽 * 本段目的是說明各類型架構師的區別，特別是企業架構師與解決方案架構師 * 透過建築領域的類比幫助理解角色差異 ### 企業架構師（Enterprise Architect） * 類比為城市規劃師，負責整體策略與藍圖規劃 * 著重於企業的全貌與長遠規劃 * 涉及所有應用系統、商業流程與 IT 基礎設施 * 將企業策略與 IT 系統對齊，屬於戰略層級的角色 ### 解決方案架構師（Solution Architect） * 類比為建築師設計單棟建築 * 專注於特定業務問題的解決方案設計 * 涉及商業面、資料面、系統與技術面整合 * 負責將需求轉換為技術可行的架構方案 ### 其他常見架構師類型（依組織而異） * **業務架構師（Business Architect）**：聚焦業務流程與價值鏈設計 * **領域架構師（Domain Architect）**：專精於特定領域如零售、金融等 * **基礎設施架構師（Infrastructure Architect）**：專注於伺服器、網路、儲存等 * **資安架構師（Security Architect）**：負責資安政策、控管與實作架構 * **雲端架構師（Cloud Architect）**：根據雲端平台（如 AWS、Azure）設計雲端解決方案 * **應用架構師（Application Architect）**：專注於應用系統的架構設計與開發標準 * **資料架構師（Data Architect）**：設計資料結構、倉儲、流通與治理 ### 後續內容說明 * 未來章節將進一步說明解決方案架構師的詳細內容 * 包含 TOGAF 架構框架如何應用於解決方案設計 ## IT Architecture Frameworks ### 架構師應理解的架構框架 * 解決方案架構師需具備對各種企業架構框架的基本認識 * 架構框架有助於標準化設計流程與產出物 ### TOGAF（The Open Group Architecture Framework） * 免費開放給組織使用 * 包含完整方法論與支援工具，用以發展企業架構 * 架構開發方法（ADM）定義建構流程、原則與建構區塊 * 架構內容框架：定義交付物、構件與建構區塊 * 參考模型：提供平台服務、業界架構模型範本 * 架構連續體：從抽象概念進化到具體、可重用的組織資產 * 架構能力框架：定義實作架構功能所需的組織結構、角色與技能 ### Zachman Framework * 為分類與組織設計產出物的邏輯結構 * 問題維度：What、How、Where、Who、When、Why * 觀點維度：Scope（範圍）、Business Model、System Model、Technology Model、Detailed Representation * 採用工程領域的設計分類方式，應用於資訊系統建構 ### FEAF（Federal Enterprise Architecture Framework） * 由美國聯邦政府於 2006 年制定 * 整合策略、業務與技術管理 * 支援組織在設計與績效改進中的整體協調 ### Gartner 架構實務 * 定義企業架構最佳實務，整合於顧問服務流程中 * 非框架式，強調實務導向與商業價值鏈連結 ### ArchiMate * 架構建模語言，由 The Open Group 推出 * 區分為：業務層、資料層、應用層與技術層 * 支援展示資訊流、行為、架構與部署結構 * 雖具備完整建模能力，但學習曲線較高，本課程不採用 ### C4 Model（本課程採用方式） * 簡單易懂的解決方案建模方式 * 層級劃分：Context、Container、Component、Code * 聚焦於使用者、Web 應用、API、資料庫、服務等互動關係 * 本課程將實作實例並使用 Draw\.io 工具建模 ### UML（Unified Modeling Language）基礎 * 傳統系統設計建模工具 * 行為圖：Use Case、Sequence、Activity、Interaction、Timing 等 * 結構圖：Class、Component、Object、Package、Composite Structure 等 * 架構層常用 Use Case、Sequence Diagram、Component Diagram 與 Class Diagram 作為輔助說明工具 ## 測驗：Enterprise Architecture vs Solution Architecture ## 測驗：IT Architecture Frameworks Knowledge --- # 第 3 節：Solution Architecture Fundamentals ## Introduction to this section ### 課程階段提醒與學習方向 * 即將進入解決方案架構的核心基礎教學 * 理論階段雖然較重，但對理解與實作完整架構非常關鍵 * 目標是能依據業務需求，產出可交付的詳細解決方案架構 ### 講師持續投入與課程內容更新 * 課程內容將持續擴充，依據學生問題與反饋新增實務內容 * 講師過去在 Udemy 上已有相關教學經驗，並承諾投入更多細節 ### 關於課程評價 * 鼓勵學員給予正面評價，作為講師持續產出內容的動力 * 提到對課程有高度投入與期待，期望建立高品質學習資源 ## Architecture Organization, Deliverables, Stakeholders and Domains ### 解決方案架構學習方向 * 理解理論是進行實務設計的必要前提 * 本課程將透過實際案例進行解決方案架構練習 * 架構設計需根據業務需求，逐步建立完整解決方案 ### 架構團隊組織結構 * Chief Architect 負責領導整體架構策略 * Domain Architect 專注於特定業務領域（如銷售、財務、營運） * Solution Architect 設計符合業務需求的整體技術解決方案 * Application Architect 聚焦於應用系統設計 * Cloud Architect 專責雲端平台解決方案 * Security Architect 專注於資安設計與控制 * Infrastructure Architect 處理系統部署與基礎架構 ### 解決方案架構師的主要產出 * 初步架構設計（Conceptual Architecture）用於評估多個解決選項 * Agile 團隊常於 Sprint 0 階段建立初步架構藍圖 * 傳統瀑布模式中會建立完整詳細的架構文件 * 在敏捷開發中，需隨著需求演進逐步補足架構細節 * 持續建立與優化解決方案架構的最佳實務與標準 ### 解決方案架構師合作對象 * Chief Architect 與 Domain Architects * 業務使用者與業務利害關係人 * Business Analyst * 專案經理或 Scrum Master * 開發主管、技術領導與開發人員 * 維運團隊與 DevOps * Security、Infrastructure、Cloud 等技術架構師 ### 企業架構的四大領域 * Business Architecture：涵蓋業務功能、流程、組織架構與地理據點 * Data Architecture：處理主資料、交易資料與其在業務與應用中的應用 * Application Architecture：描述系統邏輯結構與業務流程自動化實作方式 * Technology Architecture：涵蓋伺服器、網路、作業系統、資料庫與整合中介軟體 ### 解決方案架構的影響範圍 * 每次設計解決方案時，均會觸及所有企業架構領域 * 所有變更需更新企業架構知識庫與標準文件 ## Solution Architecture Process ### 解決方案架構流程概述 * 說明解決方案架構師在不同開發流程中的角色與互動 * 涵蓋瀑布式與敏捷式的解決方案架構流程 * 實作將以實際案例貫穿整門課程 ### 瀑布式解決方案架構流程 * 從業務案例或問題陳述出發，識別並分析高階業務需求 * 架構遠景（Architecture Vision）提供可能的解決方案選項 * 根據 TOGAF，遠景包括約束、假設、高階非功能需求、概念架構圖、粗略估算 * 通常在確認完整業務需求後，再完成詳細架構文件 ### 敏捷式解決方案架構流程 * 架構設計與開發流程同步進行 * Sprint 0 階段產出初步架構藍圖以供團隊參考 * 架構需能隨需求變動而演進，符合敏捷交付精神 * SAFE（Scaled Agile Framework）與 TOGAF 的敏捷擴充版本支援持續演進設計 ### 架構視角與交付物 * 解決方案架構需包含多個視角：業務、資料、應用、技術、部署與營運 * 解決方案架構審查由架構審查委員會與利害關係人共同參與 * 審查確保設計方案合理並納入各方意見 ### 可交付成果與工件說明 * 架構遠景文件：描述問題、涉眾關注、解決方案選項、高階估算與需求 * 概念架構與願景可合併為單一文件呈現 * 邏輯架構：說明使用者影響、組織變動、系統與資料流 * 實體架構：描述部署方式、技術堆疊、安全與硬體需求等 * 以上內容統整於完整的解決方案架構文件中 ### Scrum 模型中的架構實踐 * 架構師參與產品待辦清單規劃與 Sprint 會議 * Sprint 期間產出初步架構（例如 Sprint Zero 文件） * 架構師負責與團隊合作設計可交付之解決方案 * 每次迭代結束需提供可被業務展示與驗證的成果 ### 敏捷交付下的圖表與模型需求 * 所需視圖包含：業務視圖、應用視圖、資料視圖、整合架構與基礎架構圖 * 所有圖表與文件須具備敏捷特性，支持快速溝通與調整 * 架構師需能快速建立並更新這些工件，以支援持續交付與團隊運作 ### 架構實作與後續驗證 * 解決方案部署後仍需由架構師參與運行期檢視（如保固期） * 驗證架構落地狀況、與實際營運結果一致性 * 根據實際回饋進行調整與最佳化 ## IT Enterprise Process ### 企業層級的 IT 流程概述 * 架構設計需先理解企業整體運作流程 * 所述流程為通用性整理，實際情況視各公司而異 ### 商業策略與目標 * 商業策略定義企業的核心目標與願景 * 常見目標包含產品銷售、營收提升、客戶服務優化、永續發展等 * 策略引導組織的營運方向與價值主張 ### 營運模式（Operating Model） * 抽象描述組織如何交付價值給客戶 * 涉及人員、流程、據點與技術資源的整合 * 描述企業內部運作與技術支撐的關係 ### 企業架構（Enterprise Architecture）角色 * 奠基於原則與最佳實務，導引組織進行變革 * 涵蓋商業、資料、流程、系統與技術層面的調整 * 支援策略執行與目標達成 ### 需求定義階段 * 識別並優化業務流程與產品需求 * 定義業務使用情境與改進重點 * 為後續解決方案架構建立明確基礎 ### 解決方案架構（Solution Architecture） * 建構滿足業務需求的技術方案與選項 * 為專案執行提供起點，也影響企業架構藍圖 * 即使採用 Agile 方法，仍需有概念性架構作為初期導引 ### 解決方案交付（Solution Delivery） * 涵蓋系統開發生命週期（SDLC）：需求細化、系統設計、開發測試與交付 * 架構師需參與各階段以確保設計與實作一致 ### 系統管理與營運（Operations） * 確保系統穩定運行並提供所需基礎設施 * 包含監控、問題管理、維護非功能性需求（如可用性、安全性等） ## 測驗：Knowledge on Solution Architecture Fundamentals # 第 4 節：Sprint Zero Architecture or IT Architecture Vision ## Theory of an IT Architecture Vision or Sprint Zero Architecture Document ### 架構願景文件（Architecture Vision Document）的目的 * 提供業務足夠資訊以評估解決方案選項 * 協助決定是否修改現有系統、購買新系統、內部開發或外包實作 * 評估專案的投資報酬率與風險，作為是否啟動的依據 ### 核心內容簡介 * 架構願景文件或 Sprint 0 文件的內容可因組織而異 * 本課程內容參考 TOGAF 框架與實務經驗整合 ### 問題陳述（Problem Statement） * 說明業務面臨的問題或新需求 * 由業務人員撰寫，針對需要解決的核心議題 * 包含受影響的業務與 IT 利害關係人、能力、價值鏈 ### 商業願景（Business Vision Statement） * 明確定義架構預期達成的目標與成果 * 協助架構師聚焦於關鍵問題並驗證可行性 ### 變革驅動因素與機會（Change Drivers and Opportunities） * 說明推動此解決方案的業務驅動力 * 同時列出實施目標架構的潛在機會 * 描述受影響的業務能力（如新增或修改能力） ### 業務與技術目標（Business and Technology Objectives） * 業務目標：解決特定問題的業務成效 * 技術目標：如系統遷移、替換、退役等，通常屬於應用藍圖一部分 ### 架構願景細節（Architecture Vision Details） * 列出架構原則、假設條件與限制因素 * 包含 As-Is 概念架構（現況）與 To-Be 概念架構（目標狀態） * 展現解決方案組成、應用、資料、安全與基礎架構需求 ### 非功能需求（Non-Functional Requirements） * 定義設計限制與營運需求 * 涵蓋效能、可用性、資料量、互動方式、持續營運、安全、監控、網路、UI 等 * 對整體系統穩定性與維運有關鍵影響 ### 解決方案選項（Solution Options） * 提出建置、自行開發、購買或重用既有系統的方案 * 列出各方案的技術組合與部署模式 * 可視情況納入特定廠商選項 ### 架構準則與標準（Architecture Guidelines and Standards） * 展示架構設計遵循的組織標準與實作規範 * 確保系統與既有平台一致性與整合性 ### 初步估算與預算參考（Rough Estimates and Costing） * 與開發團隊合作估算初步開發時程與資源成本 * 協助業務評估可行性並規劃 IT 預算 * 涵蓋技術成本、授權費用與預估時程等 ### 補充說明 * 架構願景可整合為一份文件，亦可拆分為願景與概念架構兩份 * 下一堂課將介紹此文件的實際範本與結構 ## The Template for IT Architecture Vision or Sprint Zero Architecture ### 文件用途與來源 * 文件為「Architecture Vision」或「Sprint Zero Architecture」模板 * 範本為 Google Docs 形式，可根據實際情況自行修改 * 課程資源中提供下載連結 ### 文件目的 * 協助業務理解可行的解決方案選項 * 提供高階資訊、需求與初步預算評估 * 支援專案啟動前的可行性與方向判斷 ### 問題描述區塊內容 * 問題陳述：描述業務當前面臨的問題或新需求 * 願景陳述：說明希望透過架構達成的結果與效益 * 能力影響：分析哪些業務能力受影響，是否為新增或變更 * 變革驅動與機會：說明推動此方案的原因與預期收穫 * 業務目標：列出解決方案所需達成的業務成果 ### 架構願景區塊內容 * 假設條件：列出基於當前理解所做出的技術與業務假設 * 限制因素：包含預算、人力、時間、技術等限制 * 現況概念架構（As-Is）：目前系統或流程的整體結構 * 目標概念架構（To-Be）：未來預期實現的架構設計 ### 非功能性需求說明 * 系統可用性、效能、資料量預估 * 使用者互動方式與通道 * 備份頻率與災難復原計畫 * 資安需求與存取控管 * 營運與監控流程 * 網路環境與使用者介面需求 * 架構層級的額外設計需求 ### 解決方案選項與技術架構 * 提出數個高階實作選項（自建、採購、外包等） * 技術平台、部署模式、服務模式的初步評估 ### 預算與時間評估 * 提供粗略開發成本與時程 * 包含授權、平台、部署與營運的初步費用估算 ### 模板結構說明 * 範本結構已包含上述各區塊 * 接下來課程將以實際案例逐一填寫各段內容 ## 測驗：Knowledge on IT Architecture Vision or Sprint Zero Architecture ## Introducing the Solution Sections # 第 5 節：Creating an IT Architecture Vision or Sprint Zero Architecture ## The Business Problem ### 課程內容概覽 * 本節課聚焦於從業務問題導出業務解決方案 * 核心關鍵為理解「需求」如何引導解決方案設計 ### 虛構公司案例：滑稽帽子店 * 建立一間虛構公司作為案例背景 * 將從需求開始，逐步建構「概念架構」 * 案例貫穿後續多個講座，涵蓋解決方案架構、圖表與內容撰寫 ### 文件與作業說明 * 提供一份以 Google Docs 編寫的業務需求文件 * 模擬由商業人士撰寫、部分包含技術需求 * 學員需在下堂課前完整閱讀並理解此文件 * 若未掌握需求內容，後續課程將難以跟上 ### 學習任務（家庭作業） * 閱讀與理解需求文件為本次作業 * 為下一節課的概念架構與解決方案設計做好準備 ## The Agile Team ### 課程虛擬團隊介紹目的 * 建立一個模擬團隊以對應真實專案環境 * 便於學習過程中理解各角色在解決方案架構流程中的職責與互動 * 適用於 Waterfall、Scrum、Kanban 等開發流程 ### 團隊成員角色概覽 * **Product Owner（產品負責人）**：來自業務端，擁有產品，負責需求定義與優先順序 * **Business Analyst（業務分析師）**：橋接業務與技術，負責需求分析與轉換 * **Solution Architect（解決方案架構師）**：設計整體技術解決方案，協調各技術面 * **Scrum Master / Project Manager（敏捷教練／專案經理）**：協調團隊、移除障礙、確保流程順暢 * **Lead Developer（開發領導）**：技術設計與實作主導，負責開發決策與技術方案實現 * **QA Lead（測試領導）**：負責測試策略與測試環境，確保品質控制 * **IT Operations（維運）**：管理部署與營運相關事務，確保系統穩定落地 ### 團隊成員對應名稱 * Sarah：產品負責人（Product Owner） * Anne：業務分析師（Business Analyst） * Bill：解決方案架構師（Solution Architect） * Jane：專案經理／Scrum Master * Jack：開發領導（Lead Developer） * Joe：測試負責人（QA Lead） * Kevin：IT 維運代表（Operations） ### 架構審查委員會（Architecture Review Board） * 包含企業架構師（Enterprise Architect）、領域架構師（Domain Architect） * 涉及 IT 管理者與資深架構師 * 負責審查並批准最終的解決方案架構 ### 團隊參考方式 * 在課程中會多次參考此團隊及其角色 * 各角色對應解決方案架構的不同階段與任務 ## Defining the Business Problem ### 商業問題背景 * 公司目前僅於實體店面販售帽子 * 現在希望開發一個電子商務平台，將帽子產品線上銷售 ### 主要商業需求 * 建立線上註冊與購物流程 * 使用者需註冊帳號才能加入商品至購物車並進行購買 * 僅允許購買有庫存的商品，系統需即時查詢庫存狀態 ### 使用者登入需求 * 支援安全登入流程 * 可整合 Google 與 Facebook 等社群帳號進行登入 ### 結帳與支付需求 * 結帳時需整合安全的第三方支付閘道 * 支援信用卡與 PayPal 支付方式 ### 訂單完成通知需求 * 訂單成功後需自動寄送確認電子郵件給客戶 * 同時需自動發送通知給倉儲經理以便備貨處理 ### 配送整合需求 * 需整合第三方物流商的 API * 訂單完成後自動發送取貨與配送請求給物流公司 ### 發票發送需求 * 當物流確認成功送達後，系統應自動寄送發票給客戶 * 發票透過電子郵件發送，作為交易完成的通知 ## Understand the Problem Statement ### 本講座重點與目的 * 專注於撰寫 IT Architecture Vision 文件中的「問題陳述」 * 說明誰提供資訊、哪些內容需納入、如何結構化表達 ### 問題陳述資料來源 * 由產品負責人提供業務問題、需求與期望成果 * 業務分析師負責紀錄與整理問題陳述內容 * 包含涉眾、受影響的業務能力與業務關切 ### 問題背景說明 * 滑稽帽子店因疫情導致實體銷售下降 * 決定建立電子商務平台銷售現有庫存的帽子 * 線上銷售系統需涵蓋註冊、購物、付款、出貨與通知功能 ### 涉眾與對應需求 * 網站：做為銷售平台，提供線上購物介面 * 客戶：註冊帳號、建立購物車、進行付款與接收通知 * 倉儲經理：接收訂單通知、查詢庫存並備貨 * 配送公司：接收出貨通知、配送完成後回報狀態並觸發發票寄送 ### 業務功能與關切事項 * 系統需驗證商品是否有庫存，避免缺貨後仍接受訂單 * 支援第三方登入（Google、Facebook）以簡化註冊流程 * 整合安全付款閘道（如 PayPal、信用卡）以處理交易 * 訂單完成後須自動寄送確認信與電子發票給客戶 * 配送完成後需通知後台並觸發後續流程 ### 問題陳述的內容重點 * 明確列出涉眾角色與其功能需求 * 描述系統需支援的業務流程與整合點 * 突出目前痛點與轉型目標（如線上銷售、自動化通知等） ## Business Vision Statement ### 商業願景聲明內容來源 * 由產品負責人或業務利害關係人提供 * 由業務分析師負責記錄並整理進文件中 * 描述公司目標與解決方案需實現的商業價值 ### 滑稽帽子店的商業願景 * 希望將實體門市銷售的商品擴展至線上平台 * 建立一個具成本效益的電子商務網站來販售現有庫存帽子 ### 變革驅動因素與機會 * 提升銷售量，透過線上銷售管道觸及更多顧客 * 建立支援手機、平板與桌機的快速且易用的網站介面 * 已與外部物流公司簽約，需整合其 API 以完成出貨與追蹤流程 * 網站需與既有的倉儲庫存系統整合，以即時查詢庫存狀況 * 限定網站僅供美國、歐洲與南非地區用戶存取 * 系統需提供 24/7 可用性，支援多時區顧客操作需求 * 網站開發須使用最新的 Agile 方法論以因應快速交付與彈性變更 * 客戶資料需保密並具備完善資安措施，以保護個資隱私 ### 文件結構提示 * 願景陳述部分為高階方向與價值說明 * 變革驅動與機會列出具體執行要點與對解決方案的影響 * 為後續非功能需求、技術架構設計奠定商業基礎 ## Business Objectives and Capability Impact ### 本講座重點 * 說明如何在架構願景文件中建立「業務能力影響模型」 * 初次由解決方案架構師參與該模型的製作 * 業務能力與目標通常由業務用戶、產品負責人或業務分析師提供 ### 能力模型結構與呈現方式 * 每個企業都有專屬的業務能力模型，依規模與需求而異 * 可依領域（如銷售、產品、庫存、交付、支援）分類顯示能力 * 使用顏色區分「現有能力」與「新增／變更能力」 ### 新增與變更的業務能力 * **電子商務銷售能力**：新增能力，用於線上銷售產品 * **客戶帳戶管理**：新增能力，儲存使用者資訊與交易歷史 * **客戶洞察報表**：新增能力，用於後續行銷與分析應用 * **訂單管理變更**：因引入線上訂單流程需調整現有訂單處理機制 * **產品管理延伸**：需儲存產品圖像，支援前台網站展示 * **庫存查詢整合**：需從現有庫存系統取得庫存資料供電商系統即時查詢 * **交付服務整合**：新增對外 API 整合，用於自動派送與追蹤交付狀態 * **發票與溝通機制**：新增自動化電子郵件發送能力（確認信、發票通知等） * **IT 支援能力提升**：新增系統上線後需擴充 IT 支援範圍與能力 ### 能力影響呈現重點 * 明確標示哪些能力是「全新」導入，哪些是「現有功能的擴充或調整」 * 能力模型有助於視覺化業務影響，便於後續解決方案設計與溝通 * 支援後續架構文件中「非功能需求」、「整合點」與「系統邊界」定義 ## Architecture Vision ### 架構願景與原則的目的 * 定義此解決方案應遵循的高層架構原則 * 原則由架構審查委員會（Architecture Review Board）事先建立 * 解決方案架構師負責選擇與本案相關的原則並納入設計 ### 架構原則的來源與確認方式 * 初期由企業架構師或資深架構師制定 * 架構師可與同儕或企業架構師討論確認適用原則 * 原則內容通常已紀錄於企業架構資源中 ### 本次案例選用的架構原則 * **業務持續性**：系統需納入災難復原（Disaster Recovery）機制 * **易用性**：技術選擇應簡單易用、易於導入與維運 * **資料安全性**：資料在傳輸與儲存時必須加密，確保安全 * **技術獨立性**：系統應能在不同基礎設施上運行，避免平台綁定（如可部署於 Azure 或 AWS） ### 架構原則的應用價值 * 為系統設計提供一致性與方向 * 確保未來可擴充、易維運與具彈性 * 支援企業長期技術策略與標準化政策 ## Architecture Assumptions ### 架構假設的定義與收集方式 * 架構假設需由整個團隊共同參與會議討論產出 * 會議參與者包含產品負責人、專案經理、開發人員、測試人員、IT 維運與其他架構師 * 解決方案架構師負責彙整並納入架構願景文件中 ### 常見架構假設範例 * 現有庫存系統已部署並提供 API，可供查詢與更新庫存數據 * 第三方物流廠商已提供 API，可用於出貨與配送狀態查詢 * 系統已有電子郵件發送能力，或將假設其具備該功能 * 這些假設可由技術團隊或業務代表提出，後續需進行驗證 ### 架構限制條件 * 業務規定網站僅限美國、歐洲與南非地區可存取 * IT 環境目前僅具備 Azure 雲端平台帳號，無其他雲平台支援 * 限制需在設計階段被明確考量，影響地理部署與合規性 ### 識別風險與緩解策略 * 風險：人力不足導致專案無法如期交付 * 緩解方式：業務提供預算聘請外包工程師加速進度 * 風險：雲端運營成本過高 * 緩解方式：架構設計中納入自動擴展（Auto-scaling）以降低成本壓力 * 所有風險需指定責任人並定義應對計畫 ### 文件目的與價值 * 明確記錄假設、限制與風險，有助於後續設計與專案決策 * 可作為評估方案可行性與溝通依據，避免後期誤差與衝突 ## Constraints and Risks ### 架構現況與目標概念架構說明 * 若現有系統存在，需繪製 As-Is 概念架構圖 * 本案例為全新電子商務系統，無現有架構可參考 * 直接建立 To-Be 概念架構作為未來系統設計藍圖 ### 情境圖（Context Diagram）介紹 * 表示系統與外部使用者及外部系統的互動 * 圖中中央為主要系統：Funny Hat Online Website * 以高階方式呈現資料流與整合點，不涉及內部邏輯細節 ### 使用者與外部系統互動關係 * 客戶可在線上購買商品，並接收訂單與發票通知 * 系統整合社群登入服務（Google、Facebook）進行身份驗證 * 結帳時導向支付閘道（如 PayPal、信用卡）進行付款 * 系統產生訂單後通知倉儲，並將資訊傳送至發票系統產生發票 ### 整合系統與資料流說明 * 與庫存管理系統互動：查詢與更新庫存、取得商品資訊與圖片 * 與物流廠商 API 整合：發送出貨請求與接收配送狀態 * 與發票系統整合：依據出貨完成狀態產出發票並寄送給客戶 ### 圖表輔以文字說明 * 圖示提供整體架構與資料流視覺化概覽 * 應補充文字描述各互動與邏輯，以利非技術涉眾理解 * 此階段為高階概念設計，詳細技術設計將於後續架構文件中補充 ## Context Diagrams ### 本講座重點與目的 * 介紹使用 C4 模型作為替代方案來建構系統架構圖 * 與傳統情境圖（Context Diagram）比較，提供更清晰的分層架構資訊 * 展示 C4「System Context Diagram」在本案例中的應用 ### C4 模型簡介與優點 * C4 模型將系統視圖分為四層（Context、Container、Component、Code） * System Context Diagram 屬於最外層，顯示系統與外部角色／系統的互動關係 * 圖面更具層次與結構，適合系統概觀展示與進一步細化 ### C4 模型中主要元素說明 * **客戶（Customer）**：Funny Hat 網站的終端使用者 * **Funny Hat Website**：主要 Web 應用，供使用者瀏覽商品、建立購物車與進行付款 * **Payment Gateway**：處理支付流程，支援信用卡與 PayPal，透過導向方式整合 * **API Layer**：中介層，負責網站與後端系統的資料交換與整合呼叫 * **Delivery Vendor API**：第三方物流廠商的 API，處理出貨請求與配送狀態 * **Stock System**：管理商品庫存、訂單與產品資料 * **Invoicing System**：根據訂單生成並發送發票 * **Email Service**：寄送訂單與發票通知至客戶 ### 視覺標示與分層說明 * 藍色：新開發功能（如 API Layer） * 灰色：既有系統（如 Stock System） * 橘色或其他色：外部整合系統（如 Payment Gateway、Delivery Vendor） * 各元素間以箭頭標示資料流與互動方向 ### C4 模型的實務應用價值 * 比 Context Diagram 提供更多內部架構的線索，適合技術團隊閱讀 * 可延伸至更細緻的層級（如 Container Diagram）以支援後續架構細節發展 * 適用於需要展示內外部系統互動與模組分工的專案場景 ### 建議使用時機 * 若需求較複雜且有明確模組與服務邊界，建議使用 C4 模型 * 若受眾以非技術決策者為主，可優先使用 Context Diagram * 可依組織習慣與讀者需求選擇適合的圖示方式 ## How to model a Context Diagram using C4 ### 本講座重點 * 示範如何使用 Draw.io 建立 C4 模型圖 * 展示操作流程與基本建構方式 * 提供繪製解決方案架構圖的實用技巧 ### 工具使用：Draw.io（現稱 diagrams.net） * 透過瀏覽器進入 draw.io 網站 * 建立新圖表並選擇儲存位置（如 OneDrive） * 支援多種模板：基本圖形、商業圖表、雲端架構（Azure、AWS）、UML、流程圖、線框稿等 ### 啟用 C4 模型圖形庫 * 點選左側「More Shapes」以啟用 C4 圖形庫 * 勾選「C4」後套用，即可在側欄看到各類 C4 元件 * 包含使用者、系統、容器、元件等標準圖形 ### 建立 C4 元件流程 * 拖曳「Person」元件作為使用者角色，例如設定為「Customer」 * 拖曳「Software System」元件代表系統，如「Funny Hat Website」 * 可自訂名稱、描述與屬性，便於後續說明與閱讀 * 使用「Relationship」元件建立元件間關係，較一般箭頭更標準 ### 圖表互動與編輯技巧 * 點擊箭頭可輸入交互描述，如「purchases hats」 * 每個元件皆可加入技術細節與附加屬性 * 可自由拖曳與連接，快速建立概念架構圖 ### 實務應用建議 * 適用於架構師製作 System Context、Container、Component 圖層 * 可作為解決方案架構文件的附圖或簡報使用 * 圖表清晰、易於分享與修改，適合團隊協作使用 ## Review Conceptual Architecture and non-functional requirements ### 架構審查與同儕審核 * 解決方案架構師需安排與同儕或企業架構師進行架構審查會議 * 會議目的是確認概念架構內容與變更建議是否合理 * 收集審查回饋並納入更新，作為後續架構工作的基礎 ### 高階非功能性需求會議準備 * 由解決方案架構師主導召開會議，參與者包含業務代表與團隊成員 * 若企業已有既定非功能性需求，可直接使用；否則需與商業分析師共同定義 * 所有需求目前皆屬於概念性階段，並非最終版本 ### 可用性（Availability） * 系統需全年無休（24/7）運行，達到 99.99% 可用性 * 支援例行批次任務，如查詢物流狀態 * 計劃性維護時間設為週一凌晨 ### 效能（Performance） * 系統應具備自動擴展能力，特別是在晚間與週末流量高峰期 * 回應時間需低於 2 秒 * 每日預估約 1,000 次請求 ### 資料量與儲存（Volumes） * 商品圖片儲存於 AWS S3（或 Azure Blob） * 平均圖片大小為 50KB，共約 200 種產品 * 初始儲存空間需達 100GB，年增長預估為 10% ### 使用者互動（User Interactions） * 前三個月預期 500 位使用者，一年內成長至 2,000 位 * 最少同時支援 10 位使用者在線 * 地理限制為美國、歐洲與南非 ### 業務連續性（Business Continuity） * 實作資料備份與資料庫複寫機制 * 使用多可用區部署（Multi-AZ）以確保高可用性 * 客戶資料需留在所在區域資料中心，遵守資料主權 ### 資安要求（Security） * 使用 OAuth 與 Google/Facebook 提供登入驗證 * 資料在儲存與傳輸時均需加密 * 實作存取稽核機制，記錄資料存取與異動行為 * 網站需使用 X.509 憑證以確保 HTTPS 傳輸安全 ### 運維與監控（Operations & Monitoring） * 實作健康檢查機制，監控 Web 應用與資料庫狀態 * 系統錯誤需主動通知 IT 支援人員 * 建立例外處理與錯誤通報流程 ### 網路規劃（Networking） * 建立 AWS VPC 架構，前端服務放置於公共子網，後端服務放置於私有子網 * 實作 Load Balancer 以處理進入流量並支援自動擴展 * 設定防火牆規則，控制對外 API 的流量進出 ### 使用者介面需求（UI Requirements） * 網站需具備響應式設計，支援行動裝置與桌面瀏覽器 ### 架構規劃（Architecture Requirements） * 決定部署於 AWS 雲端，分為 Dev、QA、UAT 與 Production 環境 * 使用微服務架構與容器化部署方案 * 導入 DevOps 管線，支援 CI/CD 流程與自動部署 ## Propose Solution Options ### 解決方案選項制定流程 * 解決方案架構師與 IT 團隊領導與資深開發人員合作，制定可行方案 * 須依據企業既定的雲端策略（如 AWS 或 Azure）與設計準則做出選擇 * 完成初步選項後，需提交給 Architecture Review Board 或相關架構師進行審查 * 所有回饋須整合回 IT Architecture Vision 文件中 ### 選定的基礎解決方案架構 * Web 應用程式部署於 AWS EC2 上，透過 Apache 提供服務 * 應用邏輯層與前端 Web 層分開部署，各自為獨立的 EC2 實例 * 使用 ALB（Application Load Balancer）管理來自外部的請求 * 透過 Auto Scaling Group 根據流量自動擴展 EC2 實例 ### 資料與快取處理 * 使用 Elasticache 快取靜態產品資料，提升查詢效率 * 圖片儲存於 AWS S3，供網站展示使用 * 使用 RDS MySQL 作為主要關聯式資料庫（亦可根據需求替換為其他支援的 DB） * 公司網域透過 Route 53 託管 ### 監控與通知機制 * 使用 CloudWatch 進行應用程式與基礎設施的健康檢查與錯誤告警 * 應用程式異常處理可整合至 CloudWatch 日誌與警示機制 * 使用 AWS SES 發送交易郵件與系統通知給用戶 ### 全球內容分發與 API 整合 * 使用 CloudFront 內容傳遞網路（CDN）讓網站於美國、歐洲與南非快速載入 * 整合 Amazon API Gateway 與第三方物流廠商之 API，完成訂單交付與查詢作業 ### 設計原則考量與技術選擇說明 * 所採用技術為簡化版本，目的是說明設計思路與架構原則 * 所有元件與服務均可依實際需求替換為相同屬性的替代方案 * 非以最佳效能為唯一考量，強調初期可理解、可實作的基本架構模型 ### 後續階段預告 * 下一講將進行成本初估，供業務方評估是否進入實作階段 * 若獲得業務批准，將開始建構完整的 End-to-End 解決方案架構 ## Cost Estimates ### 成本估算流程概述 * 成本估算屬於 IT 架構願景文件的最後階段 * 由解決方案架構師召集相關團隊進行協作估算 * 可使用 T-shirt Sizing 估算模型快速評估工作量 * 不同公司可有各自的估算模板與流程 ### T-shirt Sizing 評估標準 * Small：約需 1～2 週完成 * Medium：約需 2～4 週完成 * Large：約需 4～8 週完成 * X-Large：約需 8～16 週完成 ### 各功能模組與估算結果 * Web 應用功能（商品展示、加入購物車、結帳）：X-Large（約 10 週） * 資料庫設計與實作（用戶資料、訂單、購物車）：Medium（約 2 週） * 郵件通知整合（Amazon SES 發送訂單與發票）：Medium（約 2 週） * 訂單系統串接（與庫存系統 API 整合）：Small（約 1 週） * 發票系統串接（生成與寄送發票）：Small（約 1 週） * 外部物流 API 串接（請求取貨與查詢配送狀態）：Large（約 4 週） * 使用者登入整合（OAuth、Google/Facebook）：Small（約 1 週） * 基礎設施建置（VPC、子網、監控）：Medium（約 3 週） * 金流整合（付款閘道串接與重導）：Medium（約 2 週） ### 總工時與成本推估 * 預估總開發工期約 24 週 * 預估總工時為 960 小時 * 參與角色包含 2 位開發者、商業分析師、解決方案架構師、測試人員與 Scrum Master * 粗略估算人力成本為約 127,000 美元 ### 額外成本與基礎設施支出 * 外部供應商整合與授權成本：約 1,500 美元 * AWS 基礎設施年度費用：約 50,000 美元 * 年度雲端營運費用須明確向業務單位說明 ### 注意事項與後續發展 * 此估算為初步規劃階段的粗估 * 待完整方案架構完成後，將進行更細緻的技術與成本細化 * 若採用 Agile，可將估算轉換為 Epic，分解至 Product Backlog 與 Sprint 計劃 ## The ARB or Architecture Review Board ### 架構願景結案審查流程 * 解決方案架構師需召開架構願景結案審查會議 * 會議參與者包含企業架構師、其他解決方案架構師、IT 經理、IT 支援人員及 Scrum 團隊成員 * 目的為呈現完整的 IT 架構願景內容並收集意見與建議 * 審查會後須獲得最終批准，才能進入下一階段 ### 後續流程 * 若業務單位批准架構選項，則可展開具體的解決方案架構設計 * 若公司無既定流程，可參考本課程的標準化步驟作為實施參考 * 下一階段將著重於完整撰寫《Solution Architecture Document》之技術細節與內容規劃 --- # 第 6 節：Creating the Solution Architecture ## Solution Architecture Template ### 解決方案架構文件簡介 * 開始撰寫《Solution Architecture Document》作為架構階段下一步 * 文件可用簡報工具（如 Google Slides、PowerPoint）撰寫，便於簡報與審查 * 文件格式可依公司慣例選擇，不拘泥於特定樣式 ### 文件目標與時機 * 可在專案正式啟動前先撰寫部分內容，幫助專案團隊準備 * 若採用 Agile 方法，也可在開發過程中持續補充與完善 ### 文件主要內容總覽 * 專案描述與範疇（In Scope / Out of Scope） * 商業能力地圖（Business Capability Map） * 應用變更與影響系統清單 * 應用程式開發路線圖 ### 架構圖與流程圖 * 現況（As-Is）與目標（To-Be）Context Diagram（含變動部分） * 用例圖（Use Case View），可能包含業務流程 Level 0/1/2 * 來自商業分析師或業務架構師的輸入 ### 非功能性需求詳列（High-level to Detail） * 可用性（Availability）與效能（Performance） * 資料量估算、檔案大小、介面形式 * 備份與歷史資料保存策略 * 資料庫成長預估與存儲需求 ### 使用者互動與角色 * 使用者地理分布與數量預估 * 各類角色與使用情境 ### 業務連續性與安全需求 * 備援架構、多區可用性設計 * 各國資料儲存隔離需求 * 認證與授權（OAuth、角色權限） * 資料保密、完整性與稽核紀錄機制 ### 運維與網路需求 * 健康檢查、監控與告警機制 * 支援責任分工（運維、開發、IT 支援） * 網路配置（VPC、子網、防火牆規則） ### 使用者介面與技術環境 * 回應式設計，適用於行動裝置與桌面 * 系統部署環境（如 EC2）、開發堆疊技術 ### 系統架構圖與整合需求 * 目標架構圖（Target State Architecture） * 架構目標、限制與風險 * 整合架構（外部 API、郵件系統、內部服務） * 資料架構（主資料、交易資料、資料流程） ### 部署與實作細節 * 邏輯與實體部署模型 * 安全架構與網路架構 * 開發需求、資料庫與檔案儲存設定 * 資料遷移策略（如需） * 部署策略（手動/自動、CI/CD） * 報表與額外功能開發需求 ### 後續安排 * 接下來課程會逐項深入說明如何完成上述內容 * 每部分將介紹參與角色、需求來源與產出格式 ## The Project Description ### 專案描述來源與撰寫角色 * 專案描述由業務單位提供指引 * 專案經理或 Scrum Master 根據業務需求撰寫描述 * 為解決方案架構文件的第一部分 ### Funny Hat Shop 專案目標 * 開發一個電子商務網站，用於銷售 Funny Hat Shop 的產品 * 建立符合 IT 架構願景與業務需求的解決方案架構 ### 預期業務成果 * 透過網站增加產品銷售額 * 提供簡單、快速、易用的網站體驗 * 支援跨平台（手機、平板、電腦）瀏覽與操作 ### 整合需求 * 與外部物流供應商建立 API 整合 * 支援訂單配送流程的自動化與資訊交換 ## Business Capability Impact ### 專案範疇（In Scope） * 建置一個電子商務網站並部署於 AWS 平台 * 整合庫存管理系統與發票系統 * 實作 Email 通知服務，用於訂單與發票通知 * 與新的物流供應商整合，處理商品配送 * 整合物流供應商 API，自動化配送狀態與請求處理 * 為每項商品加入產品圖片並更新至庫存系統 ### 專案不在範疇內（Out of Scope） * 不包含現有庫存管理系統的升級或變更 ### 業務能力影響（Business Capability Impact） * 新增線上銷售能力（Online Sales） * 建立顧客帳戶與登入機制（Customer Account） * 增加顧客洞察與報表能力（Customer Insights/Reporting） * 新增物流配送服務整合（Delivery Service） * 調整訂單管理流程（Order Management） * 調整產品管理功能以支援產品圖片（Product Management） * 實作顧客電子郵件溝通能力（Customer Communication via Email） * 擴充支援服務能力，因應新應用系統（Support） * 調整發票處理流程，納入新銷售流程（Invoicing under Financial Services） ## Applications Impacted ### 應用系統路線圖（Application Roadmap） * 每個業務能力對應到的應用系統會標示是新建、重用或購買 * 僅列出本次專案會受到影響或新增的應用系統 ### 新增應用系統 * 電子商務網站（E-commerce Web Application）：建置全新應用系統，對應於線上銷售能力 * 顧客帳戶系統（CRM Database）：建置內部 CRM 系統，管理顧客帳戶資訊 * 客戶洞察報表系統（BI Reporting Capability）：建立新的報表與洞察系統 * 配送服務整合（Delivery Vendor Integration）：與外部供應商建立 API 整合，此應用需購買授權 * 郵件服務（Email Service on AWS）：開發一套整合 AWS SaaS Email 的郵件發送服務 * IT 支援與監控（CloudWatch Monitoring）：新建支援服務，利用 AWS CloudWatch 監控系統健康狀態 ### 既有系統變更與重用 * 訂單管理與產品管理（Stock Management System）：重用現有系統，並進行修改以支援訂單處理與產品圖片管理 * 發票系統（Invoicing System）：重用並更新原有發票系統，使其整合至網站流程中 ### 無系統移除或淘汰 * 本次專案未規劃淘汰任何現有應用系統 ## Conceptual Architecture ### Aziz 與 To-Be 概念性架構的定義與用途 * Aziz 描述現有架構與基礎設施的實作現況 * To-Be 根據本次專案需求描述未來預期架構 * 若本案無現有架構可參照，則 Aziz 可留空 * To-Be 用來描繪新增或變動的系統功能與整合方式 ### To-Be 架構補充說明 * To-Be 可能包含新的使用者互動方式（如：透過網站與系統互動） * API 層、付款閘道、Email 服務、外部配送 API 等為新加入元件 * Aziz 中若沒有此類元件，代表此為新增功能 ### 圖表建立與工具說明 * 可使用 Draw\.io 等工具繪製 Context Diagram * 在 Solution Architecture 文件中補上與 Architecture Vision 差異的內容 * 不需重繪已無變動的部分，只需反映變動 ### 圖表審查流程 * 更新完 To-Be 架構圖後，應安排與架構同儕或架構審查會的會議 * 確認每一個系統、Actor、整合點與互動關係是否被完整捕捉 * 確保高階（Contextual）層級的整合方向清楚明確 ### 實務建議 * 即使架構圖處於高階抽象層，仍須明確標示所有內外部系統的交互作用 * 所有新增功能與變更項目應反映在 To-Be 架構圖中，以利後續細部設計與審查 ## Business Requirement Reviews ### 商業需求檢視流程概述 * 商業需求來源通常為產品負責人與業務使用者 * 專案經理或 Scrum Master 協助記錄並納入文件 * 不同開發模式（瀑布與敏捷）處理需求的方式不同 * 在解決方案架構制定階段，需掌握高階需求內容 ### 瀑布式 vs 敏捷式需求處理 * 瀑布式會先完成詳細的需求文件，由業務分析師主持 * 敏捷則以高階 user stories 為起點，逐步於每個 sprint 內細化與實作 * 解決方案架構師需依專案方式決定何時深入參與需求設計 ### 解決方案架構師的角色與參與時機 * 多數大型企業中，架構設計會在開發啟動前先確定技術堆疊與流程方向 * 架構師需參與需求檢視會議，與業務、產品負責人、開發團隊共同澄清需求 * 架構師須確認需求是否會影響架構設計與整合決策 ### 高階需求案例展示（Funny Hat 商店） * 使用者需可建立帳號並登入系統（OAuth / Google / Facebook） * 客戶能搜尋、瀏覽商品並加入購物車 * 預期支援不同數量的商品與數量選擇邏輯 * 若採敏捷模式，則可按優先順序安排部分功能進入初期開發 ### 與業務分析師、UX 團隊的協作 * UX 設計師會提供 UI 原型（wireframes）供團隊理解畫面流與互動 * 業務分析師會進一步定義細節，如稅務計算、欄位邏輯等業務規則 * 此類細節會在後續的系統設計與實作階段處理，不納入高階架構範疇 ### 其他可能涉及但不屬於架構師的產出 * BPMN 或其他業務流程模型可能作為需求佐證 * 架構師應了解流程對技術整合的影響，但不需親自產出流程圖 * 細部流程與畫面設計由業務分析師與 UX 專責負責完成 ## Non-Functional Requirements ### 非功能性需求責任與流程 * 高階非功能性需求初步由商業分析師與產品負責人、業務單位討論確定 * 詳細非功能性需求由解決方案架構師負責蒐集與整理 * 需召開多場會議與各方確認細節並納入解決方案架構審查文件 --- ### 可用性與維護需求 * 系統預期全年無休，目標可用性為 99.99% * SLA 需明確，例如訂單確認信於下單後 10 分鐘內送達 * 維護窗口需明確，例如每週日凌晨 1–2 點 * DevOps 環境下需評估 CI/CD 對運作影響 * 不可避免的非計劃性停機需評估對業務的影響（例如銷售） * 批次處理如每 10 分鐘執行一次用於更新配送狀態 --- ### 效能與擴展性需求 * 頁面回應時間應低於 2 秒 * 系統需支援每日數千次的訪問量 * 高峰期間須支援自動擴展，例如使用 AWS/Azure 的 Auto Scaling 和 Load Balancer * 需根據負載狀況自動增減服務實例 * 定義資料延遲接受範圍（例如地址變更是否需即時同步） --- ### 資料量與儲存 * 每月預期交易量約 500 筆，網站每日應支援 1000 次點擊 * 高峰期預計在週末與晚上 * 產品圖片儲存於 AWS S3，平均大小約 50KB * 資料庫需具備複寫與備援機制以應對異常 * 須考量歷史紀錄保存期限（如保留十年以上） * 預估資料庫每年成長 10% --- ### 使用者互動與角色 * 前三個月預計 500 名使用者，一年後達 2000 名 * 同時連線使用者數預估為 10 人，屬於低負載等級 * 使用者位置限制於美國、歐洲與南非 * 系統角色包含管理員、客戶、店鋪經理等角色，須明確定義權限 --- ### 業務持續性與災難復原 * 須具備業務持續性計畫，涵蓋災難發生時的應變策略 * 需確認是否有異地備份與跨平台部署能力 * 若 AWS 完全無法使用，應能轉移至 GCP 或 Azure * 架構設計中應利用多可用區（Multi-AZ）與 AWS CloudFront 發布至多個地區（美東、歐洲、南非） --- ### 安全性與驗證 * 使用 AWS Cognito 管理使用者驗證 * 支援 Google 與 Facebook 的單一登入（SSO） * 權限控管依據使用者角色（例如 admin、client、manager） * 支援審核機制（如主管審核使用者存取） * 實作稽核紀錄（例如地址變更記錄入稽核表） * 敏感資料需加密處理，遵循 GDPR 與各地法律 * 需實作 CAPTCHA 與多因素驗證（如 SMS）以驗證用戶真實性 --- ### 日誌與錯誤處理 * 系統異常需記錄於事件管理系統 * 開發人員需建立錯誤日誌，並保留七天以供追蹤 * 所有錯誤記錄應能支援維運與除錯使用 --- ### 傳輸與儲存加密 * 資料傳輸使用 X.509 憑證加密 * 與網站互動的 API 層需具備憑證驗證機制 * 使用 AWS KMS 管理秘密與加密（例如保護 S3 Bucket） * 資料庫使用 AES-256 加密演算法（例如 RDS）確保資料安全 ### 營運與監控需求 * 系統需支援即時健康檢查機制 * 使用 AWS CloudWatch 進行系統監控 * 整合 SNS 發送警示訊息（如簡訊或電子郵件）給維運人員 * IT 營運需持續監控監控訊息與支援信箱 --- ### 網路需求 * 使用 AWS VPC 或 Azure VNet 架構，區分 public 與 private subnet * Public subnet 用於網站主機，Private subnet 用於 API 與資料庫 * 預估資料頻寬：資料 5KB/s，上傳與下載，圖片 500KB/s * 設定防火牆與 Security Groups 控制內外部流量 * 使用 AWS API Gateway 存取外部供應商的 API * 對供應商 IP 白名單設定，並以密鑰進行驗證 * 使用 Application Load Balancer 處理網站流量並整合 Auto Scaling --- ### 使用者介面需求 * 網站需支援桌面與行動裝置（手機、平板） * 支援主流瀏覽器：Chrome、Firefox、Safari、Internet Explorer --- ### 架構需求 * 採用微服務架構，每個服務擁有自身資料與邏輯 * 使用容器化技術（如 Docker）部署服務 * API 採用 RESTful 架構與 JSON 格式 * 傳統 SOAP/XML 架構較不建議使用 --- ### 環境需求 * 需設置 4 個環境：開發（Dev）、測試（QA）、驗收（UAT）、正式（Prod） * 每個環境使用獨立 VPC，避免資源混淆與權限錯誤 * 注意 AWS 資源的區域性與共享性（如 S3 屬全球資源） --- ### 系統實作技術 * 開發語言採用 C# 搭配 ASP.NET Core 3.1 * 使用 MVC 架構開發 Web 應用 * 單元測試框架使用 XUnit * 網頁使用 Bootstrap 建立響應式設計 * 容器部署使用 Docker * 資料庫選擇可能包含 MySQL、SQL Server 或 PostgreSQL（部署於 AWS RDS） * Web Server 可使用 Apache 或 IIS * 前端可選擇 Angular 或 JavaScript 實作使用者介面 ## Solution Architecture Diagrams ### 架構圖與 TO-BE 架構概述 * 本次聚焦於「TO-BE」架構圖，未提供現有（AS-IS）架構 * 建立的架構圖基於 C4 模型，細化系統元件與互動流程 * 圖中內容協助設計與開發團隊理解整體系統設計方向與整合點 --- ### Web 應用與客戶端互動 * 採用 ASP.NET Core 單頁式應用（SPA），MVC 架構 * 功能涵蓋商品瀏覽、加入購物車與付款 * 資料透過 RESTful API（JSON）與後端交互 * 客戶端與後端通訊皆透過 HTTPS，搭配 X.509 憑證進行加密 --- ### 第三方支付整合 * 支援 Amazon Payment Gateway 進行支付流程 * 使用者付款時將被導向至第三方支付頁面，不處理信用卡資料 * 通訊透過 HTTPS 並使用 X.509 憑證保障資料傳輸安全 * 完成支付後會重新導回原始應用頁面 --- ### API 設計與後端服務 * 使用 ASP.NET Core Web API 搭配 MVC 架構 * 建議整合 Swagger 以提供 API 文件與測試功能 * 資料儲存在 MySQL 資料庫中，涵蓋用戶帳號、購物車與訂單等資訊 --- ### 通訊服務與電子郵件發送 * 通訊服務採用 .NET Core 架構 * 整合 AWS SES 寄送交易相關電子郵件 * 同時負責與物流廠商 API 連線進行配送狀態查詢與回報 * 支援多用途：發信與第三方配送 API 整合 --- ### 後端整合系統 * 系統需整合內部庫存管理系統、發票系統與電子郵件服務 * 使用 HTTP 協定與 JSON 格式傳輸資料 * 從庫存系統獲取商品圖片與庫存量 * 發票資料由發票系統產生後交由通訊服務發送 --- ### 架構圖應用建議 * 各公司繪製方式可能不同，但關鍵在於明確標示各元件間的互動 * 可進一步以不同圖示表示安全性、資料流向與基礎架構 * 後續將補充其他圖表類型（如安全架構圖、資料流圖、基礎設施圖）以輔助完整設計呈現 ## Architecture Objectives ### 架構目標（Architecture Objectives） * 所有環境部署於 AWS VPC * 架設單頁式應用（SPA），使用 Bootstrap 建立響應式介面 * 使用 AWS EC2 作為主機，並配置 Application Load Balancer * 使用 ElastiCache（Redis）快取靜態與低變動性資料 * 資料庫選用 MySQL，部署於 Amazon RDS * DNS 使用 Route 53，系統監控使用 CloudWatch * 實作 Auto Scaling 根據流量自動調整資源 * 建立 DevOps CI/CD 自動部署流程 * 傳輸與儲存資料加密，使用 X.509 憑證與 AWS KMS ### 架構限制（Architecture Constraints） * 預算上限為 20 萬美元 * 專案需於三個月內交付 * 強制使用 AWS 雲端平台 * 僅可整合公司指定第三方廠商與 API * 技術選型需符合公司內部標準與政策 ### 架構風險與對策（Architecture Risks and Mitigation） * 專案未能如期交付將影響營收與上線時程 * 為加速開發，可引進外包資源 * 使用高效能雲服務可能導致營運成本過高 * 可透過選用如 MySQL 等免費方案平衡效能與成本 * 所有風險由團隊共同識別並制定對策 * 風險與緩解方案由解決方案架構師記錄於架構審查文件 ## Data Model Diagram ### 圖表支援與組織差異 * 各公司對架構圖的使用習慣不同，有的忽略，有的過度詳盡 * 常見圖表包括資料模型、序列圖、基礎設施圖、部署圖、安全圖等 * 圖表形式與層次依組織文化與角色分工而異 ### 資料模型的重要性 * 資料模型有助於說明資料的來源、用途與存儲位置 * 應定義主資料（如顧客、商品）與交易資料（如訂單、發票）之關係 * 資料模型可與企業的業務能力模型關聯，指出資料屬於哪項業務能力 ### 資料模型建立流程 * 由解決方案架構師主導資料模型建立 * 收集來自企業架構師、資料分析師、資料治理人員的意見 * 產出為高階資料關聯圖（非物理資料庫結構） ### 範例資料模型內容 * 顧客（Customer）為主資料，可對應多筆訂單（Order）與發票（Invoice） * 訂單為交易資料，包含多個訂單項目（Order Item） * 訂單項目關聯至產品（Product），產品亦為主資料 * 購物車中商品為訂單項目的前身 * 可標註各資料類型（主資料、交易資料）以強化模型清晰度 ### 與後續設計的關聯 * 高階資料模型作為開發人員與資料庫設計人員進一步設計的基礎 * 詳細實作（如 ERD）由資料庫設計者根據此高階模型擴展而成 * 可視需要延伸至資料流圖，視覺化資料如何在系統間傳遞 ### 預告下一主題 * 下一章節將介紹序列圖，展示各元件間的互動流程 ## Data Interaction Sequence Diagram ### 序列圖的目的與角色 * 序列圖用於描述使用者與系統各元件之間的互動流程 * 協助開發團隊了解元件間呼叫順序與責任分工 * 解決方案架構師需先擬定初稿，再與團隊討論確認 ### 圖中常見的參與元件 * 使用者（Customer） * 單頁式應用程式（SPA） * Web API * 通訊服務（Communication Service） * 資料庫（Database） * 現有後端系統（庫存系統、發票系統） * AWS SES（寄送電子郵件） * 外部配送 API（物流廠商） * 第三方付款閘道（Payment Gateway） ### 標準使用者互動流程 * 使用者開啟網站，SPA 透過 API 向庫存系統請求商品列表 * 使用者將商品加入購物車，資料儲存至資料庫 * 使用者點選結帳，頁面導向第三方付款閘道 * 付款完成後導回網站，系統儲存訂單狀態至資料庫 ### 背景服務流程 * 通訊服務透過批次程序檢查新訂單 * 透過 AWS SES 寄送訂單確認郵件給顧客 * 向發票系統請求開立發票 * 通知外部物流 API 安排取件 * 持續查詢物流狀態，確認配送完成 * 配送完成後寄送發票給顧客 ### 團隊合作與設計細節 * 序列圖應專注於高階互動流程，不需呈現資料欄位或技術細節 * 詳細實作交由系統設計或開發階段定義 * 根據情境可繪製多種序列圖（如結帳流程、庫存更新流程、後台操作流程） ### 重要性與應用 * 序列圖是解決方案架構設計中的關鍵輸出 * 有助於明確劃分服務職責與資料流向 * 為開發與測試提供依據，有助於減少實作過程中的誤解 ## Application Logical Component Model ### 應用邏輯元件模型簡介 * 描述應用系統中高階邏輯元件及其組成 * 部分公司由開發團隊負責建立，部分公司要求解決方案架構師先行制定架構藍圖 * 模型有助於理解應用如何被模組化、職責如何劃分 ### Web 應用元件（ASP.NET Core 3.1 MVC） * Product View * Product Controller * Basket View * Basket Controller * Customer Account View * Customer Account Controller ### Web API 元件（ASP.NET Core 3.1 Web API，MVC Pattern） * Product Controller API * Product Model * Basket Controller API * Basket Model * Customer Account Controller API * Customer Account Model ### 資料庫元件（MySQL） * Customer Account Table * Basket Table * Basket Item Table * Order Table ### 通訊服務元件（.NET Core 3.1，MVC Pattern） * 批次處理服務（處理送貨狀態查詢） * 批次處理服務（處理電子郵件發送） * 與外部系統整合的核心中介層元件 ### 建模目的與使用時機 * 提供開發團隊明確的模組分工與實作參考 * 支援後續的開發堆疊選型與技術策略 * 可延伸用於部署圖與服務定義文件中 ### 注意事項 * 此模型為高階設計參考，不包含具體實作細節 * 須與開發團隊密切合作，以確保模型符合實際開發需求與可行性 ## Application Development Stack ### 開發堆疊決策背景 * 開發堆疊通常由企業架構團隊與開發團隊事先協議決定 * 技術選型依賴公司策略、團隊技能、應用需求而定 * 常見堆疊包含 Spring Boot（Java）或 ASP.NET Core（C#）等 ### 本案開發堆疊整體架構 * 三個主要組件：Web 應用、Web API、Worker Service（通訊服務） * 全部運行於 AWS EC2，作業系統採用 Amazon Linux 2 * 每個組件獨立部署於 T2.medium 等級的 EC2 實例 * 所有應用以 Docker 容器形式部署 ### Web 應用堆疊 * 技術框架：ASP.NET Core 3.1 * 模式：MVC 架構 * 執行環境：Apache 作為 Web Server * 執行核心：.NET Core CLR 與 .NET Native Runtime * 容器化部署：使用 Docker 包裝與部署 ### Web API 堆疊 * 與 Web 應用相同的作業系統與部署方式 * 技術框架同樣採用 ASP.NET Core 3.1 + MVC * 部署於獨立的 EC2 實例，提供服務端點與 RESTful API ### Worker Service（通訊服務）堆疊 * 適用於長時間執行的背景任務，如批次處理、寄送郵件、查詢物流狀態 * 採用 .NET Core Worker Service 架構 * 同樣部署於 Amazon Linux 2 上的 EC2 實例 * 使用 Docker 容器執行，包含 .NET Core CLR 與 Runtime ### 架構設計注意事項 * 堆疊選擇需與開發團隊密切合作、取得共識 * 文件內容非強制標準，依專案複雜度與團隊需求調整細節層次 * 明確列出開發堆疊有助於部署計畫與環境建置標準化 ## Deployment, Networking and Infrastructure Diagrams ### 部署與網路圖的重要性 * 解決方案架構師需規劃應用程式的部署與運行方式 * 無論是否採用 DevOps，都應定義釋出與部署流程 * 部署圖與網路圖有助於開發、運維與安全團隊理解整體環境設計 --- ### CI/CD 部署流程圖（範例） * 開發使用 Visual Studio Code，推送至 Jenkins Pipeline * 進行自動建置與測試 * Docker 映像推送至 AWS ECR * 部署至目標環境如 ECS、EC2、Fargate 或 Kubernetes * 可使用 Jenkins、AWS CodePipeline、Azure DevOps 等工具 * 支援預部署檢查與條件審核（如部署前測試結果、審核流程） --- ### 基礎架構與網路架構圖（AWS 環境） * DNS 使用 Route 53，主機網域如 `funnyhatshop.com` * 使用 CloudFront 作為 CDN 發佈靜態網站（如 S3 上的 Angular 前端） * 設定防火牆與安全性群組保護服務 * 架設兩個子網區於不同的可用區（AZ）以支援高可用性 * 公有子網配置 NAT Gateway，轉送請求至私有子網的後端服務 * 私有子網部署 EC2 應用伺服器、資料庫與應用邏輯層 * ElasticCache（如 Redis）用於快取加速查詢 --- ### 外部整合與服務配置 * 對接第三方付款閘道（如 Amazon Payment Gateway） * 整合外部物流廠商的 API，處理配送通知與查詢 * 郵件通知透過 AWS SES 寄送 * 錯誤與日誌記錄寫入 AWS CloudWatch --- ### 安全性元件與服務 * 使用 AWS Cognito 進行使用者身分驗證與授權管理 * 憑證與金鑰管理由 AWS KMS 處理，例如第三方 API 認證用憑證 * 圖中可擴充加入安全架構圖，細化登入、授權、存取控制設計 --- ### 跨區部署與全球覆蓋 * 使用 CloudFront 將網站部署至三個區域：美國、歐洲、南非 * 確保各區域用戶獲得低延遲的網站存取體驗 * 每個區域可部署獨立實例以支援區域容錯與備援 --- ### 補充建議圖表類型 * **安全架構圖**：顯示認證、授權、存取控制與加密策略 * **部署流程圖**：顯示手動與自動部署路徑 * **整合架構圖**：呈現內部與外部系統互通點與資料流向 * **容器與資源調度圖**：釐清 Kubernetes/Fargate 資源規劃與佈局 --- ## Define Development Requirements ### 開發需求概述 * 架構師須與資深開發者或技術主管密切合作，定義高階開發需求 * 可用於內部開發參考，也可作為外包廠商的技術交付規範 * 聚焦於技術選型、組件分工、配置要求與實作約定 --- ### 系統分層與關注點區分（Area of Concern） * **Systems of Record**：處理交易性系統與後端邏輯（如資料庫、訂單服務） * **Systems of Engagement**：前端網站與客戶互動介面 * **Systems of Integration**：API Gateway、Web Services、ETL 流程等整合機制 * **Systems of Insight**：報表與商業智慧（BI）相關模組 --- ### 配置與基礎設施需求 * 使用 Amazon Machine Image (AMI) 建立標準應用映像檔 * 透過 Ansible Playbook 建立三類容器服務：SPA、API、通訊服務 * 使用 AWS KMS 管理密鑰與機密資訊 * 授權與身份驗證由 AWS Cognito 負責 --- ### 資料庫與儲存規劃 * 使用 MySQL 部署於 AWS RDS，考量成本與穩定性 * 啟用跨可用區（AZ）同步複寫與資料加密（RDS Encryption） * 指定資料庫實例規格（如 db.m5.xlarge）滿足高效能需求 * EC2 實例使用 EBS 作為儲存，配置每台主機 10GB 用於日誌與設定檔 --- ### 檔案與圖像處理 * 商品圖像儲存於 S3，透過應用系統與庫存管理系統間的引用連結實作 --- ### 資料移轉與初始化 * 僅針對圖像資料進行初始上傳至 S3 * 無大型資料遷移或歷史資料匯入需求 --- ### 部署策略 * 採用 DevOps 流程自動部署，依據邏輯部署架構進行分層部署 * 由 CI/CD 管理版本發佈與部署至各環境（Dev、QA、UAT、Prod） --- ### 報表與輸出需求 * 開發客製化銷售報表，提供歷史銷售資料查詢功能 * 報表可作為業務監控或管理決策的依據 --- ### 補充說明 * 本開發需求為高階描述，實際實作細節由開發團隊進一步設計與拆解 * 同時提供基礎建設與運維人員實作參考，用於資源建置與設定規劃 ## Define Cost Estimates ### 成本估算的角色與重要性 * 預算估算由專案經理或 Scrum Master 主責，整合各部門輸入 * 解決方案架構師需列出所有技術與部署組件，協助團隊評估成本 * 成本預估應涵蓋開發、基礎設施、維運、授權費與外部整合成本 --- ### 成本估算的常見分類 * **基礎設施成本**：雲端資源（如 EC2、RDS、S3、CloudFront 等）依使用量預估 * **開發成本**：依工時計算，分別列出前端、後端、API、資料庫開發等任務 * **測試與品質保證成本**：包含手動與自動化測試、人力與工具支出 * **業務分析與專案管理成本**：包含解決方案架構師、BA、Scrum Master 的人力成本 * **IT 營運成本**：系統上線後之維護、監控、備援支援等 * **外部服務整合成本**：如付款閘道、物流 API、授權系統接入等成本 * **授權與工具費用**：包含 IDE、CI/CD 工具、API 金鑰、報表系統等費用 --- ### 雲端成本估算建議 * 使用 AWS/Azure 成本估算器計算 EC2、RDS、S3、CloudWatch 等資源預估開銷 * 可考慮選擇 **按量付費（pay-as-you-go）** 或 **預留實例（Reserved Instances）** 模式 * 示意例：AWS 初期部署成本估計為 \$30,000（12 個月），後續每月依使用量波動 --- ### 成本模型建議格式 * 使用 Excel 或 Google Sheets 建立可擴展的成本表 * 按功能區塊列出：網站、API、資料庫、通訊服務、CI/CD 管線等 * 每項列出：預估工時、人力角色、每小時費率、工具/授權支出、雲資源費用 * 彙總一次性成本與每月/每年持續性成本 --- ### 成本模型目的與用途 * 協助企業在決策前理解整體實作與營運支出 * 提供專案啟動會議與高階管理層審核依據 * 成為日後預算追蹤與支出管控的參考文件 --- ### 解決方案架構師的角色 * 定義所有技術與系統元件，建立成本結構基礎 * 協助確認部署架構對應的雲資源使用情境 * 協調開發、運維與業務單位輸入資料至成本模型中 ## Review the Solution Architecture with ARB ### 解決方案架構完成後的下一步 * 準備好所有架構內容與圖表後，可加入補充圖表支援完整性（選填） * 建議先進行內部**同儕審查（Peer Review）**，邀請其他架構師提供建議 * 確認架構內容涵蓋開發、運維、安全、部署等面向，確保整體一致性 ### 提交至架構審查委員會（Architecture Review Board, ARB） * 將解決方案提交給正式的審查會議，通常為企業級機制 * 成員可能包括 IT 運維、開發主管、資深管理層與業務利害關係人 * 在審查會中簡報解決方案架構內容、決策依據與風險考量 * 須準備回答與處理與會人員提出的問題與建議 ### 審查通過後流程 * 一旦獲得 ARB 批准，即可進入下一階段：**實作與交付** * 團隊可根據已審查通過的架構進行詳細設計、開發與部署作業 * 解決方案架構文件將成為實作階段的正式依據 ### 核心重點 * 內部預審與正式審查是大型企業中常見且必要的治理機制 * 架構審查是架構品質控制與組織一致性的關鍵節點 * 通過審查是架構文件轉化為實際交付的門檻與依據 # 第 7 節：Final Section ## Additional Diagrams to Support Solution Architecture ### 業務流程圖（Business Process Diagram） * 描述使用者、系統與後端應用的互動流程 * 分為使用者區（User lane）、系統區（System lane）、後端區（Backend lane） * 常用於呈現業務流程步驟，例如儲存資料、驗證、查詢與回應 * 適合由業務分析師或業務架構師繪製 * 屬於高階流程圖，能作為開發與設計參考 ### Azure 架構圖示例 * 展示使用 Azure 雲端部署的整體架構 * 包含 ExpressRoute 私有通道、Web 前端、快取層（如 Redis Cache） * 高可用架構下配置負載平衡器與多區部署 * 虛擬網路中規劃子網路與隔離機制 * 整合 Azure Active Directory 做為身份驗證與授權機制 * 展現與第三方服務如支付閘道、物流 API 的整合路徑 ### On-Premise 架構圖示例 * 展示企業自行管理基礎設施的架構設計 * 包含外部 DNS、防火牆、L4 與 L7 負載平衡器 * 分為主動（Active）與備援（Standby）區，具備高可用性考量 * 各應用分層部署於 Web Server、Middleware、DB Server * 使用 DMZ 隔離區做網路安全控管 * 整合企業內部 Active Directory 提供帳號驗證與授權 ### 安全性架構圖示例 * 外部防火牆：過濾不明與惡意流量，保護 Web Server * SSL/TLS 憑證：保護網站入口點，確保 HTTPS 傳輸安全 * Web Server 與 API Server 間使用 Secret Key 或服務憑證驗證 * 資料庫加密：確保 Data at Rest 的安全性 * API 防護：僅允許特定來源（如 Web Server）存取後端 API * 強調資料在傳輸中與靜態存放時皆須加密與保護 ## Final Word Of Encouragement --- # 參考 [Enterprise architecture](https://en.wikipedia.org/wiki/Enterprise_architecture) [TOGAF](https://zh.wikipedia.org/zh-tw/%E5%BC%80%E6%94%BE%E7%BB%84%E4%BD%93%E7%B3%BB%E7%BB%93%E6%9E%84%E6%A1%86%E6%9E%B6) [Zachman](https://en.wikipedia.org/wiki/Zachman_Framework) [Federal enterprise architecture](https://en.wikipedia.org/wiki/Federal_enterprise_architecture) [ArchiMate](https://zh.wikipedia.org/zh-tw/ArchiMate) [C4模型](https://zh.wikipedia.org/zh-tw/C4%E6%A8%A1%E5%9E%8B) # Terminology * **解決方案架構（Solution Architecture）**：針對特定業務問題設計的技術解決方案，包含業務、應用、資料與技術視角。 * **企業架構（Enterprise Architecture, EA）**：描述組織整體的業務、應用、資料與技術藍圖，確保IT與業務策略一致。 * **架構願景（Architecture Vision）**：高階描述解決方案的初步構想、範圍與非功能性需求，供涉眾初步評估。 * **概念架構（Conceptual Architecture）**：高階架構圖與元件互動關係，描述可能的解決方案選項與核心組件。 * **邏輯架構（Logical Architecture）**：抽象的應用與資料元件圖，無關實體技術平台，描述邏輯模組與互動。 * **實體架構（Physical Architecture）**：實際部署於硬體與平台上的架構圖，包含伺服器、網路、資料庫、雲服務等。 * **敏捷開發（Agile Development）**：強調快速迭代與回饋的開發方法，支援需求隨時變更，常與Scrum搭配使用。 * **Scrum**：敏捷框架之一，包含產品待辦清單、Sprint計畫、每日站會與交付可用產品。 * **Sprint 0**：Scrum開始前的準備階段，建立初步架構與技術選型，支援後續開發。 * **IT架構遠景（IT Architecture Vision）**：以IT視角描繪未來狀態與目標，通常包含假設、約束與非功能需求。 * **業務架構（Business Architecture）**：描述企業的業務流程、組織架構、角色與業務功能。 * **資料架構（Data Architecture）**：規劃資料流、資料模型與主資料管理，支援業務流程與分析。 * **應用架構（Application Architecture）**：描述應用系統模組間互動與整合方式，支援業務自動化。 * **技術架構（Technology Architecture）**：定義技術平台、作業系統、網路、硬體、開發工具與部署模式。 * **架構審查委員會（Architecture Review Board, ARB）**：組織中負責審查與批准架構決策的委員會。 * **架構制式文件（Architecture Artifacts）**：包括願景文件、解決方案架構文件、架構圖與技術選型報告。 * **涉眾（Stakeholders）**：包含業務單位、技術團隊、管理階層等，對架構決策有興趣或受影響者。 * **非功能需求（Non-Functional Requirements, NFRs）**：包含效能、安全性、可用性、擴充性等系統品質屬性。 * **TOGAF（The Open Group Architecture Framework）**：業界常用的企業架構框架，提供架構開發方法（ADM）。 * **架構約束（Architecture Constraints）**：影響設計選項的限制條件，如法規、既有系統或預算限制。 * **架構假設（Architecture Assumptions）**：在設計初期所做的前提假設，後續可能需驗證或調整。 * **架構圖（Architecture Diagrams）**：圖形化表示業務流程、資料流、系統模組與基礎設施互動關係的視覺工具。 * **持續交付（Continuous Delivery）**：持續整合與快速部署，確保軟體快速釋出並可隨時交付。 * **雲架構（Cloud Architecture）**：基於雲端服務的系統設計，包含IaaS、PaaS、SaaS等雲服務模式。 * **微服務（Microservices）**：將應用拆分為可獨立部署與維護的小服務，各自擁有資料與功能邏輯。 * **容器（Containers）**：以輕量級方式包裝應用與其依賴，常使用Docker進行部署與執行。 * **Kubernetes**：容器編排平台，支援自動部署、擴展與管理多個容器應用。 * **Fargate**：AWS 提供的無伺服器容器服務，讓用戶專注於應用部署而非基礎設施管理。 * **DevOps**：整合開發（Dev）與運維（Ops）的實務，強調自動化、持續整合與交付。 * **系統開發生命週期（System Development Life Cycle, SDLC）**：涵蓋需求、設計、開發、測試、部署與維運的流程模型。 * **問題陳述（Problem Statement）**：明確描述業務面臨的問題或機會，作為解決方案設計的起點。 * **成本估算（Cost Estimation）**：預估實施解決方案所需的預算支出。 * **架構倉儲（Architecture Repository）**：集中儲存所有架構相關的資產與知識庫。 * **基礎設施架構師（Infrastructure Architect）**：專注於網路、伺服器、儲存等IT基礎建設設計。 * **資安架構師（Security Architect）**：負責設計安全控制措施，保障系統資料與資源的安全性。 * **領域架構師（Domain Architect）**：在特定業務領域如銷售、財務中進行架構設計與指導。 * **雲端架構師（Cloud Architect）**：專注於AWS、Azure、GCP等平台上的解決方案設計與部署策略。 * **敏捷架構（Agile Architecture）**：在敏捷開發流程中持續演進的架構設計方式，強調回饋迭代與最小可行架構。 * **Scaled Agile Framework（SAFe）**：大規模企業使用的敏捷框架，涵蓋團隊層、程式層與組織層的架構與交付實務。 * **架構模式（Architecture Patterns）**：可重複使用的架構設計解法，如層次式架構、事件驅動架構等。 * **架構原則（Architecture Principles）**：指導架構決策的基本準則，如模組化、鬆耦合、高內聚等。 * **上下文圖（Context Diagram）**：顯示系統與外部實體互動的圖表，用於界定系統邊界與資訊流。 * **2B架構（To-Be Architecture）**：目標狀態架構，描述實施解決方案後預期的系統與業務結構。 * **As-Is架構（As-Is Architecture）**：現況架構，呈現目前的系統實作、流程與應用組件。 * **涉眾關注（Stakeholder Concerns）**：涉眾對系統的期望與限制條件，如風險、效能、維運成本等。 * **架構用例（Architecture Use Case）**：描述架構設計中要支援的業務場景與互動流程。 * **ETL（Extract, Transform, Load）**：資料整合技術，將資料從多個來源提取後轉換並載入資料倉儲。 * **ESB（Enterprise Service Bus）**：企業服務匯流排，整合各系統間的通訊與訊息轉換平台。 * **API（Application Programming Interface）**：系統對外提供服務的標準介面，支援整合與擴充。 * **UML（Unified Modeling Language）**：統一建模語言，用於描述軟體系統結構與行為的標準符號與圖表。 * **認證（Authentication）**：識別使用者身份的過程，通常以帳號密碼、OAuth、SSO等方式實作。 * **授權（Authorization）**：判斷已驗證使用者是否有權限執行特定操作的機制。 * **加密（Encryption）**：透過演算法將資料轉換為不可讀格式，以防止未授權存取。 * **雜湊（Hashing）**：產生資料指紋的一種不可逆運算方式，常用於驗證資料完整性與密碼儲存。 * **網段（Subnet）**：IP位址的子集合，用於區分與管理網路中的主機。 * **DMZ（Demilitarized Zone）**：非軍事區，網路安全架構中用於放置公開服務的隔離區域。 * **系統操作（System Operations）**：指系統部署後的維護、監控、效能管理與問題處理流程。 * **保固期（Warranty Period）**：系統上線後由架構師或開發團隊負責觀察與調整的一段時期。 * **持續整合（Continuous Integration, CI）**：開發人員將程式碼頻繁合併至主幹並自動建置與測試的實務。 * **持續部署（Continuous Deployment, CD）**：將通過測試的程式碼自動部署到生產環境的流程。 * **技術堆疊（Technology Stack）**：建構與執行應用程式所使用的技術組合，如前端框架、後端語言、資料庫等。 * **應用元件（Application Components）**：應用系統中的模組、服務與服務介面等邏輯或實體單元。 * **資料流圖（Data Flow Diagram, DFD）**：顯示資料在系統中流動方式的圖表，強調處理與來源/目的地。 * **部署拓撲圖（Deployment Topology Diagram）**：描述系統在物理或虛擬基礎設施上的部署方式圖表。 * **架構倉儲工具（Architecture Repository Tools）**：用於儲存、版本管理與協作架構文件的平台，如Sparx EA、Archi。 * **架構治理（Architecture Governance）**：架構相關決策、標準、流程與審查制度的總稱。 * **架構回饋迴圈（Architecture Feedback Loop）**：架構設計與實作中持續獲得回饋與調整的流程。 * **業務用例（Business Use Case）**：描述業務流程中各角色與系統的互動情境。 * **風險矩陣（Risk Matrix）**：評估架構風險發生機率與影響程度的工具，常用於決策過程。 * **技術債（Technical Debt）**：為了快速交付而做出的次佳技術選擇，日後需付出額外維護成本。 * **架構願景文件（Architecture Vision Document）**：描述解決方案初步構想的文件，用來協助涉眾理解業務問題、評估解決選項與預估投資效益。 * **Sprint 架構文件（Sprint Architecture Document）**：在敏捷開發初期（如 Sprint 0）編寫的文件，用以描述高階架構構想與實作建議。 * **問題陳述（Problem Statement）**：由業務使用者定義的主要痛點或新需求，說明業務與 IT 領域受到哪些挑戰或需改善。 * **業務願景聲明（Business Vision Statement）**：描述業務期望透過本解決方案達成的成果與未來目標，作為架構設計的指導方針。 * **變更驅動與機會（Change Drivers and Opportunities）**：指出推動架構變更的原因（如法規、競爭、市場壓力）與潛在效益。 * **業務能力衝擊（Business Capability Impact）**：列出受影響的業務能力，並標註為新增、變更或移除，通常可用能力模型或價值鏈圖表示。 * **業務與技術目標（Business and Technology Objectives）**：具體說明解決方案要解決的業務目標，以及系統遷移、替換、汰除等技術目標。 * **架構願景（Architecture Vision）**：包含設計原則（principles）、假設（assumptions）與限制（constraints），以及現況（As-Is）與目標（To-Be）概念架構。 * **As-Is 概念架構（As-Is Conceptual Architecture）**：用圖示方式呈現目前系統架構、整合與業務環境的全貌。 * **To-Be 概念架構（To-Be Conceptual Architecture）**：描繪解決方案實施後的預期架構狀態，包含應用、資料、安全與技術元件。 * **非功能需求（Non-Functional Requirements, NFRs）**：高階的系統品質屬性，例如效能、可用性、容量、操作性、安全性、持續營運等。 * **提案解決方案選項（Proposed Solution Options）**：列出可行的建置選項，如內部開發、外部採購、合作開發，及相關技術與平台。 * **技術選項（Technology Options）**：針對不同的解決方案，提供相應技術堆疊、部署模式（雲端／地端）與現有技術可重用性。 * **架構準則與標準（Architecture Guidance and Standards）**：解釋所依循的架構原則、標準或框架（如 TOGAF、SAFE），確保一致性與可治理性。 * **粗略預算估算（Rough Cost Estimate）**：由開發／技術團隊提供的初步成本預估，包含授權費用、開發費、人力資源與潛在雲端支出等。 * **高階時程（High-Level Timeline）**：簡略列出實施時程與重要里程碑，協助業務預估專案進度與資源配置。 * **風險評估（Risk Assessment）**：指出實施與不實施該解決方案可能面臨的重大風險，有助於業務評估投資決策。 * **可行性分析（Feasibility Analysis）**：評估方案是否實際可行，從技術、成本、人力與風險角度加以說明。 * **業務案例（Business Case）**：支持投資的財務與策略分析，說明解決方案對業務價值鏈的貢獻與投資報酬率。 * **架構原則（Architecture Principles）**：指導解決方案設計與決策的基本準則，例如可擴展性（Scalability）、模組化（Modularity）、重用性（Reusability）等。 * **架構假設（Architecture Assumptions）**：在提出方案選項時所做的前提假設，例如「使用者數量不超過1000人」、「所有系統皆支援API整合」。 * **架構限制條件（Architecture Constraints）**：限制方案設計的條件，例如「必須使用現有ERP系統」、「不得引入開源軟體」、「僅能部署於Azure」。 * **系統互動通道（Interaction Channels）**：使用者將透過哪些介面與系統互動，如Web、Mobile、API、第三方整合平台。 * **業務持續性（Business Continuity）**：系統需具備的備援與災難復原機制（DR），保證業務不中斷運作的能力。 * **資安需求（Security Requirements）**：對資料保護與系統安全的要求，如身分驗證、授權、加密、審計日誌、資安法規遵循（如GDPR）。 * **操作與監控需求（Operations and Monitoring Requirements）**：系統上線後的運維策略，包括監控工具（如Prometheus、CloudWatch）、告警設定與維運手冊。 * **網路需求（Networking Requirements）**：解決方案所需的網路架構與規則，例如子網（Subnet）、防火牆規則（Firewall Rules）、VPN通道、DMZ設計。 * **使用者介面需求（User Interface Requirements）**：前端介面設計上的指引與期望，例如支援多語系、無障礙設計、響應式設計。 * **架構需求（Architectural Requirements）**：對整體架構應具備特性之要求，如高度可用性、可觀測性、容錯能力、部署自動化。 * **應用路線圖（Application Roadmap）**：列出未來應用系統的預定遷移、整合或淘汰時程，支援長期IT規劃。 * **現有系統重用（Reuse of Existing Systems）**：評估是否可利用現有平台、應用或元件，以降低建置成本與時程。 * **架構決策紀錄（Architecture Decision Records, ADRs）**：記錄每項關鍵架構選擇背後的背景、選項、評估依據與決策結果。 * **涉眾評審（Stakeholder Review）**：與業務、IT與高層等涉眾確認架構構想、收集意見並修正初步方案。 * **多方案比較分析（Solution Option Comparison）**：以表格或圖表比較建置／採購／合作等選項的優劣，包括風險、成本、技術成熟度等。 * **架構輸出物（Architecture Deliverables）**：在Vision文件中定義後續應產出的工件，例如詳細架構文件（Solution Architecture Document）、部署藍圖、技術規格書。 * **估算假設（Estimation Assumptions）**：說明成本與時程預估中使用的假設，例如「第三方API已就緒」、「外部供應商能準時交付」。 * **初步供應商分析（Preliminary Vendor Analysis）**：若業務尚未指定廠商，列出建議供應商與選型評估標準（如功能完整性、技術支援、總體擁有成本）。 * **授權與法遵考量（Licensing and Compliance Considerations）**：評估所提方案是否涉及授權費用、契約限制或必須符合特定法規。 * **建議行動（Recommended Action）**：基於所有前述內容，提供清晰建議，例如「進入POC階段」、「採購SaaS方案」、「不建議繼續進行」。 * **產品負責人（Product Owner）**：代表業務利益相關者，負責定義產品需求與優先順序。 * **解決方案架構師（Solution Architect）**：負責針對特定業務需求設計整體解決方案，涵蓋應用、資料、技術與整合面向。 * **Scrum 主持人／專案經理（Scrum Master / Project Manager）**：協助團隊排除障礙，確保專案順利推進與流程符合敏捷原則。 * **業務分析師（Business Analyst）**：負責分析與記錄業務需求，轉換為技術可執行的規格。 * **資深開發者／技術負責人（Lead Developer）**：負責技術設計與開發指導，協助架構師完成實作細節。 * **測試負責人（QA Lead）**：主導測試策略、測試案例設計與品質保證活動。 * **IT 營運人員（IT Operations）**：負責系統部署、維運、監控與資安維護等生產環境管理。 * **架構審查委員會（Architecture Review Board, ARB）**：由企業架構師與各領域架構師組成，負責審核與批准架構決策。 * **企業架構師（Enterprise Architect）**：關注整體企業架構藍圖，確保業務與 IT 策略對齊。 * **領域架構師（Domain Architect）**：專注於特定業務領域的架構設計，如財務、人資、零售等。 * **As-Is 架構（As-Is Architecture）**：現況系統架構，描述現有解決方案的技術與運作情況。 * **To-Be 架構（To-Be Architecture）**：預期的目標架構，描述未來解決方案的實施樣貌。 * **C4 模型（C4 Model）**：一種漸進式架構建模方法，分為四個層級：情境（Context）、容器（Container）、元件（Component）、程式碼（Code）。 * **系統情境圖（System Context Diagram）**：C4 模型第一層，用來展示系統與外部實體之間的互動關係。 * **功能影響圖（Capability Impact Model）**：顯示新解決方案將如何影響現有業務功能或能力的圖示。 * **業務問題陳述（Business Problem Statement）**：定義業務遇到的痛點、需求或限制，作為解決方案設計依據。 * **業務願景聲明（Business Vision Statement）**：說明業務期望透過此解決方案達成的目標與價值。 * **變更驅動與機會（Change Drivers and Opportunities）**：推動本次架構變更的因素與所帶來的潛在價值。 * **架構原則（Architecture Principles）**：導引架構設計的基本規則，例如安全性、可用性、擴展性。 * **架構假設（Architecture Assumptions）**：在設計過程中預設成立的條件，可能影響技術選擇與整合方式。 * **架構限制條件（Architecture Constraints）**：業務或技術上的限制條件，例如預算、地理位置、法規遵循等。 * **非功能性需求（Non-Functional Requirements, NFRs）**：與系統品質相關的需求，如效能、可用性、可擴展性與安全性。 * **初步解決方案選項（Solution Options）**：提出多種可行技術方案供業務比較選擇。 * **估算（Estimation）**：針對時間、人力與成本的初步評估，常用 T-shirt sizing（S/M/L/XL）表示。 * **T-shirt Sizing**：一種估算技術，根據工作量粗略分類（小/中/大/特大）以便於高階規劃。 * **雲端服務（Cloud Services）**：如 EC2、RDS、S3、CloudFront、SES 等 AWS 雲端服務，用以支援應用部署與運作。 * **自動擴展群組（Auto Scaling Group）**：根據流量負載自動擴增或縮減伺服器實例的機制。 * **負載平衡器（Load Balancer）**：分配流量至多個伺服器實例，提升系統可用性與效能。 * **監控服務（Monitoring Services）**：如 CloudWatch 等工具，用來監控系統狀態與發出警示。 * **寄送服務（Email Service, SES）**：提供電子郵件傳遞功能，常用於交易通知與發票寄送。 * **內容傳遞網路（Content Delivery Network, CDN）**：如 CloudFront，用來加速不同地區使用者存取速度。 * **OAuth 認證（OAuth Authentication）**：開放式授權協議，支援第三方平台（如 Google、Facebook）登入。 * **網路隔離（Subnet, VPC）**：在雲端環境中實作網路分段與安全隔離的設計。 * **資安憑證（X.509 Certificates）**：用於 HTTPS 與資料傳輸加密的標準憑證。 * **例外處理與稽核（Exception Handling & Auditing）**：記錄與回報系統異常，以及存取與變更資料的操作紀錄。 * **CI/CD 管線（Continuous Integration / Continuous Deployment Pipeline）**：自動化建置、測試與部署流程，提高交付效率與穩定性。 * **微服務架構（Microservice Architecture）**：將應用拆分為小型獨立模組，可獨立開發與部署。 * **容器化（Containerization）**：使用技術（如 Docker）將應用與其依賴封裝，便於移植與部署。 * **解決方案實施計畫（Solution Implementation Plan）**：根據所選方案規劃的開發、測試、部署與上線策略。 * 架構審查委員會（Architecture Review Board）：由多位架構師與相關利害關係人組成，負責審查與批准解決方案架構的設計與實施。 * 解決方案架構（Solution Architecture）：針對特定業務問題或需求所設計的整體技術與應用架構。 * 非功能性需求（Non-Functional Requirements, NFRs）：系統在性能、可用性、安全性、擴展性等方面的需求，非功能層面。 * 架構視野（Architecture Vision）：高層次、戰略性的架構描述，通常用來描繪未來架構的目標與原則。 * 現況架構（As-Is Architecture）：描述現行系統架構的實際狀況，做為評估改變前的基準。 * 目標架構（To-Be Architecture）：描述在特定時間點未來欲達到的系統架構樣貌。 * 架構目標（Architecture Objectives）：解決方案架構欲達成的技術與業務目標。 * 架構限制（Architecture Constraints）：在設計與實施過程中受到的條件限制，如技術選型、預算或資源。 * 架構風險（Architecture Risks）：在架構設計與實施過程中可能對成功產生威脅的因素。 * 企業能力地圖（Business Capability Map）：描繪企業提供價值所需具備的核心與支持能力。 * 應用路線圖（Application Roadmap）：規劃應用系統在未來數年內的發展、替換、淘汰與整合計劃。 * 概念架構圖（Conceptual Architecture Diagram）：以高層次方式呈現系統主要組成與其互動關係。 * C4 模型（C4 Model）：一種分層次的系統架構建模方式，分為上下文圖、容器圖、元件圖、程式碼圖。 * 用例圖（Use Case View）：呈現系統中使用者與系統功能互動的情境圖。 * 服務水準協議（Service Level Agreement, SLA）：系統服務的可用性與響應時間等標準的協議。 * 容錯性（Fault Tolerance）：系統在部分元件失效時仍可維持運作的能力。 * 自動擴展（Auto Scaling）：根據系統負載自動調整資源以維持性能的機制。 * 負載平衡器（Load Balancer）：分散流量至多個伺服器以提升性能與可用性。 * 地區冗餘（Regional Redundancy）：在多個地理區域部署以確保業務持續性。 * CDN（Content Delivery Network）：分散式伺服器架構，提升全球使用者的內容存取速度。 * AWS CloudFront：Amazon 提供的 CDN 服務。 * AWS Cognito：AWS 提供的身份驗證與授權服務。 * OAuth：開放標準的授權協議，允許使用者第三方授權訪問其資訊。 * 多因素驗證（MFA）：需提供兩個或以上驗證因子才能進行登入的安全機制。 * 日誌管理（Logging）：系統中對操作、錯誤等事件的紀錄，用於偵錯與監控。 * 監控服務（Monitoring Service）：追蹤系統運作狀態與資源使用的工具與流程。 * 雲端基礎設施（Cloud Infrastructure）：雲端平台提供的運算、儲存、網路等基礎資源。 * 雲端運算服務（Cloud Services）：例如 AWS、Azure 提供的各種即用型運算資源與平台服務。 * 私有子網（Private Subnet）：雲端中隔離的網段，僅允許內部或有限訪問。 * 公有子網（Public Subnet）：允許外部存取的網段，用於對外服務。 * 防火牆規則（Firewall Rules）：管控進出流量允許或拒絕的設定。 * API Gateway：用來管理、保護與監控 API 存取的服務。 * 資料加密（Data Encryption）：確保資料在傳輸中與儲存時的機密性。 * 資料遷移（Data Migration）：從舊系統將資料轉移到新系統的過程。 * 部署策略（Deployment Strategy）：定義如何將應用程式部署到目標環境的方式與流程。 * CI/CD（Continuous Integration/Continuous Deployment）：持續整合與持續部署，提升交付效率與品質。 * Jenkins：自動化建置與部署的開源 CI/CD 工具。 * 容器化（Containerization）：使用容器（如 Docker）封裝應用以提升可攜性與一致性。 * Docker：主流的容器技術平台。 * Kubernetes：容器協調管理平台，支援高可用與自動擴展。 * RDS（Relational Database Service）：AWS 提供的關聯式資料庫代管服務。 * EC2（Elastic Compute Cloud）：AWS 提供的虛擬伺服器服務。 * S3（Simple Storage Service）：AWS 的物件式儲存服務。 * KMS（Key Management Service）：AWS 提供的加密金鑰管理服務。 * 微服務架構（Microservices Architecture）：將應用程式拆分為獨立可部署的小型服務的架構風格。 * MVC（Model-View-Controller）：常見的軟體開發架構模式，分離資料處理與使用者介面。 * E-R 模型（Entity-Relationship Model）：資料庫結構的實體與關聯模型。 * BPMN（Business Process Model and Notation）：用來建模業務流程的圖示標準。 * SLA違約風險（SLA Breach Risk）：指系統若無法滿足 SLA 所帶來的業務風險。 * 認證（Authentication）：確認使用者身分是否合法的程序。 * 授權（Authorization）：確認使用者是否有權限執行特定動作或存取特定資源。 * 整合架構（Integration Architecture）：描述系統之間資料交換與互通的技術架構。 * 資料治理（Data Governance）：確保資料品質、權責與保護的制度與流程。