架構參考資料（企業架構師 / 設計權威）
適用於受監管的歐盟/法國環境（銀行、醫療、國防）。法規細節會持續演變：任何標示為「需驗證」的內容，在納入交付物之前，必須查證現行官方文本。
參考文獻索引
references/togaf-archimate.md— 規劃架構工作（ADM 階段、交付物、治理、合規審查）或使用 ArchiMate（層次、元素、關係、視角）進行建模時閱讀。完整路徑${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/togaf-archimate.mdreferences/urbanisation.md— 產出或使用法國資訊系統地圖（區域/街區/島嶼、地圖）、總體規劃、應用程式組合評估（TIME）或合理化/除役計畫時閱讀。完整路徑${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/urbanisation.mdreferences/adr.md— 撰寫或審查架構決策記錄或決策矩陣（Nygard、MADR、Y-statement、加權標準、虛構範例）時閱讀。完整路徑${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/adr.md
相關交付物範本：${CLAUDE_PLUGIN_ROOT}/skills/deliverables/templates/dat.md、interface-contract.md、flow-matrix.md。
法規細節（GDPR、DORA、NIS2、HDS、II 901、IGI 1300…）位於 sector-compliance 技能及其行業參考文獻中（${CLAUDE_PLUGIN_ROOT}/skills/sector-compliance/references/）；本技能僅涵蓋架構相關的影響。
1. 角色：設計權威
負責：架構原則與標準；目標架構與藍圖；結構性決策（ADR）；跨領域與專家的一致性；豁免（帶有效期限）；架構合規審查；架構層級的技術債務登記。 不負責：安全風險接受（業務風險負責人 / 授權主管，由 RSSI 提供建議）；個人資料決策（資料控管者，由 DPO 提供建議）；預算/時程仲裁（COPIL）；生產環境變更（CAB）。
審查關卡
| 關卡 | 時機 | 檢查事項 |
|---|---|---|
| G0 範疇界定 | 範疇備忘錄 | 符合目標/藍圖、已識別選項、法規範圍、資料主權分類 |
| G1 設計 | DAT / 介面合約草案 | 原則遵循、NFR 量化、整合模式、資料擁有權、安全架構、可逆性 |
| G2 建置前 | 設計凍結 | ADR 已接受、豁免已簽署、流程矩陣完整、營運/災難復原設計 |
| G3 上線前 | 進入 go/no-go 決策前 | 實作成果 vs DAT、已產生的債務已登記、DR 已測試、DORA 登記 / 相依性圖表已更新 |
審查結果：合規 / 有保留合規（行動+日期）/ 豁免（風險負責人+有效期限）/ 不合規（阻擋）。
2. 架構原則
格式（TOGAF 風格）：名稱 — 陳述 — 理由 — 影響。維持 10-15 條，每條皆可在審查中測試。適用於受監管整合環境的預設集合：
| # | 原則 | 可測試的影響 |
|---|---|---|
| P1 | 內建業務持續性 | 每項關鍵功能都有明確的 RTO/RPO，並已透過設計達成且經過測試 |
| P2 | 預設與內建的安全與隱私（GDPR 第 25 條） | 設計前資料已分類（DICT）；最小權限；傳輸中與靜態加密 |
| P3 | 每個資料領域單一事實來源 | 每個資料實體都有一個主系統和指定擁有者；其他系統持有受控副本 |
| P4 | 透過受管介面實現鬆散耦合 | 不得直接存取其他應用程式的資料庫；所有交換皆透過合約化的 API、訊息或檔案進行 |
| P5 | 重用優先於採購，採購優先於自建 | 除非 ADR 另有說明，否則使用現有共享平台（MFT、API 閘道、IAM、排程器） |
| P6 | 標準與開放格式 | 偏好開放協定/格式；專有格式須有可逆性計畫 |
| P7 | 可逆性與退出 | 每項外部服務都有退出計畫；資料可以文件化格式匯出 |
| P8 | 可操作性是一項需求 | 監控、日誌、排程、重啟和 DEX 需與解決方案一同設計 |
| P9 | 可追溯性與可稽核性 | 端到端關聯 ID；稽核軌跡依法律要求保留 |
| P10 | 依分類決定資料駐留與主權 | 根據資料分類選擇託管方式（參見第 6 節） |
| P11 | 簡單化與合理化 | 僅在沒有現有元件符合時才引入新元件；每次更換都需規劃除役 |
| P12 | 自動化交付鏈 | 基礎設施與部署即程式碼，環境可重現 |
3. 目標與過渡架構
- 基準架構（現狀）、目標架構（截至規劃時限的未來狀態，通常為 3-5 年）、過渡架構（平台：穩定、可操作、能交付價值的中間狀態）、差距分析（新增、移除或變更的內容）、藍圖（工作包、相依性、除役日期）。
- 每個過渡架構本身必須是可操作的（有支援、監控、災難復原涵蓋、文件化）——專案可能就此停下。
- 共存橋接（暫時同步、避免雙重寫入、防腐層）是頭等元件：需有負責人、成本、淘汰日期、債務項目。
- 「暫時性」若無淘汰日期會變成永久：在 G1 拒絕此類設計。
- 若既有系統龐大且文件不良，偏好增量遷移（絞殺者模式：在 façade 後方逐步將功能路由至新系統）而非一次性替換。
4. 整合架構（宏觀層級）
詳細設計屬於整合專家；架構師設定模式與規則。
| 模式 | 適用時機 | 避免情境 | 注意事項 |
|---|---|---|---|
| 點對點 | 少數穩定流程、戰術性 | 許多消費端、頻繁變更 | 形成混亂蜘蛛網（n² 條連線）、缺乏集中監控 |
| 中樞與輻射 / EAI / ESB | 許多異質系統、轉換、集中治理 | 中樞成為瓶頸或業務邏輯單體 | 保持匯流排不含業務邏輯 |
| 透過 MFT 的檔案傳輸 | 批次處理、高容量、合作夥伴交換、既有系統（在銀行/IBM i 環境中非常常見） | 需要即時性 | 完整性檢查、命名、截止時間、重新傳送、加密、不可否認性 |
| API 主導（系統/流程/體驗層） | 可重用服務、數位通路、合作夥伴 API | 大量資料搬移 | API 管理、版本控制、配額、OAuth2/mTLS |
| 事件驅動（發布/訂閱、事件串流、CDC） | 解耦反應、即時傳播、許多消費端 | 跨系統需要強交易一致性 | 排序、冪等性、綱目演進、重播、事件擁有權 |
| 資料平台（DWH、資料湖、湖倉一體、資料網格） | 分析、法規報告、機器學習 | 營運交易整合 | 血緣、品質、保留、敏感資料隔離 |
| MDM / 主資料庫 | 共享主資料（客戶、產品、組織、病患身分） | 資料有單一自然擁有者 | 治理與管理成本是真正的成本 |
經驗法則：僅當呼叫方真正需要立即得到答案時才使用同步呼叫；跨領域預設非同步；為每個流程設計失敗情境（帶有退避的重試、死信佇列、重播、冪等消費端）；使用 outbox 模式而非雙重寫入；僅在有限範圍內使用規範性資料模型（企業級規範模型很少存活）；為每個合約進行版本控制；維持端到端單一關聯 ID。
5. 非功能性需求
量化每個 NFR；「高可用性」不是一個需求。
| 類別 | 指標 / 問題 | 陷阱 |
|---|---|---|
| 可用性 | 一段時間內百分比、服務時數、允許的計畫性停機 | 忽略相依性鏈結；測量基礎設施而非服務 |
| 持續性 | 每個業務功能的 RTO / RPO (DMIA / PDMA)、MTPD | 使用非同步複製卻承諾 RPO 為 0；忽略批次重啟 |
| 效能 | 吞吐量、p95/p99 延遲、批次處理時間窗、尖峰因子、成長率 | 測試平均值而非尖峰值；忘記月底尖峰 |
| 可擴展性 | 截至規劃時限的容量、彈性 | 授權模型成本非線性成長 |
| 安全性 | DICT 評級、IAM、加密、日誌記錄、隔離 | 安全性在設計完成後才加入 |
| 可操作性 | 監控、警示、日誌、重啟、排程、自動化 | DEX 在上線後才撰寫 |
| 可觀測性 | 追蹤、指標、日誌、關聯、業務 KPI | 缺乏跨中介軟體的端到端視圖 |
| 可逆性 | 退出計畫、匯出格式、退出時間與成本 | 僅有合約條款，從未測試 |
| 互通性 | 標準（例如支付領域的 ISO 20022、醫療領域的 HL7 FHIR——需驗證行業授權） | 標準的本地方言 |
| 合規 / 資料駐留 | 資料位置、保留、法定保留、稽核 | 備份和日誌儲存在約定區域之外 |
| 可維護性 | 升級頻率、供應商支援日期 | 支援終止日期恰逢專案中段 |
| 永續性 | 資源效率（法國的 RGESN 生態設計指南——需驗證狀態） | 過大的非生產環境 |
可用性速查表（每年）：99 % ≈ 3.65 天；99.5 % ≈ 1.83 天；99.9 % ≈ 8.76 小時；99.95 % ≈ 4.38 小時；99.99 % ≈ 52.6 分鐘；99.999 % ≈ 5.3 分鐘。串聯鏈：A = A1 × A2 × …；備援對：A = 1 − (1 − A1)(1 − A2)（假設故障獨立——很少完全成立）。 RPO/RTO 一致性：RPO 受複製模式和備份頻率限制；RTO 包含偵測、決策、容錯移轉、資料修復、批次追趕和合作夥伴重新同步——不僅是技術切換時間。
6. 雲端策略與主權
先分類，再託管：資料分類驅動託管選項。
| 資料 / 系統分類 | 典型託管選項（需根據現行規則驗證） |
|---|---|
| 公開 / 內部、非敏感 | 具有標準控制措施的公有雲可接受 |
| 個人資料（GDPR） | 偏好歐盟託管；向 EEA 以外傳輸需要第 V 章依據和傳輸影響評估 |
| 健康個人資料（法國） | 需要 HDS 認證的託管服務供應商（Code de la santé publique, Art. L.1111-8）；最近的 HDS 基準增加了 EEA 內的資料位置要求——需驗證當前版本和過渡日期 |
| 國家服務、國家營運商及指定 GIP 的特定敏感性資料 | SecNumCloud 合格服務，或 ANSSI 認定為等效的 EU/EEA 認證：SREN 法律第 31 條（2024）、décret n° 2026-272（2026 年 4 月 14 日）、2026 年 8 月 12 日命令；「雲端中心」學說（2021 年，2023 年更新）將此期望擴展到其他國家資訊系統——這些文本中有豁免制度 |
| 擴散限制（DR） | 依照 II 901 認證的系統；特定的託管限制——需驗證 |
| 機密 / 極機密（IGI 1300） | 專用認證基礎設施；通常排除公有雲 |
| 銀行關鍵或重要功能 | 允許，但須符合 DORA 第三方要求、外包規則（EBA 指引）及監理機關通知（如要求）——需驗證 |
SecNumCloud：ANSSI 針對要求基準 v3.2（2022 年 3 月 8 日；2026 年 8 月 12 日命令核准的版本）對雲端服務供應商的認證。除了技術安全要求外，其 §19.6 禁止非歐盟域外法律：供應商設立在歐盟，非歐盟股東個人上限為 24%，集體上限為 39%，資料儲存於歐盟，且服務的管理和監督均來自歐盟。「主權」行銷標籤並非認證：需要求認證證書及其確切服務範圍。 域外風險：針對資料分類評估非歐盟法律存取風險（例如，美國 CLOUD Act、FISA s.702）；使用客戶持有金鑰（HSM/BYOK/HYOK）的加密可以降低但並非總是消除風險。 可逆性條款（合約 + 架構）：退出計畫與協助期間；以文件化的開放格式匯出資料與中繼資料，費用不得過高；刪除證明；文件與設定匯出；退出期間的服務持續性；通知期間；次處理者清單；稽核權。歐盟資料法案（Regulation (EU) 2023/2854, Chapter VI）自 2025 年 9 月 12 日起適用：供應商必須支援切換，且僅能收取實際切換/出口費用至 2027 年 1 月 12 日，之後不得收費。 架構促成要素：可攜式工作負載（容器、IaC）、標準資料庫或文件化的遷移路徑、避免核心功能深度耦合專有 PaaS（除非 ADR 接受）、定期退出測試（至少匯出 + 在其他地方還原）。 雲端遷移選項（6R/7R）：停用、保留、原機遷移、重新定位、更換平台、重構、重新購買——根據組合評估（參見都市化參考文獻）為每個應用程式決定。
7. 技術債務管理
- 類型：架構（錯誤模式、耦合）、過時（終止支援版本）、程式碼、資料（品質、重複）、營運（手動步驟）、文件、安全性（延遲修復）。
- 登記簿：項目、類型、位置、原因（透過 ADR 的有意 / 無意）、利息（每個期間的成本或風險）、本金（修復成本）、負責人、截止日期、ADR/豁免連結。
- 過時日曆：作業系統、資料庫、中介軟體、執行時期、ERP 版本、IBM i 版本的供應商終止支援日期；標記任何在 24 個月內到期的項目。
- 資金配置：預留明確容量（常見建議為交付容量的 15-20%——因組織而異）；專案豁免產生的債務計入該專案成本。
- 影響關鍵功能的債務屬於 ICT 風險：不僅在 IT 待辦事項中報告，還應在風險框架中報告。
8. 從架構觀點看 DORA ICT 風險
法規 (EU) 2022/2554，自 2025 年 1 月 17 日起適用，並由 RTS/ITS 補充。以下條文編號僅供參考：在交付物中引用前，請在 EUR-Lex 上確認。
| DORA 主題 | 架構貢獻 |
|---|---|
| ICT 風險管理框架（第 6 條） | 架構原則、標準和目標架構作為文件化的控制措施 |
| 識別（第 8 條） | ICT 資產和資訊資產清單；關鍵功能的業務功能與相依性對映；資產相關性 |
| 保護與預防（第 9 條） | 安全架構原則、網路隔離、零信任模式（如適用）、變更管理流程納入 |
| 偵測（第 10 條） | 日誌和監控的架構（集中式安全資訊與事件管理 (SIEM)、異常偵測管道）；端到端可觀測性 |
| 回應與復原（第 11 條） | 災難復原 (DR) 架構、備援、容錯移轉程序、從備份重建的能力；包含在過渡架構中 |
| 備份政策與程序（第 12 條） | 備份架構（頻率、媒體類型、隔離、恢復測試）；RPO/RTO 要求 |
| 學習與演進（第 13 條） | 事後檢討回饋到架構原則和模式；ADR 記錄了學習 |
| 通訊（第 14 條） | 中斷期間的通訊架構（緊急通知系統、利害關係人對映） |
| ICT 第三方風險（第 28-44 條） | 可逆性條款、退出計畫、供應商鎖定評估、關鍵依賴識別；架構中的合約要求 |
| 數位營運韌性測試（第 24-27 條） | 威脅情資導向的滲透測試 (TLPT) 的架構考量：範圍、測試環境、第三方依賴排除；架構文件支援測試場景 |
架構師關鍵行動：確保現行 DORA RTS/ITS 為合規行動提供資訊；在 ADR 中記錄架構韌性決策；在新的依賴關係（特別是第三方）建立時維護依賴關係圖；將 DORA 要求追溯映射到現有架構原則和控制措施中。
9. 跨專家一致性檢查清單
在 G1 和 G2 審查期間，協調以下專家並簽署其觀點：
- 安全架構 (RSSI / 網路安全團隊)：資料分類 (DICT)、安全模式 (P2)、加密、IAM、網路隔離、安全事件監控。
- 資料管理 / DPO：個人資料歸檔、同意管理、資料保留期限、資料主體權利 (DSR) 的處理架構、資料保護影響評估 (DPIA) 輸入。
- 營運 / SRE：可監控性、可觀測性、排程、部署、備份、災難復原、容量規劃、非功能性需求 (NFR) 測量。
- 整合專家：協定、模式、API 治理、中介軟體、效能（端點延遲）、流程原子性。
- 合規 / 法務：法規映射（GDPR、DORA、行業特定）、境外資料傳輸、外包分類、主權要求。
- 業務負責人：功能優先級、持續時間 / 服務水準目標 (SLO)、中斷容忍度、預算影響、業務持續性計畫 (BCP) / 災難復原 (DR) 預期。
- 採購：供應商鎖定、合約終止、退場費用、許可證模式、第三方風險管理。
- 應用團隊（零售、商業、核心、渠道等）：功能影響、遷移路徑、回歸測試、資料所有權。
- 第三方 / 合作夥伴：服務水準協議 (SLA) / 操作級別協議 (OLA)、技術合約（介面合約 API、檔案格式、時間表）、退出選項。
10. ADR 架構決策記錄
- ADRs 是結構性決策，而非設計文件：捕捉上下文（驅動力、限制、選項）、決策（選擇），以及決策的後果（正面與負面）。
- 格式：針對此技能的使用，使用位於
references/adr.md的 MADR 範本，此範本與 TOGAF 背景中的架構決策特別相關。根據需要補充權重決策矩陣、圖表或場景分析。 - 層級：
- 層級 1（策略）：架構原則、目標、全域藍圖決策——由架構審查委員會 (ARB) 或設計權威發布。
- 層級 2（結構）：領域級模式、重大整合決策、技術選擇——由領域架構師在層級 1 的邊界內發布。
- 層級 3（實作）：團隊級決策（資料庫架構、框架選擇）——由實作團隊發布。
- 什麼時候不需要 ADR：明顯的選擇（COTS 評估中的標準供應商）、可逆且低成本的決策（本地設定、測試框架）、純技術升級（次要平台版本）。
- 替代方案：每個 ADR 應該考慮至少一個合理的替代方案，即使被拒絕。
- 生命週期：提議 → 已接受（層級 1）→ 已取代（連結到後續 ADR）→ 已廢棄（設計從未完成或已被取代）。
11. 有用資源
- TOGAF 標準（第 10 版）
- ArchiMate 規格（3.2 版）
- MADR ADR 範本
- ANSSI SecNumCloud
- 法國數位生態設計指南 (RGESN)——需驗證
- EUR-Lex 上的 DORA
- 歐盟資料法案
- SREN 法律（法國，2024）
此參考資料為實務摘要，非官方標準或法律的替代品。在涉及關鍵或受監管環境的決策中，始終查證官方來源。