# 2021-05-22 技術管理者論壇 Session 2 - 商業與技術的平衡

## 架構思維

軟體架構師的角色定位是什麼？技術最強？每家的期望都不一樣，你需要先理解組織的期望。

- 技術的廣度與深度（一定要技術最強的？）
- 處理人與人之間的關係（軟技能）
- 理解與實現組織對你的期望

架構與設計的分界？

找出分界線，哪些是架構師負責，哪些是工程師負責
上下游的關係，會造成一到無形的牆

-> 更好的是，兩邊一起緊密合作溝通而非單向溝通，畢竟架構設計沒有完美。

通常架構師是團隊內最了解技術的人員之一，但就算再有能力，在架構師這個身份時，你一定會碰到很多你不知道的知識，這時候你要在廣度與深度之間抓好比例。

* 架構師會一直遇到新的問題，不是侷限過往擅長的技術專長

架構師常見問題：你沒有時間去對新技術做大量實作，更常見的是用你過往習慣的技術去處理，但架構師的挑戰不只是技術，甚至還有商業、法律等等。你很難去繼續鑽研深度。

> 架構師與其說是升級，不如說是轉型

以 Jed 經驗來說，可能以技術深度來說，團隊內的工程經理、資深工程師都有自己更強的部分，但架構師要懂得更廣。

### 案例:快取機制設計

要怎麼做得好？你也要理解需求面的因素。不同的賠率邏輯都會決定系統不同的設計，同時使用者體驗也是考量因素之一。而像是賠率甚至不只是系統面，還會牽涉人工處理，有非常多不確定性。

方案一 (近端快取)：效能好、避免單點失敗。但需要有技術能力維護多個系統

