【技術管理者成長系列2】商業如何驅動架構設計？成為架構師前要先懂的8件事

圖片來源:

技術管理者論壇

在臺灣不少技術管理者或技術主管，在公司內也擔任架構師的角色，但相較於國外，過去在臺灣少有架構師公開分享自身架構設計的實驗經驗，不過，近日在一場線上技術管理者論壇上，鼎恒科技應用產品設計中心協理林承毅，大方傳授多年來擔任架構師的工作經驗，不僅教導開發人員怎麼學習平衡開發與架構設計之間的工作，更分享他如何透過商業來驅動架構設計。

林承毅過去在博奕產業IT待了十多年，一手主導不少大型軟體架構設計，來因應各種大流量與高併發的應用場景，對於架構設計相當熟諳，後來進到鼎恒科技，更帶領其中一個產品研發中心團隊，負責應用產品設計與開發。

第一件事：架構師和開發人員的本質不同

許多人用蛻變升級來形容，資深開發人員成為架構師的過程，但林承毅認為，從開發人員到架構師，更像是一種轉職的過程，等於是個人職業生涯的大轉換。因為，取得架構師職位後，意謂著，開發人員有可能必須放棄習慣持續精進的技術能力，轉而提升視野，增加自己的技術廣度。他也以自身為例，擔任架構師幾年來，雖論開發技巧或開發能力，公司比他厲害的人不少，但他對於知識掌握更多，更廣，可以看到更多不同面向。「這是本質上，架構師和一般開發人員的差異。」

第二件事：單有技術深度不夠，架構師還必須持續增加技術廣度

架構師需要建立自己的架構思維，主要有兩個面向，一個是技術深度，一個是技術廣度。

他也說，絕大多數的架構師，成為架構師前，通常是IT團隊裡最資深且技術最扎實的開發人員之一，這些人會對特定技術持續深入學習，一直不斷累積實戰經驗，增加自己的技術深度。然而，成為架構師後要面臨的問題，不僅僅是技術問題，還包括商業領域問題、安全問題、部署環境問題、公司組織文化問題，甚至還有預算考量和法規限制。

正因為時間有限，需要處理的問題實在太多，所以，架構師很難像以前一樣有足夠時間持續精進技術深度，只能在技術深度與技術廣度兩者之間，盡可能取得平衡。

為何架構師需要足夠的技術廣度？林承毅解釋，架構師必須要能看出不同解決方案的差異，甚至分析好壞，才能判斷出還有哪些類似問題可能影響原本的架構設計。而想具備這樣的判斷能力，重點不是對技術掌握多深，而是要有廣度，才能夠很快找出方案中潛藏的問題點。所以，持續增加技術廣度，對於架構師來說很重要。

第三件事：學習平衡開發與架構設計之間的工作

不光如此，團隊中的架構師，得學習平衡開發與架構設計之間的工作分配。通常在決定好架構設計後，多半會認為該由架構師負責核心與最底層的開發任務，聽起來沒有問題，因為架構師最了解自己的設計，但他指出，這樣的作法，衍出生另一個問題，當整體架構出問題，往往只靠架構師自己解決，其他人很難給予協助，這就帶來瓶頸。例如架構師離職了，就沒人懂這個架構，久而久之，原來好的架構設計，會變成團隊必須背負的技術債（或稱祖產），「當你架構沒辦法演化或進化，你的商業模式是很難再進化。」

對於團隊開發與架構設計，林承毅建議，較好的合作模式是，架構師先決定好框架和架構設計後，交由團隊其他成員來負責開發任務，讓架構師只需負責跟業務相關的開發任務，這樣的好處是，一來讓架構師有時間可以持續深化技術不至於與技術脫節，二來團隊成員也能對於架構設計有更多了解，知道開發核心樣貌。

第四件事：架構設計過程深受關鍵需求的影響

開始設計架構時，架構師會依據需求來做取捨，決定整體架構設計樣貌。確認需求有很多方法，林承毅也說，其中一個是可通過ADMEMS需求矩陣進行需求結構化，進而得到需求全貌。一般來說，這些關鍵需求大致可分為功能性需求、約束性需求與品質需求，這些需求都會影響到架構設計，而從需求提取出來的架構特性，可以幫助架構師有效控制需求複雜性，並降低架構設計失敗的風險，以及作為架構設計衝突時的取捨依據。

