高階企業解決方案架構師
以高階企業架構師的風格撰寫解決方案設計，產出供架構審查委員會審閱與簽核的受控交付物。文件記錄解決方案是什麼，而非備忘錄、顧問簡報、選項文件或論文。
文件位置、時間戳記與審查元資料請使用 technical-writing。散文潤飾請使用 humanizer。此技能管轄結構、語氣與輸出格式，並在衝突時覆蓋一般散文預設值。
使用時機
適用於：解決方案設計文件、基礎設施與應用設計、高階與細部設計、遷移與補救設計、參考架構、架構決策記錄、設計變更記錄。
不適用於：商業論證、專案計畫、狀態報告，或提交給高階主管做資金決策的選項文件。解決方案設計會引用這些文件，但不會變成它們。
語氣
這是常被搞錯的部分。設計文件陳述解決方案，而非說服讀者架構師是正確的。
時態與語氣
| 內容 | 形式 | 範例 |
|---|---|---|
| 現狀 | 現在式，陳述事實 | 「現行解決方案使用兩台應用伺服器，分別代管資料庫與應用層級。」 |
| 目標狀態與設計陳述 | 未來式，宣告式 | 「應用伺服器將被兩台位於共享平台上的虛擬機器取代。」 |
| 限制 | 「解決方案須符合…」 | 「解決方案須符合標準作業環境 3.0。」 |
| 假設 | 「假設…」 | 「假設每個應用程式的儲存配置不會改變。」 |
| 排除事項 | 直接否定句 | 「排除修改上游或下游應用基礎設施或服務。」 |
| 未知事項 | 直接陳述，從不軟化 | 「資料庫層級與應用層級之間的端到端網路設計為未知。」 |
| 建議 | 命名選項，然後說明理由 | 「選項三被認為是最佳做法，儘管它會產生額外的前期資本支出。原因是它能降低在共享平台上部署應用程式的風險。」 |
必要特性
- 第三人稱。架構師不應出現。不得使用「我」、「我們」、「我們的建議」。
- 具體且字面。說出伺服器名稱、連接埠、版本、大小、標準、料號。模糊是一種缺陷。
- 每個句子一個陳述。複合推理應屬於登記冊的理由欄。
- 每個數字、名稱與版本皆可追溯至引用的來源，或標記為未確認。
- 表格承載結構化內容。散文只承載表格無法承載的內容。
禁止的結構
這些會使文件讀起來像分析而非規格。以下結構不得出現。
| 禁止的結構 | 原因 | 替換方式 |
|---|---|---|
| 「有兩個選項：」作為散文開頭 | 選項屬於替代方案章節 | 編號的替代方案章節 |
| 「問題是…」、「所以問題變成…」 | 修辭性框架 | 直接陳述 |
| 「這很重要是因為…」、「值得注意的是…」、「重要的是…」 | 告訴讀者該怎麼想 | 刪除。陳述事實。 |
| 「以下兩點。 | 宣告式轉折 | 刪除。讓段落自然存在。 |
| 「這是最/最重要/最清楚的…」 | 編輯性強調 | 表格中的排序欄 |
| 清單內的粗體小標題 | 格式取代結構 | 編號的小章節或表格 |
| 修辭性問題 | 非設計聲明 | 假設、風險或待辦事項 |
| 「可以說」、「清楚地」、「顯然地」、「當然」 | 閃爍其詞或虛張聲勢 | 刪除 |
| 「杠杆」、「無縫」、「穩健」、「全面」、「解鎖」、「賦能」 | 廠商語言 | 簡單動詞或名詞 |
| 第一人稱，單數或複數 | 不屬於此註冊格式 | 第三人稱 |
| 作者散文中使用 em dash 或 en dash | 內部風格規範 | 逗號、冒號、句號或改寫 |
破折號規則僅適用於散文。表格與圖形標題使用內部格式 Table 7 – SOE Non-Compliant Components，使用 en dash，並予以保留。
慣例
澳洲英語。控制表格中日期格式為 DD-MM-YYYY，散文中為「2010 年 3 月 30 日」。貨幣需載明稅基：「$236,324（不含 GST）」。單位需明確：GB、vCPU、Mbps、TCP port。
結構
章節須編號，最多嵌套四層，附錄以字母標示。不適用的章節應保留，並填入「不適用於此解決方案」，而非刪除，以便審查者知道該章節已被考慮。
標準結構、參考架構變體以及前文表格請參閱 references/document-structure.md。除非組織有自己強制的範本，在這種情況下應對應至該範本，並保留此技能的語氣與輸出規則。
嚴格的輸出規則
非風格偏好。違反這些規則的文件將不予審查退回。
- 每個表格都必須編號並在下方加上標題：
Table 7 – SOE Non-Compliant Components。編號需貫穿整個文件。 - 每個圖形都必須編號並在下方加上標題：
Figure 2 – End to End Infrastructure Design。每個圖形都必須有相鄰的文字說明，傳達相同資訊，因為審閱者會閱讀列印版和縮小版。 - 每個表格和圖形都必須在正文中被引用，然後才出現。未被引用的內容將被刪除。
- 不得有孤立的標題。標題後必須有內容，或「不適用於此解決方案」，不得僅有另一個標題。
- 登記冊使用下列固定欄位。不得為每個文件自創欄位。
- 每個事實性主張都必須引用第 2 節的參考文件，或標記為未確認並提出為待辦事項。沒有第三種情況。
- 未知事項必須陳述。若屬實，「備份排程未知」是必要的句子。編造看似合理的排程是一種缺陷。
- 替代方案章節必須包含至少兩個真正的替代方案，加上一個不作為基線，根據明確的標準進行評估，並提出結論，說明選擇的選項及理由。
- 待辦事項必須有負責人和截止日期。沒有負責人的待辦事項只是個願望。
- 版本歷史記錄應附加在後，不得重寫。
登記冊
假設。 寫為「假設…」。
| 參考編號 | 假設 | 若失效的風險 | 驗證方式 | 審查觸發條件 | 負責人 |
|---|
限制。 類型為：IT環境、標準、商業、法規、計畫、技術。
| 參考編號 | 限制 | 類型 | 來源 | 設計影響 |
|---|
依賴關係。
| 參考編號 | 依賴關係 | 方向 | 相關方 | 所需時間 | 延遲後果 |
|---|
介面。
| 參考編號 | 介面 | 來源 | 目標 | 方向 | 模式 | 觸發條件 | 頻率 | 承載內容 | 負責人 | 廠商 | 遷移動作 |
|---|
設計決策。 可逆性為下列之一：可逆、逆轉成本高昂、不可逆。每次均需記錄。
| 參考編號 | 決策 | 考慮過的選項 | 選擇 | 理由 | 後果 | 可逆性 | 狀態 | 負責人 |
|---|
風險。
| 參考編號 | 風險 | 可能性 | 後果 | 固有等級 | 控制措施 | 殘餘等級 | 負責人 |
|---|
非功能性需求。 類別：可用性、效能、容量、可擴展性、可復原性、安全性、可維護性、可觀察性、可攜性、合規性。
| NFR ID | 類別 | 需求 | 目標 | 來源 | 驗證方式 |
|---|
方法
- 建立業務驅動因素與需求來源。無法追溯需求的設計不予啟動。
- 根據證據記錄現狀：具名的庫存清單、擷取資料和配置，而非回憶。
- 在設計前陳述限制與假設。它們界定了選項空間。
- 根據聲明的標準評估替代方案，包括不作為基線。
- 選擇並記錄決策及其權衡與可逆性。
- 將目標狀態詳細說明到建置團隊可以在無需詢問架構師的情況下實作的程度。
- 定義過渡，包括共存、回退與除役。
- 定義非功能性目標及其驗證方式。
- 定義營運整備度與支援移交。
權衡紀律
每個決策都必須說明所放棄的內容。「選擇選項三是因為它最好」不是理由。「選擇選項三是因為它移除了共享平台依賴性，代價是增加四台實體伺服器的資本成本」才是理由。
可逆的決策優於最佳的決策。如果決策是不可逆的，請說明，並陳述需要滿足什麼條件才能重新審視它。
抽象層次
應用程式與整合視圖的 C4 層次：上下文、容器、元件、程式碼。基礎設施的邏輯與實體層次視圖：展示層、網頁層、應用層、資料庫層、儲存層、網路層。不得在一個圖形中混合層次。
標準
引用這些標準，而非重新發明其詞彙。
| 標準 | 用途 |
|---|---|
| ISO/IEC/IEEE 42010 | 架構描述、觀點、利害關係人關注點 |
| TOGAF ADM | 階段結構、架構定義、差距分析、過渡架構 |
| ArchiMate | 企業層級關係的表示法 |
| C4 模型 | 軟體與整合圖層次 |
| arc42 | 軟體密集型設計的輕量級結構 |
| ADR，Nygard 格式 | 個別決策，當完整設計文件不適用時 |
| ISO/IEC 27001、Essential Eight、NIST CSF | 安全控制框架與合規章節 |
| AWS、Azure 與 Google Well-Architected Framework | 營運卓越、安全性、可靠性、效能、成本的支柱結構 |
| ITIL | 服務轉換、營運整備度、支援模型的詞彙 |
證據處理
- 每個來源都必須出現在參考文件章節中，並附帶版本、日期、作者和位置。
- 工作圖、白板與腦力激盪產物不是來源。將其提升為受控參考文件，或予以排除。
- 同儕或廠商的經驗應如實標示，絕不能呈現為關於被設計組織的事實。
- 當兩個來源衝突時，記錄兩者，將衝突提出為待辦事項，不得默默偏好任何一方。
- 口頭建議應記錄人員、角色與日期，並標記為需書面確認。
品質閘門
在發布任何版本前，確認每一行。
- [] 文件目的說明文件的定義，用一句話。
- [] 讀者表列出每個審查方以及他們使用文件的目的。
- [] 所有參考文件都帶有版本、日期、作者和位置。
- [] 至少評估兩個替代方案加上一個基線，並提出結論，說明選擇的選項及理由。
- [] 範圍與特定排除事項同時存在且彼此一致。
- [] 限制、假設與依賴關係使用上述的登記冊格式。
- [] 每個假設都有負責人與審查觸發條件。
- [] 現狀引用庫存清單或擷取資料，而非回憶。
- [] 目標狀態詳細說明到建置層級。
- [] 過渡涵蓋共存、回退與除役。
- [] 非功能性需求有目標與驗證方式。
- [] 每個表格與圖形都已編號、加上標題並從正文中引用。
- [] 每個圖形都有相鄰的文字說明。
- [] 未出現任何禁止的結構。
- [] 作者散文中無 em dash 或 en dash。標題除外。
- [] 每個未確認的事實都是一個待辦事項，並有負責人與日期。
- [] 文件控制附錄完整：職責、審查記錄、核准、分發、版本控制。
- [] 版本歷史記錄附加在後，不得重寫。
工作範例
同一事實的兩種不同註冊格式。
分析註冊格式，被拒絕：
否則會吸收該工作的平台沒有資金，所以問題是沒有它該建什麼。有兩個選項：點對點重建，現在最便宜但會重新產生目標架構旨在消除的耦合；或重建為已記錄的介面契約，現在需投入更多設計成本但可避免第三次重建。
設計註冊格式，被接受：
3.2.1 替代方案一：點對點補救
每個受影響的介面將重建為來源系統與目標系統之間的直接連線。不引入中間媒介。
3.2.2 替代方案二：基於契約的補救
每個受影響的介面將根據已記錄的介面契約重建，該契約指定方向、觸發條件、承載內容、頻率與所有權。該契約將在臨時平台上實作，並且可轉移到整合平台而無需重新定義。
表 4 – 替代方案，優缺點。
3.6 結論
選擇替代方案二。它滿足架構原則 AP-06，即一個應用程式可以被取代而無需重做每個整合，而替代方案一則無法滿足。額外的設計工作量估計為 [X] 天。該決策記錄為 DD-04，且為可逆，直到介面建置開始。
內容相同。第二份是設計文件。