架構師的使命


架構師的工作到底是做啥?用一張十年前 (2012) 我自己在 Plurk 寫下的定義,然後再真實經歷之後,重新回顧這段話。


Plurk Permalink

這篇是我在粉專寫下的 隨筆文,放在 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 隨筆



Comments

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