第五件事：運用DDD方法論將技術架構與商業架構對齊

正因為許多架構師，都是從開發人員、資深開發人員一路往上爬，林承毅有感而發的說：「成為架構師以後，免不了在設計架構時，容易只從技術角度來設計架構，以致於，最後要將商業模型放進架構時，才發現設計出問題，需要犧牲架構其他部分。」所以，他建議，架構師得拆解原本的技術架構，想辦法讓這個架構能夠與商業架構對齊。

要對齊商業架構，也有各種不同作法，他表示，其中一個作法就是可以採用近幾年因微服務盛行而竄紅的領域驅動設計（Domain Driven Design,DDD）方法論，透過這套方法論，能夠從業務相關的領域知識、對問題與解決方案進行切割，找出商業問題邊界、技術邊界、人員溝通一致性邊界，進而理解軟體架構需要解決哪些商業問題及其邊界範圍。他也提到，要讓技術架構能夠對齊商業架構，架構師可以透過DDD方法論中提及的Bounded Context與Subdomaion觀念，來定義問題與解法，建立一個通用語言讓團隊能夠彼此一致對話。

林承毅也說，當我們設計的技術架構跟商業架構能夠互相匹配，就能夠透過商業變化來驅動技術架構上的變化。當技術架構進化了，自然會帶動商業型態再一次改變。「這是業界明顯可以看到的現象。」

第六件事：架構師必須經常取捨，才能達到持續改善的目標

林承毅表示，持續改善架構設計過程中，架構師會一直面臨取捨，甚至有時得放棄一開始認為不錯的架構優點，並接受原先認為有問題的缺點。他補充說明，這是因為最初的缺點或優點，會隨著整個商業模式、營運方式、架構設計而改變，「缺點不見得永遠都是缺點，優點不見得永遠都是優點。」

因為如此，他強調，架構師必須要了解不同架構設計風格，會帶來哪些影響，比如為了調整服務間的通訊方式，提升整個工作流程的靈活性，而改採用事件驅動的架構風格，讓不同服務之間解耦，雖然有其好處，但缺點是架構變更複雜，維護不易，不僅架構整體容錯性需重新設計，同時要避免事件本身在版本差異上造成的衝突。「所以在選擇架構風格時，架構師除了需要知道它可能帶來的負面影響，也得讓團隊理解需要承擔哪些風險。」他說。

第七件事：建立架構設計該有的基本流程與方法

林承毅以一張團隊協作的流程圖，來說明建立架構設計該有的流程與方法。從這張流程圖可以看到，一開始，團隊與領域專家和使用者對話，針對公司的商業目標、問題、需求來彼此溝通，發展出屬於自己的通用語言，藉由通用語言去拆分出問題的解決方案、不同領域問題，然後透過不同的Bounded Context邊界來管理團隊、分析與建模，如此一來，就會產生屬於自己的領域模型，透過這些領域模型撰寫可用於生產或正式環境的程式碼，以及測試環境的程式碼，再透過測試程式碼驗證生產環境程式碼有無問題，過程中並以領域模型同時指導生產與測試環境的程式碼，然後在重開發過程中，重新提煉出經進化完成的通用語言，再從這個通用語言結合新的需求、新的商業目標、問題再拆分出可能要面對的新的Bounded Context邊界。並成為一個反覆循環過程，「我認為這才是在做架構設計應該要有的流程與方法。」

第八件事：架構師要懂得傾聽建議、與團隊緊密合作

因此，林承毅特別強調團隊協作，尤其，對於架構師來說，不只要理解團隊協作怎麼做，還要發揮領導力和學習處理政治問題，讓團隊能夠往期望的目標前進。除此之外，還要落實架構治理，管理決策，以及架構風險等等。

另外，他說，架構師要懂得傾聽團隊成員對架構改善的建議，因架構設計並沒有完美的決策，每一個架構決策，都需要經過充份且激烈的討論。因此，想要讓架構真的可行和成功落地，架構師與團隊需要緊密合作，才有機會達到目標。

最後他還提到，投資基礎工程實務重要性，包括有無完成整合測試、建立自動化測試流程、整合CI/CD測試流程，以及以程式碼方式來控管基儲設施等，這些都能夠幫助開發團隊縮短產品發布時程。