企業架構師、解決方案架構師和技術架構師的異同 - Briqi

軟體架構師在 SDLC 中的作用是什麼？
這取決於 SDLC 期間的設計範圍：

• 在應用程式設計中，角色將是應用程式架構師（.NET、JAVA、iOS 或 Android 應用程式架構師），負責在程式設計技術、框架、元件、層和整合介面。
• 負責 SDLC 自動化設計的 DevOps 架構師。
• 負責使用不同方法和技術設計託管環境的平臺架構師（例如，雲上或 on-prim 或混合解決方案上的容器管理系統。
• 基礎架構和網路架構師負責直流拓撲和網路。
• 負責編寫跨技術和/或應用程式的解決方案的解決方案架構師（例如 Azure 解決方案架構師、AWS 解決方案架構師或特定程式解決方案架構師）。
• 企業架構師，他負責在組織範圍內為 SDLC 設計整體架構基礎，描述主要架構檢視（業務、應用程式、資料和技術），有時也被引用以 EA 架構師為 IT 架構師。

​

1. 企業架構
它是關於跨越組織內或多個組織內的跨系統的解決方案型別。
企業架構是指組織級別的整體設計工件，描述健壯和彈性設計，考慮適合業務需求的不同架構檢視，並根據需要靈活應對變化。
企業架構師的角色擴充套件到業務和管理。與高層管理人員合作，瞭解組織的業務目標，並與底層架構委員會合作，定製 EA 解決方案，從業務、資訊和技術原則方面描述組織數字產品和服務的景觀設計。企業架構師負責設計原則的持續發展，作為參考架構的一部分，以指導組織中任何架構師可以處理的任何型別的潛在設計的創作。
在深入瞭解更多細節之前，瞭解 TOGAF 和 Gartner 等其他權威機構對企業架構的標準定義會很有用：

• TOGAF 將企業架構定義為元件的結構、它們的相互關係以及隨著時間的推移管理它們的設計和演變的原則和指南，這些原則和指南描述了組織的最高階別（通常），通常涵蓋所有任務和功能。一個企業通常會跨越多個組織。
• Gartner 將企業架構 (EA) 定義為透過識別和分析變革的執行以實現期望的業務願景和結果，主動和全面地領導企業應對破壞性力量的學科。EA 透過向業務和 IT 領導者提供可用於調整政策和專案的簽名建議來實現價值，以實現利用相關業務中斷的目標業務成果。

• 商業意識和設計
• 組織分析和客觀性
• 富有洞察力和遠見
• 軟技能
• 技術設計能力
• 具有 EA 框架的經驗和知識

2. 解決方案架構
它是一種模糊的架構型別，因為它跨越了SDLC的不同領域，如預售、管理、開發和運營。它意味著為與特定行業、供應商或組織內的特定程式相關的應用程式程式提供端到端解決方案。不知何故，這類架構型別被故意或錯誤地與其他架構型別（EA 和 TA）一起計算。
那麼，為什麼這種型別的架構與其他型別混合在一起呢？讓我解釋。
企業架構師主要是指從方法和實現細節中抽象出來的組織內軟體應用程式的通用技術標準和參考架構的全域性設計。而技術架構師是指如何使用特定系統和特定技術實施解決方案的詳細設計。因此，解決方案架構師在這裡填補了這兩個角色之間的差距，因為該角色具有提供跨越不同技術和不同系統的解決方案的技能。
我們可以在 SDLC 中按供應商的產品或組織程式分組的標題下看到此角色。

​
微軟、亞馬遜、谷歌等供應商正在提供旗艦產品/服務，例如 AWS 雲、Azure 雲等。
而對於像大公司、政府（例如部委）、研發實驗室、新興業務（例如加密和物聯網）或任何其他型別的組織，它們傾向於在特定計劃下在內部管理一組產品（或服務）。例如，一個大組織決定在程式結構下組織產品和服務，而每個程式管理一組應用程式。
解決方案架構師可以在軟體架構中扮演不同且更多的角色，透過組合的技術解決方案來體現業務商業價值，而業務不會停止。
解決方案架構師與企業架構師和技術架構師協同工作，在 SDLC 的不同階段進行所需的設計輸出。
關鍵技能：