方案二(快取叢集）：比較容易管理。但效能一定遜於方案一

比較（當然不只這兩種）：

從以上案例來說，要知道完美的架構不存在，重點是 **有沒有從需求中提取相關的架構特性**

### 架構師的第一法則

* 一切都是取捨
* 有時不只是深度足夠，更需要取決於技術廣度。
* 對領域知識也要足夠，架構設計也不是單靠一個人，還需要接觸利害關係人
* 知道解決方案的差異
* 分析解決方案的好處與壞處
* 依據業務需求做出取捨

當你讓架構師做所有決定（如核心、底層），那他有可能就會成為瓶頸。畢竟哪一天他離開了，團隊就沒有人看得懂這套「祖產」aka 技術債

應該是，當架構師決定好架構跟框架，其他讓工程師團隊去負責開發，而架構師頂多在業務相關的程式著手。這就是架構師兼顧技術深度與廣度的方法。

## 需求結構化


### 關鍵需求決定架構

需求對架構的影響：
* 功能性需求(Functional Requirements)
* 約束性需求 (Constrait)
- EX: 資源約束、商業約束、法規限制
* 品質屬性 - 非功能性需求: (Non-Functional Requirements)
- 隱性需求
- 不太會出現在規格書中
- 可能要有相關資歷的工程師才有辦法識別出

底下以電商的分析為例，矩陣中不同因素會相互影響：


最後，你會從品質需求提取許多架構所需的特性

### 提取架構特性的目的


## 軟體如何解決複雜問題

> System architecture should reflect the end users' mental model of their world.

技術應該最終**反應使用者的認知**，而非提升技術的複雜

* 軟體的複雜性很多原因
* 業務場景多
* 業務流程多
* 業務規模大
* 要解決的問題太多
* 一環扣一環

沒有共通語言，把業務語言/目標跟開發語言/目標串再一起。當你們沒有共識時，很難進入架構前際。

最後做決定的還是以「商業」為主！！

* 邊界
* 商業問題邊界
* 人員溝通問題邊界
* 技術邊界

> 當你理解商業時，可以幫你驅動技術變化，而當你的技術進步，有時也會促進商業進化

比如雲端時代，Adobe 也開始上雲，往訂閱制發展(雲端 Sass)，一開始受到很多質疑，但該產品經理還是力推。沒過多久，訂閱制的表現遠遠超過桌上型軟體，從 60億美 -> 200 億美 (*數字未核實)。

### 實際案例



### Impact Mapping

Goal -> Who -> What -> How

從中找到 User Story
As a 客戶小明，In order to 更方便購物，我想要線上下單

### User Story Mapping


### Specification by Example

Ubiquitous Language: 不只是專有名詞文件化，而是要是一個所有人的共識，並落實到程式碼、測試、文件、溝通之中。

Jed 使用實例化需求，並搭配 Cucumber Gherkin 語法 (Given-When-Then 假設 當 那麼)

放在哪裡都可以，wiki 也可。 **重點是持續重構與進化**

進行的方式與傳統方法不同(相反)，需求方闡述完需求後，開發與測試人員要去寫 spec by example，寫完後給需求方 (EX PO) 確認

Spec by example 成果：

Jed 觀察：很多開發團隊不知道測試團隊要測試什麼，而 QA 也不知道 dev 如何寫程式。 dev 會用自己認知的開發規格去寫程式，這時就很容易出現 bug

### 找出領域概念

比如找出業務活動中名詞與動詞。


目前國外流行的兩種方法：
* Event Storming (https://www.eventstorming.com/)
* Domain Storytelling (https://domainstorytelling.org/)
* 台灣 DST 大神演講：https://youtu.be/mGR0A5Jyolg?t=682

## 定義問題與解決方案


第三方支付可能會發生很多問題(外部問題、網路問題、安全性....)：


設計架構時，可以把外部金流的風險獨立出來成一個解決方案


再者，我們可能也不會只用一家金流，可能會需要建立一些重用的元件。

那我們應該怎麼做選擇呢？回頭前面，從架構特性開始看起。

## 持續改善架構設計

DDD 有助於持續改善架構設計


高內聚、低耦合。

資料庫很容易把相應的服務給綁住。

[演進式架構 書](http://nealford.com/books/buildingevolutionaryarchitectures.html)

觀眾留言：資料庫是造成服務無法解藕的最大共用狀態來源

量子愈大演進能力愈小


### 同步/非同步共生性

* 同步：
[order service] <- req/resp -> [payment system]

訂單/金流服務藕合性較高，互為影響，採用同歩需要較多考量

* 非同步
[order service] <- event -> (= 事件通道 =) <- event-> [payment system]


可能遇到 PK, FK 等技術困難。

### 持續改善架構設計

DB依模組切離，減少藕合性

為了應付更複雜的業務場景，架構再一次演進: Mediator Pattern，讓服務之間不互相依賴


但缺點是架構變得更複雜，比如當一個地方出錯，你會需要更多機制去 debug，難度會比上一個架構難上更多。

不同的架構風格有不同優點與風險，架構師此時就是要讓團隊理解這項決定帶來的改變。商業模式、技術模式的改變，優缺點會一直改變。

## 其他重要的


* 投資基礎工程實務不可以省，開發主管不管如何都應該撥出時間去處理
* test (unit, integrated, e2e)
* CI/CD
* infra as code


# Q&A

> 非功能性需求如安全性、可用性的部分，在作架構規劃時可以怎麼去判讀優先順序？
- 需求結構化，經過激烈的爭辯，針對需求方激烈爭辯哪些是最重要的
- 透明化決策過程，有時候一件事情不只牽涉到單一團隊，也會牽涉多個團隊

> 請問一下 Jed 覺得如何技術廣度如何培養 有什麼建議的方向嗎
- 多看書、多去社群跟人交流
- 不要預設立場，多聽聽看別人的想法
- 領域方面，假如
- 會多種程式語言是架構設計師的必要條件嗎?你是電商，你也要多懂一點電商的商業趨勢等，技術方面也是

> mediator 那層的用途是?
- 是design pattern的一種，主要去協調事件input，及派送至處理的服務。
- 類似的design pattern還有其他的方式可供選擇
- message queue (like RabbitMQ)，需要額外處理一些錯誤，掉訊息(?)

> 可以比較一下Devops和架構師的差異在哪裡嗎?

- 這二者無從比較，對架構師而言都需學習
- Devops是一種文化，是架構師需內化的價值觀，確保上線獲得足夠價值

> 剛剛有提到服務上雲，請問覺得如果企業要上雲該思考到哪些因素呢

- 考量每家企業場域不同
- 會面臨到整個流程的改變
- e.g. 人資服務上雲
- 打卡機原本在地端，上雲如何處理，會改變工作流程
- 要思考工作流程是否因此改善
- 上雲本身屬於偏技術方面議題，最終考量點需回到企業對於流程想改善至何處
- 錢與人的考量

> 非功能性需求要怎麼樣跟User Story Mapping合併在一起表示,讓業務團隊可以理解?

- (建議別名)架構需求，以利業務人員理解
- 直接放進去，讓懂業務的人一起進來

> 改掉技術債問題 (部分非功能性需求可能屬技術債的一部分)
- 判斷：常常出小問題的錯誤，影響開發
- 影響團隊平常的開發能量
- 提醒使用單位，告訴他不做可能會造成的影響

> 在event sourcing / event driven情況下 是否有什麼比較好的方式可以確保資料不會漏 或是最終一致性

> 請問好的架構師如何養成呢？感覺需要掌握新資訊，需要了解人事時地物全貌，亦需理解人性，知道如何溝通。請問是否有相關經驗可供傳承？又哪類領域的IT或特質的人或職位的人，適合邁向架構師呢？

- 每個人都不一樣
- 講師個人經歷，過往為純工程師，所有問題都使用技術解
- 上過 Odd-e Daniel 的 CSM 與 好的課程引導後
- 站在對方的角度思考
- 站在技術以外的架構思考
- 讓自己開放一點
- 不要將技術當成解決事情的必要手段，技術只是工具
- 當作角色去看待，比較能符合期待，不要用職位的角度去看待，任何人都可以勝任

> 請問簡報時，以大圈圈做重點關注，這是使用哪一種工具呢？謝謝！

- 買邏技最貴的簡報筆，約3000多元

> 覺得Jed大開了很多坑，何時開個podcast?XD
- 哈哈哈 (笑而不答)

> ADMEMS 矩陣的範例，在實際上需要去量化嗎? 譬如如何定義可測試性/敏捷性

- 還是需要一定程度上的量化
- 依個別場景而定
- 敏捷性：如提出一個需要，多久可提交至production
- 考驗基礎架構

> 架構師算是技術職還算管理職? 是團隊內的一個成員還是獨立於團隊外比較好?

- 重點是與業務單位、開發團隊協作

> 感恩Jed資訊經驗分享，請問會後方便提供簡報檔嗎？謝謝！
- 會後提供PDF檔

> 會多種程式語言是架構設計師的必要條件嗎?
- 不需精通，只需對語言的特性理解
- 各語言的特性不同

> 這樣感覺在公司從技術者逐漸轉為架構師,是否也是個賭注?
- 是！在很多實踐上無法像工程師一樣

> 架構師的深度同廣度的培養嗎？還是另有其它門道？

- 深度：作POC、實作演算法
- 去了解使用該技術可能會遇到什麼樣的問題
- 工作參與開發，讓團隊做核心開發
- 透過交流維持程式能力

> 在規劃架構/導入技術的時候,如何說服老闆給時間跟金錢,例如老闆可能無法理解基礎工程的重要性,這類問題該如何去解決?

- 以錢的角度出發來分析
- 技術工程背景的老闆，認為自己學有專精，一樣用錢說服

> 團隊的系統沒有什麼架構設計、沒有測試、與業務之間只靠規格書溝通，團隊成員彼此還未建立開發的原則與共識。在這樣的情境下您身為架構師會先做些什麼？
- 先建立對業務目標共識
- 建立對團隊目標的共職
- 對需求排序有共識

> 在拆解流程與場景中討論user story/activities 時會把所有developer和PM拉進來討論嗎？還是只有PM及架構師？這個階段有沒有需要注意的地方？
- 全團隊討論，含DBA、設計
- 不要人身攻擊，準備吃的(遠端工作可以怎麼做?)
- 準備一點吃的，因為動腦很辛苦
- Jed補充：遠端可以透過協作工具 Miro，每個人都能自由的貼上便利貼進行討論與交流

> 在event sourcing / event driven情況下 是否有什麼比較好的方式可以確保資料不會漏 或是最終一致性
- ES為一種pattern，事件進來前需先log
- ES 是有連續性的，(發送端)一發生就要紀錄在可靠的storage上，可靠性需達損毀仍可還原
- 接受端做一樣的事，去比較序號是否有掉
- 事件版本可能有分支，是需要考慮的issue
- keyword: dead letter queue in mq

> 在 DB依模組切離的那個例子 可能一個流程會經過多個模組驗證/修改資料 這樣雖然模組切分了，但是對於資料的驗證，更新，還有講者提到的 transaction rollback 的成本提高許多了，有沒有好的做法可以解決，還是模組切分會造成架構的複雜度提升是沒辦法避免的？
- 以業務邊界切割，切的好應該沒有這個問題
- 不同bounded context有不同驗證需求
- 若不同BC間有互相依賴的情況，表示業務邊界沒有切好
- 找不到商業邊界，業務邊界，技術角度切有危險，建議先別拆

> 在實務不得已的情況，架構師通常會怎樣workaround的解法
- 每次都緊急解技術債，除排時間解，是否有其它招式
- 讓子彈飛一會兒，讓老闆出現痛點，受不了便會將專案排開
- 什麼C可以讓企業轉型?
- CEO(X) CTO(X) Covid-19(O)
- 放著不管有風險
- 前提：在企業的credit要夠好
- 容易有公信力，大家易信服
- 被逼著遠端協作
- 若可解決代表不是問題

> 架構師日常的一天?
- 做好時間管理
- 讓你有時間做技術研究
- 學會say no

> cto喜歡做半套,那架構也先做半套, 該硬著頭皮上嗎
- 先做最有價值的架構
- 再從其它架構切入
- 先與CTO有共識，找出內在原因，可能為策略考量
- CTO問題建議開履歷

> 新的技術一直堆疊，技術種類越來越多架構越來越大，有一個需要開始收斂的範圍或程度嗎？
- 先做POC
- 架構師不要一直玩新技術
- 可以理解學習，不要隨便用
- 拚命疊加新技術，非好現象
- 考量團隊對新技術的掌握度
- 不要在架構上玩新技術
- 業務面、團隊未準備好，建議不要推

> 當團隊head KPI與現在已知產品基礎架構及穩定度已有明顯問題皆需時間調整卻無法狠下心處理變成多頭馬車...該如何逐步進程呢?!
- 重新目標制訂
- 偏向溝通，讓 stakeholder 理解

>公司十五多年的老系統，主管交辦設計新架構，身為架構師的你，你的第一步是什麼呢？

- 業務目標與公司發展方向為何？
- 商業流程或組織有改變
- 找出架構目標，了解舊系統問題
- 先找出商業目標

> 剛剛說不要在架構上玩新技術,但如果新的業務內容產品, 看業界都是使用該類似架構/技術, 是不是該帶領團隊去嘗試該新架構/技術
- 回到業務內容，能不能從中得到好處
- (未來 Ant 場次會提到)

> 可不可以分享採用DDD的好處和挑戰？什麼樣的應用場景適用用它？
- 適合業務場景複雜，要解決軟體核心的複雜度
- 如果業務單純，則不需使用，反而技術變複雜
- 從戰略/戰術
- 需要有良好的團隊協作方式，讓相關的人都一起參與，才能從中得到好處 (避免落入純戰術)

> 架構導入是要「先求有、再求好」的嗎？如果是的話，當「求好」的機會成本變高，會放棄或改變未導入的部分嗎？
- 取決於場景
- 若享受不到好處，不如外包

> 要導入git ,DevOps, Cloud, Agile...，又要考量老舊系統更版，要如何規劃先做何種改變？
- too big to answer...
- 先共識大家的認知
- 先看痛點
- Git(版控)是基礎，在軟體業打滾必要的打底項目
- DevOps 為文化上的變革
- 先找出老闆的痛點

>面對未來要可能架構的調整時，架構師該如何做，才能讓團隊成員理解架構調整的原因，以及如何進行因應的開發上調整、重構？
- DDD的分析方式有所依據
- 團隊需全程參與
- 架構師勿埋入coding
- 取得 team member feeback
- 讓其參與理解與反饋
- 自然而然

> 雖然前面有回答任何人都可以當架構師，但又有提到當架構師是一個賭注，那麼有什麼東西是對於想當架構師之前應該要想清楚的? 以及能否分享當架構師最棒最有成就的事？

要想清楚的:
- 可能沒有時間去寫coding
- 原本很厲害的技能就不那麼厲害了
- 理解商業，理解組織，要了解談判，籌碼交易等
- 多出溝通協調，參與政治議題
- 從對方的說法了解內在議題

最有成就的事情:
- 團隊協作真的解決了他們的問題，而非架構師自己解決
- 讓業績真的有所成長
- 每個人要的不同