什麼是TOGAF解決方案？ - Anatolii

banq發表於2022-03-18

以下是對企業解決方案架構的核心工程階段的精簡回顧：
 

解決方案架構有什麼用？
解決方案架構有許多不同的風味，而且幾乎每家公司都有其混合的責任，這是個術語。
因此，有一個共同的基礎來解釋和分類解決方案架構中所涉及的核心功能和角色是至關重要的。
本文進一步細分的基礎是TOGAF框架，這是一個著名的、成熟的框架，概述了軟體開發和架構標準。
如果你正在閱讀這篇文章，你很可能參與了軟體開發，並且你正在問自己如何成為一個架構師，或者如何為你的團隊找到一個架構師。你甚至可能想偷偷了解一下企業環境中軟體開發的複雜性，或者想獲得另一個認證，而TOGAF就在這個名單上。
  

什麼是解決方案架構？
解決方案架構！=技術架構

Open Group對解決方案架構的定義明顯地強調了業務操作。
對一個離散的、集中的業務操作或活動的描述，以及資訊系統（IS）如何支援該操作。
然而，該組織既不承認 "解決方案架構師 "是一個角色，也沒有將其納入TOGAF的技能框架。
它在資訊系統、技術和業務架構之間劃出了一條細線。

  • 解決方案架構的一個巨大範圍在於對流程、框架和組織結構的定義。
  • 資訊系統架構和技術架構只是隱藏在其傘下的一些支柱。

 

業務架構
業務架構是一個先決條件，它為進一步的設計活動提供了基礎和輸入。
從本質上講，業務架構必須證明技術架構和未來系統是如何與利益相關者的投資回報率相匹配的。
定義架構和組織價值之間聯絡的最常見方式是使用業務場景--技術架構可以實現的流程和應用。
一個好的業務場景必須是：

  • 具體要求--需要做什麼
  • 可衡量的--成功的衡量標準
  • 可操作的--確定解決方案的行動計劃的基礎
  • 現實的--在組織、時間和成本限制的範圍內
  • 有時限的--機會到期時有明確的時間表

因此，有了一些軟體工藝的經驗，你會發現業務架構是敏捷中產品經理、產品所有者和業務分析師的工作。
 
儘管TOGAF並不關心敏捷方法論及其調整，但你可以在最常見的企業採用的敏捷中找到業務架構的參考。
作為參考，你可以檢視一個大型組織的SAFe（Scaled Agile Framework）配置。
軟體架構師可以成為解決方案積壓（Solution Backlog）、解決方案背景（Solution Context）和解決方案意圖（Solution Intent）的一個重要貢獻者。
相比之下，在BAs的支援下，業務擁有者的工作是定義和確認未來技術架構的需求基礎。
  

資訊系統架構（ISA）
業務架構有明確的目標和範圍，而資訊系統架構則嵌入了一套基本的設計和分析活動。
簡而言之，資訊系統架構的主要目標是確保在企業的範圍內，不管是已經建成的還是目前處於設計階段的，都能得到充分利用，並與我們未來要開發的系統保持一致。它適用於資料治理、結構以及與現有應用和能力的整合。
當ISA被忽視時，即使是一個架構良好、看似成功的應用/系統也可能無法適應當前的企業生態系統，因此，它本身就會成為一個失敗的例子。
ISA包括兩個步驟。

  • 資料架構
  • 應用架構

兩者都以業務場景、背景、意圖、差距分析結果和組織的可重用構件為輸入，併產生資料應用架構、藍圖和系統打算實施的目標架構的核心原則。
 

資料架構
在這個階段，設定資料架構工作的界限和架構師的參與程度非常重要。
常見的錯誤是跳到資料庫設計，資料層的邏輯和物理架構。然而，主要的目標是識別和定義與企業相關的資料實體及其關係，特別是關於我們正在設計的資訊系統的範圍。
ISA資料架構不是關於資料庫圖或ACID原則的。
通常情況下，這一步的工作背景是通過業務場景和架構願景來定義的。
一旦收到所有的輸入，資料架構師就必須建立一個基線資料架構。這種架構工件的格式在每個組織中可能有所不同，但它應該包括以下資訊。

  • 業務資料模型（實體、屬性和關係）
  • 邏輯資料模型（從系統的角度對資料的邏輯看法）
  • 資料原則（安全、治理和管理模式）

一旦定義了基線，就會產生另一個基本檔案--目標資料架構。
目標檔案將包括資料模型和原則的定義以及其他支援性檔案，投射到系統實現系統目標和業務目標的未來狀態中。
所以，它是一個試圖根據架構和業務資訊來預測未來的嘗試。
 

