導讀：
“ 以前大家對架構師有個樸素的了解：搭建技術架構、解決疑難技術問題、優化系統提供高并發高可用場景支撐。
但随着spring體系的不斷成熟，以前需要架構師搭建的架構大部分由spring體系提供了成熟的一套架構标準，普通技術選型也趨向統一；在新技術領域如雲、大資料、區塊鍊等湧現出一批架構師；随着數字化轉型的浪潮，企業也繳納了足夠的“智商稅”，不再相信咨詢公司的“忽悠”，而更加重視企業EA架構師。
這時候我們如何對架構師進行分類，就成了一個公說公有理婆說婆有理的、各自領域自說自話的混亂局面。
為正本溯源，我在寫此文章過程中翻閱了ISO國際标準、Togaf标準，以微軟架構師分類标準為基礎，聊一聊架構師的分類及未來的演進，不足之處敬請各位同仁指正。
本文共分為四個章節：
第一章節講ISO标準、第二章節講Togaf了解、第三章節講微軟架構師分類、第四章節講演進。想一步到位的朋友請直接跳到第三、四章節。
”
目錄
01 ISO/IEC/IEEE42010.架構标準
02 Togaf對企業架構的解釋
03 “微軟”架構師分類
04 綜合了解
01
—
ISO/IEC/IEEE42010.架構标準
本文對軟體體系架構的描述方法的研究基于ISO/IEC/IEEE42010. ISO/IEC/IEEE 42010 于2011 年準許使用并釋出，該标準是繼 2006 年 ISO 快速采用 IEEE 标準後，ISO 和 IEEE 聯合制定的修訂 IEEE Std 1471:2000 的産物。
其中，“系統（System）”指其結構受到關注的實體，在軟體開發過程中，可以認為是“軟體密集型系統”：任何軟體對其設計、構造、部署和演變有重要影響的系統，包括單個應用程式、傳統意義上的系統、子系統、系統的系統、産品線、産品系列、整個企業和其他利益的集合。
“利益相關者（Stakeholder）”是指在系統中擁有利益的各方。利益相關者的利益表現為“系統關注點”（System Concern）。利益相關者賦予系統各種目的（Purpose），目的是系統關注點的一種。
“環境（Environment）”決定了系統在其整個生命周期中受到的全部影響，包括與環境的互相作用。一個系統處在一個環境中，一個環境可以包含多個系統。
“架構（Architecture）”構成了系統與其環境相關的基本内容，可能涉及到如下幾點：系統的構成要素或元素；系統要素如何安排或互相關聯；系統的組織或設計原則；系統在其生命周期中的演變原則。
“架構描述（Architecture Description）”用于表達有關系統架構的内容。下面對架構描述的方法進行詳盡的闡述與分析。
架構描述是系統和軟體體系架構的工作成果。下圖是在應用此國際标準編制架構描述時，用于描述一個“利益系統（System of Interest，或簡稱系統）”的一個架構的概念模型。
架構視圖由一個或多個“架構模型（Architecture Model）”組成。架構模型使用規定好的模組化規範，這些規範由管理該模型的模型種類指定。在一個架構描述中，一個架構模型可以是一個或以上架構視圖的一部分。
每個架構模型應包括：
（1）組織和（或）項目指定的版本辨別。
（2）所管理模型的種類辨別。
（3）架構描述應記錄其架構模型和架構視圖中任何已知的不一緻之處。
架構描述應包括對其架構模型和架構視圖的一緻性分析。
一個系統的利益相關者對系統和與其有關的問題進行關注。
一個關注點可能由一個或多個利益相關者持有。
在整個生命周期中，對系統的需求和要求以及實施和運作的考慮等都可能成為關注點。
關注點可以通過多種形式表現出來，例如與一個或多個利益相關者的需求、目标、期望、責任、要求、設計限制、假設、依賴性、品質屬性、架構決策、風險或其他與系統有關的問題有關。
架構描述應确定系統利益相關者，這些利益相關者的關切被認為對相關系統的架構至關重要。架構描述中應考慮并在适用時确定以下利益相關者：
系統的使用者；
系統的操作者；
系統的擷取者；
系統的所有者；
系統的供應商；
系統的開發者；
系統的建設者；
系統的維護者。
體系結構說明應确定被認為對有關系統的體系結構至關重要的關注點。架構描述中應考慮并在适用的情況下确定以下關注點：
（1）系統的目的。
（2）體系結構對實作系統目的的适用性。
（3）建構和部署系統的可行性。
（4）系統在整個生命周期内對利益相關者的潛在風險和影響。
（5）系統的可維護性和可演變性。
通讀下來發現，此國際标準定義的架構标準屬于企業EA架構，對架構師的了解也是企業EA架構師。感興趣的朋友可以通讀中文翻譯版，下載下傳位址：關注EA之家公衆号并回複：ISO
02
—
Togaf對企業架構的解釋
Togaf對“企業架構”的了解：
在“企業架構”上下文中，“企業”這一術語不僅可用來表示整個企業（包含所有資訊和技術服務、流程和基礎設施），而且可以表示企業内的一個特定領域。在這兩個情形中，架構可以跨越多個系統和企業内的多個職能群組。“企業”術語本身的演化性經常導緻困惑。當今的擴充企業常常包含夥伴、供應商和客戶。如果目标是內建擴充型的企業，那麼企業就該包含夥伴、供應商和客戶，以及内部的業務機關。業務營運模型的概念對決定組織内企業架構的範圍和本質十分有用。大型公司和政府部門可以由多個企業組成，并且可以開發及維護一些獨立的企業架構來應對每一個企業的營運。但是，這些企業的資訊系統經常存在許多共同之處，是以，使用一個共同的架構架構通常會有大的潛在收獲。例如，一個共同的架構能提供架構儲藏庫作為開發基礎，提供可重用模型、設計以及基線資料。
企業架構可以分為兩大部分：業務架構和IT架構，大部分企業架構方法都是從IT架構發展而來的。
（1）業務架構：是把企業的業務戰略轉化為日常運作的管道，業務戰略決定業務架構，它包括業務的營運模式、流程體系、組織結構、地域分布、業務流程設計等内容。
（2）IT架構：指導IT投資和設計決策的IT架構，是建立企業資訊系統的綜合藍圖，包括資料架構、應用架構和技術架構三部分。
在業務戰略方面，可使用Togaf及其架構開發方法論來定義企業願景/使命，目标/目的/驅動力，組織架構，職能及角色。
在IT戰略方面，Togaf及ADM較長的描述了如何定義業務架構，資料架構，應用架構，和技術架構，是IT戰略規劃的最佳實踐指引。
企業架構是承接企業業務戰略與IT戰略之間的橋梁與标準接口，是企業資訊化規劃的核心。
顯然Togaf定義的架構師與國标ISO/IEC/IEEE42010定義的架構師同樣是企業EA架構師。
03
—
“微軟”架構師分類
網傳“微軟”架構師分類，原因是我一直沒有找到微軟的官方定義出處，我感覺此定義可能“國産化”居多一些，但劃分的仍然合理，不妨礙我們讨論架構師分類問題。
“微軟”架構師分類參考：
- 企業架構師EA(Enterprise Architect)
- 基礎結構架構師IA(Infrastructure Architect)
- 特定技術架構TSA(Technology-Specific Architect)
- 解決方案架構師SA (Solution Architect)。
Togaf架構及ISO/IEC/IEEE 42010國際标準中描述的架構師即是企業EA架構師。負責将企業戰略分解成業務、資料、應用、技術、安全5大架構體系，指明企業資訊化方向。
IA的工作就是提煉和優化技術方面積累和沉澱形成的基礎性的、公共的、可複用的架構群組件，這些都是一個技術型公司傳承下來的最寶貴的财富之一，也是對架構師的最傳統了解。
TSA特定技術架構師，他們主要從事類似安全架構、存儲架構、或新技術等專項技術的架構工作。
SA的工作則專于解決方案的規劃和設計，一般用于售前架構人員與客戶溝通。
軟體架構師：TSA+IA，是程式員最容易突破，也是對架構師最樸素的了解。
系統架構師：SA+TSA，更着力于綜合運用已有的産品和技術，來實作客戶期望的需求。
軟體架構師主要工作：
（1）确認需求
（2）系統分解
（3）技術選型
比如：資料庫ORM架構采用Hibernate還是Mybatis？需要不需要采用MVC或者Spring等輕量級的架構？前端采用Vue還是其他方式？類似的工作，都需要在這個階段提出，并進行評估。
架構師對産品和技術的選型僅僅限于評估，沒有決定權，最終的決定權歸項目經理。架構師提出的技術方案為項目經理提供了重要的參考資訊，項目經理會從項目預算、人力資源、時間進度等實際情況進行權衡，最終進行确認。
（4）制定技術規格說明
架構師與開發者溝通的最重要的形式是技術規格說明書，它可以是UML視圖、Word文檔，Visio檔案等各種表現形式。通過架構師提供的技術規格說明書，保證開發者可以從不同角度去觀察、了解各自承擔的子系統或者子產品。
04
—
綜合了解
Togaf定義的架構師及國标ISO/IEC/IEEE42010定義的架構師與“微軟”架構師分類結合起來看：
SA：最關注戰略及業務滿足度。【售前架構】
EA：戰略與技術之間的橋梁，負責架構規劃與治理，含業務、資料、應用、技術四大基礎架構，確定規劃架構與落地實施的一緻性。【企業架構】
IA：負責技術架構搭建、技術選型等。【技術架構】
TSA：專業領域架構師，如安全等。随着新技術的發展，出現如大資料架構師、區塊鍊架構師等。【技術架構】
随着spring體系的不斷成熟，以前需要架構師搭建的架構大部分由spring體系提供了成熟的一套架構标準，普通技術選型也趨向統一。
在新技術領域如雲、大資料、區塊鍊等湧現出一批架構師。
随着數字化轉型的浪潮，企業也繳納了足夠的“智商稅”，不再相信咨詢公司的“忽悠”，而更加重視企業EA架構師。
對企業應用軟體來講
IA架構師正在與ISA架構師融合，技術架構有且隻有穩定的一套，技術元件有但可供選擇的也就如此，尤其是在上雲之後，如阿裡雲提供了一整套微服務上雲治理體系、技術元件體系、資料中台體系，甚至devops的能力都已經囊括。
SA架構師與EA架構師融合，以我在企業應用的直接感受是：企業的“智商稅”已經交夠了，不在相信傳統咨詢公司或“皮包公司”的“忽悠”，PPT畫的再好落地不成功，使用者體驗總是差的，企業開始重視真正落地的規劃，“表裡如一”的資訊化系統。另外數字化轉型的大趨勢已經來臨，同樣會倒逼企業做好資訊化規劃。
企業架構治理委員會是確定規劃與落地的中間橋梁，其作用簡單歸納了四點：
作用一：確定架構合規性。【面向利益相關者-如甲方客戶】
確定甲方認可架構規劃，達成對未來目标的一緻性。
作用二：確定架構與實際落地的一緻性。【架構規範實際開發】
作用三：在實踐過程中依據原則及政策更新架構體系。【實際開發反哺架構】
實際開發過程中反映出架構不合理的地方，需要不斷治理架構體系，并與利益相關者達成一緻。
作用四：提供架構變更決策支撐。
備注：有小部分架構師定義内容來源網際網路，未能原作者了，特此說明。