• 業務需求分析
• 利益相關者分析
• 具有分散式系統和廣泛的軟體工具和程式設計技術的經驗
• 具有企業整合解決方案的經驗
• 技術領導
• 解決方案建模和文件（以每個利益相關者都能理解的方式）
• 技術實施的解決方案治理
• 軟技能

3. 技術架構
它是一種架構型別，是指基於特定技術對系統進行底層設計，以提供系統子元件及其相互之間和與其他系統互動的詳細技術解決方案。
技術解決方案的複雜性因每個業務案例而異。例如，像 .NET 應用程式這樣管理基本業務場景的簡單資料輸入/輸出的案例，可能不需要技術架構師，因為技術最佳實踐本身的文件足以涵蓋技術解決方案。而對於其他複雜的場景，分散式事務將發生在系統之間，需要一致的事務提交和安全回滾，或者複雜的邏輯將發生在系統內，需要特殊的設計模式，因此這裡需要技術架構師的角色.
這是否意味著企業架構師和解決方案架構師不是有關技術解決方案！？當然，技術架構是根據企業架構師設計的技術策略和解放方案師的技術高階設計來設計詳細的技術實現。
在現實世界中，這個角色可以由熟練的開發人員或解決方案架構師扮演，以防他/她具有技術經驗，並且工作地點強加了架構角色（如初創公司和小型組織）之間的合併。
技術架構師是技術極客，主題專家（SME），具有設計與特定技術領域相關的純技術解決方案的技能

​

• 應用程式程式設計技術，例如 .NET、Java、Python、iOS、Android 等。
• 資料技術，如資料庫、大資料、ML&AI、API等。
• 基礎設施技術，例如網路和虛擬化
• 平臺技術，例如 Terraform、Ansible、Azure DevOps、ArgoCD、Jenkins 等。
• 區塊鏈技術，例如超級賬本結構
• 物聯網技術，例如思科物聯網

​

架構層次
每個架構角色都被視為設計中的一個層，相互結合形成不同利益相關者理解的清晰設計形象，並反映在最終的軟體產品上.
這裡對架構角色採用的分類可以換一種說法來解釋。其中企業架構是識別概念架構風格的層，解決方案架構是識別邏輯架構模式的層，技術架構是識別物理設計模式的層。

​

我們可以想象一個架構解決方案設計的最終影像的說明性示例，如下圖所示，它將企業架構描繪為主要框架（或景觀），技術架構描繪為框架中的點，解決方案架構描繪為線條將點相互連結。

​

角色舉例
讓我們舉一個簡化的例子，放棄像新電信公司這樣的組織中的角色，考慮到在現實世界中，我們可能有不同的情況和業務需求，以對組織有利的方式使用架構師（例如架構團隊結構和組織結構圖中的角色）。
讓我們假設一個理想的架構團隊具有一個企業架構師、三個解決方案架構師和許多技術架構師的結構！（稍後宣告）。他們將共同交付可用於 SDLC 後續步驟的目標設計文件。
此示例描述了企業和解決方案架構的邏輯應用程式檢視的簡化設計。而其他檢視（例如應用程式、資料、拓撲、技術堆疊、整合等）未在此處描述。 每個架構檢視都可以用三種形式來描述（概念、邏輯和物理）。有時將檢視混合在一起（或簡化）以賦予目標利益相關者以意義。
收集、分析和與不同利益相關者討論業務需求後，每個架構師角色將按以下方式工作：

(1)
企業架構師對業務需求和利益相關者進行分析研究，然後處理景觀架構的設計工件，從資訊系統和技術的角度描述產品和服務的核心業務。交付物工件因組織而異，架構框架因架構框架而異，但可以說企業架構師根據原則和不同的架構檢視繪製高階技術策略。該解決方案的重點是強調主要系統、它們的特性、拓撲、它們的通訊方式以及它們的技術。Enterprise Architect 負責整個企業解決方案的治理模型，
下圖描繪了電信組織系統的企業架構的邏輯檢視