應用架構
在TOGAF中，應用架構的目的是審查與企業相關的能力和應用。
所以，這一步的工作將包括分析當前的應用、它們的互動以及它們對業務功能的影響。
在這個階段審查的應用並不被定義為一個計算機系統，而是企業中的一個邏輯能力組，它管理著資料架構中的資料物件，並支援業務架構中的業務功能。
注意：ISA應用架構不是關於設計模式、服務或API的。

除了我們在每個設計和分析階段收到的工件之外，還有一些專門針對應用架構的輸入。

  • 應用原則--應用架構的基本規則的集合，它們的理由和影響由架構負責人和架構委員會制定。
  • 架構願景--詳細的目標、行動者和他們的角色、架構約束以及與目標架構相匹配的要求。

工作和產出將類似於資料架構，不同的是我們所分析的物件--應用程式。
  • 基線應用架構
  • 目標應用架構
  • 解決關鍵利益相關者關注的觀點
  • 通用應用服務互操作性觀點

需要注意的是，所有的設計工作都應該與應用背後使用的技術無關。
TOGAF良好應用架構的核心原則之一是技術獨立和易於使用。
 

技術解決方案架構
祝賀你，我們終於到達了軟體工程師所頌揚的解決方案架構的部分。
前面的步驟主要屬於盡職調查，而技術解決方案架構通過使用面向服務的描述對構件和系統進行建模，定義了未來應用的具體特徵。
這一階段的目標是將需求、約束、分析、原則和指導方針轉化為未來實施工作的基礎。
在這個階段，技術架構師的一個關鍵交付物將是一個目標技術架構--一個使用架構積木（ABB）的廣泛的架構模型，提供對特定應用和全球企業功能的洞察力。
讓我們簡單回顧一下目標技術架構中必須要解決的基本部分：

  • 原則--將ISA原則和約束實現為適用於實施工作的規則
  • 參考模型和模式--構件的定義、功能的模型、服務和企業範圍的框架
  • 觀點--整體架構的表述，展示如何解決利益相關者的關切，即服務互操作性觀點、成本觀點、處理觀點等。
  • 架構定義--對相對抽象的服務地圖和詳細的特定實施構件的全面表示
  • 過渡架構--必須定義的中間架構，以展示在需要多個步驟時遷移到目標架構的複雜性
  • 架構決策記錄--在系統開發的每個階段做出的架構決策的登錄檔

 

決策、承諾、重複
最後，我們審查的階段中沒有一個是一次性的行動。架構師和開發團隊應該經常回到以前的結果，根據不斷變化的業務和生態系統的要求來審查和重新評估決定。
在不斷髮展的技術、不斷變化的趨勢和客戶需求的背景下--目標系統架構和系統架構作為一個整體總是一個移動的目標。難怪近年來，新興架構與敏捷方法論攜手並進，越來越受歡迎。
 

C4模型
C4模型是一個參考模型和框架的完美例子，它允許在技術架構中擁有必要的細節水平。
C4是一種用於技術架構建模的圖形符號技術，吸收了UML和ERD模型的最佳部分。
它將架構分解為不同層次的觀點。

  • 第一層：上下文背景圖--顯示與外部系統和使用者的關係
  • 第二層：容器圖--將系統分解為一組可作為單獨元件部署的架構構件，以解決業務問題
  • 第三層：元件圖--使用建築連續體中定義的原則和技術實現容器功能的技術和應用程式碼（不能單獨部署）。
  • 第四層：程式碼圖--介面和實現細節等。

如果你還沒有，請檢視這個框架。它是一個簡單易行的工具，可以簡化你組織中的溝通。工程師、業務分析員、建築師和其他人都可以用它來分享知識和做出決定。
更多C4模型介紹
 
 

構建塊
構建塊building block是一個功能包，它的定義是為了實現組織中的業務需求，並有公佈的介面來訪問這些功能。
TOGAF的技術架構是關於架構構建塊（ABBs：Architecture Building Blocks）。
因此，架構是一組構件、規範和互操作性的對映，以實現業務需求。
重要的是要理解，定義和維護ABBs登錄檔的工作似乎是多餘的，需要在一個大型組織中支援和接受可重複使用。
在架構工作從願景到業務、IS以及最終的技術架構階段（A到D，看ADM）的過程中，ABBs被逐漸定義和指定。
每一步，ABB都會有更具體的形狀和特徵，並被確定為延續、消除、定義為一種新的能力、開發或採購。

相關文章