架構師的使命
架構師的工作到底是做啥？用一張十年前 (2012) 我自己在 Plurk 寫下的定義，然後再真實經歷之後，重新回顧這段話。
這篇是我在粉專寫下的 隨筆文，放在 blog 做個紀錄。
定義
截圖是我 2012 年在 噗浪 (Plurk, 還有人在用？) 上自己對於 架構師 寫下的定義:
讓所有團隊的
關係人，對於產品有一致性的整體觀
我的部落格文章裡，有很高的比例都在整理溝通表達的想法，像是：
除了這些軟性的，在 “一致性問題與共識演算法“ 這篇整理，把 一致性問題、共識演算法 兩個 分散式系統的核心議題，直接用到組織溝通。計算機科學裡的 通訊協議 概念，應用在人與人溝通。
使命
最近跟朋友聊到架構師工作內容是做啥？研究最新的最炫砲的技術？還是去扛別人留下來的坑、把坑變黃金？研究下一代的技術？ …. 聽起來好像是，也好像都不是。
最近剛好有機會，有在學學生來公司參訪，我負責介紹架構師在做啥，準備的時候我直覺的就用了十年前的這段話當開場，定義了架構師的使命。
這句話其實換成其他角色，也可以？其實不然，換成總監、經理層級，絕對不行；VP 以上層級，也不對，大部分的 VP、總監、經裡 還是 Functional Base 的角色，也就是具備本位主義。所以只有架構師、產品長、PO，或者 C-Level 這種全局觀的角色，才是做這種工作。
普遍人對於架構師還是以技術角度出發，例如就是在導 MicroServices、DDD、Clean Code / Architect、搞 K8s、弄 Cloud、弄 vSphere、Service Mesh、資訊安全 … 我也的確在當場回答了一些概念，我的 Blog 也有一半以上都在寫技術類的東西。
各種 XXX Architect (updated: 2023/05/31)
我的 個人介紹 有寫到這些 XXX Architect，突然想到 紀錄 這件事。。。
這些名稱背後我有自己的解釋，記錄這些定義，以及背後的想法。好友 Kim 也有類似的 紀錄，也可以參考看看～～
Software Architect
有些公司稱 Application Architect, 本質是處理 Code Level 的各種 資料結構 與 資料流. System Design 談的 Design Patterns, DI, AoP, SOLID, Algorithm, Protocol, Framework, API, UI, … 等要處理的. 也就是一個應用程式裡面所有的東西, 與他對外的關係.
最近我用 Process 概念來闡述這種概念, App 跑起來在作業系統裡就是一條 Process …. Process 以外的就是 Infra, 有怨念 … 但真實世界就是這樣運作的 QQ
Infra Architect
處理 Application 以外的東西. 跳出 Process 以外的事情, 都是 Infra 的事 (也很符合事實) …
K8s 核心概念的 Pod 表述的是一個應用程式 (Process / container) 與其他 Process (Container) 之間的關係. 實務上, 應用程式 (Process) 之外的 Processes (ex: DB, storage, networking …), 真的都是 Infra Team 在管的.
大概就是你媽在家裡做的是，老爸只負責賺錢 …
Tech Architect
做 技術決策 與 技術管理.
舉凡各種 Design Principle / Methodology / Guideline, 技術選擇, Evaluation / Tradeoff / Tuning / Optimizition ….
該用 REST or GraphQL? 該用 NATS or Kafka? 該用 RDB or NoSQL or NewSQL? 該用 Block or Object Storage?
所以 Tech Architect 會往下繼續展開各種專業, 像是 DB / Data / Network / Security / Storage / Test … 等更深度領域的.
這也是大多數人認為 architect 的主要工作.
Solution Architect
解決問題的那個人, 需要懂上面一堆東西 …. 技能很硬、身段卻要很軟的角色 (到處跪🧎)。
一些人會以為導入 OOXX 技術就是 “Solution”, 所以常常系統裡就多了很多不知道為啥存在的東西 …. Solution Architect 的重點是要解決問題, 這才是最難的.
通常問我, 你都用什麼 Solution ? 通常我都會反問:
你說的問題是什麼？怎樣才叫解決？
通常被我這樣反問的人, 有一半會當機 ….
問題背後的問題：Problem Behind Question
Enterprice Architect
跟業務 ($$) 有關的, 上面沒列到的, 簡稱 Others …. (有點像 PMO .. XDD
詳細可以參閱 Wikipedia 的整理.
武、俠與俠之大者
我很喜歡讀金庸武俠，其中最喜歡討論的就是 武俠，喜歡郭靖的 俠之大者，為國為民。江湖上喜歡討論誰武功高、誰的武功有多厲害、喜歡討論之最、最高、爭奪武功秘笈 ….. (這年代的武功秘笈都在 ACM 論文 …. 只要有心，人人都可以練成葵花寶典、超級賽雅人)。
而我個人，更多喜歡討論的是俠者為何？直接引用金庸自己在小說序中提到的概念：
『武功』只是用來解決問題的手段，特別是在過去朝代律法規範不健全之下，人們只能用『武功』來取得正義，或者利益。『武俠』小說要討論的核心，應該是人跟人之間的俠與義，更近一步的是人性。只是在說故事的時候，需要透過武功來陳述過程衝突，解決的手段，甚至誇大武功的力量（所以乾坤大挪移、降龍十八掌），藉此吸引讀者目光。
同樣的概念，也可以套用在科幻小說上。藉由幻想的科學 (科幻)，探討『哲學』議題，包含生命、烏托邦 … 等。
回到架構師的職責，架構師要凝聚的是 關係人 (Stakeholder) 的 共識 (Consensus) ，讓團隊對於展品有整體 一致性 (Consistency) 的 整體觀。
Consensus vs Consistency 的差異，參閱 “一致性問題與共識演算法“ 有實際舉例說明其差異。
延伸閱讀
站內文章
Facebook 隨筆
- 2022/10/07: 架構師的使命
- 2023/05/31: 各種 XXX Architect
- 2022/11/10: Kim Kao 的架構師解釋
Comments
About
著作
演講
AWS Certifications