​

(2)
Solutions Architect 與企業架構師和技術架構師合作，為企業解決方案（例如自我保健計劃）中的特定領域提供解決方案設計，比在企業架構中具有更多和更深入的技術潛水。
解決方案架構師將為每個架構檢視提供更多詳細資訊。描述層、元件以及它們與外部系統之間的整合。因此，讓我們使用下圖作為描述自助解決方案的邏輯應用程式檢視。

​

該圖描繪：

1. 客戶端渠道和每個渠道的一般規範，例如（網頁、移動應用程式、聊天機器人等）。
2. 與身份和使用者訪問管理器 (IAM)、API 管理器和靜態內容等邊緣元件的介面。通訊協議和認證機制。
3. 與內部系統之間的互動。和環境服務。

​

這裡的最後一個示例是針對MS Azure 災難恢復解決方案架構的

​


(3)
技術架構師比解決方案架構師和企業架構師更清晰。技術架構師正在從原理和理論走向實際和具體的實現，因此在程式碼設計和支援開發人員、系統管理員和運營商的戰場上找到技術架構師是很正常的。手牽手，但仍然戴著設計的帽子。
技術架構師提供的文件型別是低階設計文件，它根據設計模式描述程式碼結構、資料庫低階設計、描述系統之間複雜互動流程的特殊流程圖等。
技術架構師不承擔開發任務，而是透過程式碼模板、POC和技術諮詢支援開發過程. 這與敏捷交付並不矛盾，因為技術架構師負責最終的技術輸出，支援正在執行的開發過程，並監控每個 SDLC 迭代的輸出. [在心態文章中詳細說明]。

​

現實中的角色
首先，在著手構建架構團隊的層次結構和他們的職位之前，我們必須非常瞭解組織業務和組織結構圖。
初創公司、小型企業、中型企業和大型組織都將擁有自己的圖表和架構角色。例如一家初創公司，幾乎都會從一位專家架構師開始。而大公司將擁有更成熟的組織結構圖和標準架構角色。
每個架構師都有 t 型技能，在特定架構領域（垂直領域，例如應用程式架構師）的專家，同時在水平領域（例如其他架構角色）與其他人很好地協作。
架構師正在做一個共同的活動，無論角色如下：

1. 支援業務價值流的解決方案設計。
2. 架構治理以監控設計的執行或根據進度更正設計本身.
3. 根據需要提供技術支援和諮詢。
4. POC 和研發支援解決方案設計並保持敏銳的技術技能。
5. 自我發展（架構師思維和軟技能）

​

架構師承擔不同架構角色的責任是沒有問題的，同時符合真實案例和T型架構技能的事實。問題是將架構師的角色（主要是設計角色）與 SDLC 中的非設計角色混合在一起，或者以某種方式忽略角色。

軟體架構中的其他角色
當將軟體視為一個整合行業時，這將導致我們在軟體架構下包含更多角色，例如使用者體驗 (UX) 設計師和業務/產品分析師。
架構師角色是 SDLC 中管理設計活動的職位或技能。

我們需要 SDLC 中的角色軟體架構師嗎？
每個人都有建造房屋的技能，但有多少人能夠正確建造它而不會變得醜陋或很快被摧毀？此外，我們是要建造小型/簡單的房子、很棒的房子還是摩天大樓？在軟體領域也是如此，如果您正在開發一個小型產品/服務，並且您擁有具有良好設計技能的熟練開發團隊（這已經依賴於現有的架構知識，例如架構模式），那麼您可以在沒有明確的架構師的情況下進行。如果組織擁有多個開發團隊和多個產品/服務，則情況會有所不同，那麼架構師的角色就會出現，以統一設計思維並在設計階段支援 SDLC。此外，在使用旗艦產品時情況會有所不同，您不能沒有架構師。
我更願意將軟體架構作為組織內部或外部的諮詢服務，作為在 SDLC 中分離角色以減少團隊之間的耦合並加速 SDLC 流程的一種方式.