TOGAF 10 Architecture Partitioning：治理分區與架構重用策略

解析 TOGAF 架構分區概念 — — 如何為不同團隊定義邊界、管理治理流程，並讓架構治理更模組化與可管理。

為何要進行架構分區？治理、責任與治理邊界的重要性

分區用於簡化企業架構的開發和管理。也是架構治理的基礎，與架構連續體的層級和組織概念不同。架構被分區是因為：

• 組織單位架構相互衝突
• 不同的團隊需要同時處理架構的不同元素，分區允許特定的架構師團隊擁有和制訂架構的特定元素
• 有效的架構重複使用需要模組化的架構部分，這些部分可以採用並納入更廣泛的架構和解決方案中

提出一個明確的架構分區模型是不切實際的。每個企業都需要採用反映自身營運模式的分區模型。本文討論了通常應用於架構的分類標準，以及如何利用這些標準將企業劃分為一組具有可管理的複雜性和有效治理的架構。

分區標準解析：主題、時間、成熟度與架構深度的作用

由於上一節所述的原因，將企業連續體劃分並組織成一組相關的解決方案和架構是價值的，因為：

1. 可管理每個單獨架構或解決方案的複雜性
2. 定義分組
3. 定義層次結構與導航結構
4. 每個分組都有適當的流程、角色和職責

下面說明如何使用適當的分類標準來支援解決方案的劃分：

特徵: 主題(深度)

用於支援"解決方案分區"的用法: 解決方案自然地組織成一組以支援營運管理和控制。根據主題的解決方案分區範例包括應用程式、部門、處、產品、服務、服務中心、分公司等。按主題分解解決方案通常是建立解決方案及其代表架構的基本技術。

特徵: 時間

用於支援”解決方案分區”的用法: 解決方案生命週期通常圍繞時間軸進行組織，這使得解決方案的開發、引入、運行和除役能夠根據類似時間區間內發生的其他業務活動進行管理。

特徵: 成熟度/波動性

用於支援”解決方案分區”的用法: 解決方案的成熟度和波動性通常會影響解決方案生命週期所需的執行速度。此外，波動性和成熟度將決定投資重點。高度不穩定的環境中的解決方案可能更適合快速、敏捷的開發技術。

以下是如何使用每個分類準則來支援架構的分區：

特徵: 深度

用於支援”架構分區”的用法: 架構中的細節層級與對該架構有利益關係的利害關係人群體密切相關。 通常，不太詳細的架構會引起高階主管利害關係人的興趣。隨著架構變得越來越詳細，它們與實施和第一線人員的相關性也會增加。

從實際角度來說，架構學科用於支援多種用於不同目的的不同類型的架構。上面描述的分類標準可以以不同的方式使用來支持每個目標的實現。

以下特徵通常不用於劃分架構面貌：

• 用來描述架構面貌的架構通常不是抽象的
• 解決方案的波動性通常會阻礙對遙遠未來的架構進行定義；隨著組織不斷變化並適應新情況，波動性也會隨著時間的推移降低歷史架構的準確性

使用上述標準，可以將架構分組到各個分區。

ADM 初始階段中的分區活動：如何建立團隊與治理邊界

初始階段的主要目標是建立企業的架構能力。從實際角度來看，這項活動將需要建立多個架構分區，提供明確的邊界、治理和所有權。

一般來說，企業內進行架構活動的每個團隊都會擁有一個或多個架構分區，並執行 ADM 來"定義、管理和實現"他們的架構。

如果預計有多個團隊在單一架構上作業，這可能會成為問題，因為很難確定每個團隊的確切職責。因此，最好對架構進行分區，直到每個架構都有一個擁有團隊。

最後，值得考慮的是企業常備能力與為支持特定變革措施而動員的臨時團隊之間的差異。雖然可以精確定義企業內常設團隊的職責，但預測和指定（可能未知的）臨時架構團隊的職責則更加困難。對於這些臨時團隊，每個團隊都應該受到常設架構團隊的管理，並且在這些團隊的 ADM 週期內應該有一個流程來建立適當的架構分區。

初步階段支援架構分區的步驟如下：

• 確定企業內部架構的組織結構：應該確定將建立架構的各個常設團隊。 對於每個團隊，應該建立適當的界限，包括： — 適用於團隊的治理單位 — 團隊成員 — 團隊報告線
• 確定每個常設架構團隊的職責：對於每個架構團隊，應該明確職責。 此步驟將分區邏輯應用於企業架構，以便先確定每個團隊的範圍，其次在單一團隊的職責範圍內對架構進行分割。一旦完成，這個步驟就應該對整個企業範圍進行劃分，並將每個分區架構的​​責任分配給一個團隊。分區應該建立每個架構的定義，包括： — 涵蓋的主題領域 — 團隊工作細節的程度 — 需要涵蓋的時間區間 — 利害關係人
• 確定架構之間的關係：一旦建立了一組分區架構，就應該制定架構之間的關係。此步驟允許將治理關係形式化，並顯示一個架構中的工件有望在其他架構中重複使用的位置。需要考慮的面向包括： — 不同的架構在哪些地方重疊/契合/向下？ — 架構之間的合規性要求是什麼？

一旦初步階段完成，就應該理解進行架構作業的團隊。每個團隊都應該有一個明確的範圍，並且應該了解團隊和架構之間的關係。下圖說明了團隊依架構範圍的分配。

取自Open Group

架構間如何互動與重用？治理流程與一致性管理方法

建立分區架構可能會產生碎片化、脫節的架構集合，而無法整合成一個整體。

對於大型複雜企業來說，聯合架構（獨立開發、維護和管理的架構，隨後整合到整合框架內）是典型的。聯合架構通常用於政府和企業集團，其中獨立的組織單元需要獨立的架構。該框架指定了互通性、遷移和一致性的原則。這使得特定業務部門可以將架構作為獨立的架構專案進行開發和管理。

為了減緩這種風險，應該定義內容整合的標準，並且架構治理應該將內容整合作為架構合規性的條件。內容框架，例如 TOGAF 內容框架，可用於指定內容整合標準的主題的標準建構區塊和工件。

例如，可以為企業商定一個標準的業務流程目錄。後續架構可以透過使用相同的流程清單並將架構的其他面向與這些標準流程交叉引用來簡化整合。可以從多個維度來解決整合問題：

• 跨架構領域的整合提供了某一時間點企業某個部分狀態的跨領域視圖
• 跨組織業務範圍的整合提供了跨部門的企業視圖
• 架構願景提供了架構定義的綜合摘要，而架構定義則提供了過渡架構的綜合摘要

下圖呈現如何使用多種技術來聚合架構內容。