TOGAF的架構分區

Mar 2, 2023

企業架構的開發與維護通常都是複雜的。而TOGAF的架構分區(Architecture Partitioning)則可以讓企業架構師簡化這一類的作業。本文將介紹:

簡介

架構分區的主要目的是通過簡化企業架構的開發和維護來管理其複雜性。對架構進行分區是為了：

管理複雜性:在單一架構中解決所有問題可能過於複雜
管理衝突:不同的組織單位的架構相互衝突
管理同時開發的作業:不同的團隊需要同時處理架構的不同部分，分區方式讓特定的企業架構師團隊擁有和開發架構的特定部分
管理可重複使用: 有效的架構重複使用需要模塊化的架構區段(modular architecture segments)，這些區段可以被採用並整合到更廣泛的架構和解決方案中

以下分類標準可用於支援解決方案分區：

Subject Matter(Breath):解決方案應該組織成一個群組以支援運營管理和控制。
根據subject matter 的解決方案分區的範例包括應用程式、部門、產品、服務、服務中心、站點等。按subject matter分解解決方案通常是構建解決方案和代表它們的架構的基本技術。
Time:解決方案生命週期通常圍繞時間線進行組織，這允許針對類似時間區段內發生的其他業務活動來管理解決方案開發、導入、運營和退役的影響
Maturity/Volatility:解決方案的成熟度和波動性通常會影響解決方案生命週期所需的執行速度

此外，波動性和成熟度將決定投資重點。存在於高度易變環境中的解決方案可能更適合快速、敏捷的開發技術。

以下分類標準則用於支援架構分區：

通常不太詳細的架構會引起利害關係人的興趣。隨著架構細節的增加，它們與實施和操作人員的相關性也將增加。

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

使用上面的分類標準，可以將架構分組在一個區段中。

準備階段的主要目標是為企業建立架構能力。實際上，這個活動將需要建立許多具有"明確邊界"和"所有權"的架構分區。

一般而言，在企業內執行架構活動的每個團隊都將擁有一個或多個架構分區，並執行 ADM 來"定義、治理和實現"他們的架構。如果期望多個團隊在一個架構上作業，這可能會成為問題，因為每個團隊的確切職責就會很難認定。出於這個原因，最好對架構進行分區，直到每個架構都只有一個團隊是擁有者。

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

確定企業內部架構的組織結構並確定團隊。為每個團隊建立適當的界限，包括：
— 主題領域
— 詳細的程度
— 時間區間
— 利害關係人
確認每個架構團隊的責任
此步驟將分區邏輯應用於企業架構，以便首先確定每個團隊的範圍，然後在單一團隊的職權範圍內對架構進行分區。完成後，此步驟應該已經對企業的整個範圍進行了分區，並且應該將每個分區架構的責任分配給了一個團隊。 分區應該為每個架構建立一個定義，其中包括：
— 主題領域
— 詳細的程度
— 時間區間
— 利害關係人
通過考慮架構重疊(architectures
overlap)和架構之間的合規性要求來確定架構之間的關係
這個步驟讓治理關係正式化，並顯示架構中的工件預計在其他架構中的哪些位置被重複使用。

一旦準備階段完成，就應該定義執行架構的團隊。 每個團隊都應該有一個定義的範圍，並且應該理解團隊和架構之間的關係。下圖為一個將一個架構分配給一個團隊的範例