架構師(Architect) 的角色| 小朱® 的技術隨手寫 - - 點部落

當寫軟體寫到了一定程度，基本上都會開始有了一些程式碼整理、模組化、共用、乃至於規劃整個系統流程的經驗與能力，這時多半已對至少一種語言、技術、框架 ... 之前其實就有想寫這一篇，但是因為很忙而擱著，今天看到了某些網路文章，才讓我起意把這篇補起來。

早期我寫了一系列關於架構師先決條件的文章"邁向架構師的暖身運動"，簡單說明了怎麼由架構的角度去思考系統設計的方略，今天就用這篇文章將它做個總結吧(謎之音：其實是你自己懶吧)。

當寫軟體寫到了一定程度，基本上都會開始有了一些程式碼整理、模組化、共用、乃至於規劃整個系統流程的經驗與能力，這時多半已對至少一種語言、技術、框架的運用相對的熟稔，並且能運用自如，同時，可能職務已經不只是做程式開發的程式設計師，或許已歷練了資深工程師或系統分析師(SA)的職務，視野會比做一個程式設計師要來得寬廣一些，至少已經知道程式設計已經不只是寫寫程式那麼回事了。

不過，即便做了SA/SD，也未必能做架構師。

架構師到底是什麼？ 架構(Architecture)這個字是源自於建築界，建築師也叫做Architect，建築師設計了一幢建築物的構型、管路、電力、空間配置、動線以及建築設備(如消防安全)等等，一幢房子的構造藍圖就是Architecture。

同理，軟體系統的架構也是相似的概念，一套系統的軟體架構，涵蓋了系統運作所需要的元件，包含軟體和硬體。

軟體：程式語言、框架、協定、資料處理、產生輸出文件或報表、使用者介面、與外部系統連結方式等等。

硬體：主機(伺服器)、網路拓樸(含設備、連結方式、協定等)、分散式環境必須的系統層級規範與要求等等。

規範：專案管理、軟體工程、品質管理、部署方式、維護作業、需求管理、客戶關係等等。

資源：人力資源、專案資源、系統資源、客戶協力等等。

因此一套系統的設計，只看如何設計程式、軟體是不夠的，還要因應客戶的需求、市場的變化、技術的演進、團隊人力的能量、專案資源的配置等，將這些因素都考慮進去後，所規劃與設計出來的，就是解決方案架構(Solution Architecture)，其上又可分為對硬體的系統架構(SystemArchitecture)以及對軟體的軟體架構(SoftwareArchitecture)，而負責規劃與設計這類架構的角色，就是所謂的架構師(Architect)。

 而架構師除了系統與軟體之外，為了要讓兩者能相互合作發揮綜效，還可能需要定義、研究或發展一系列的管理規則、流程、政策、方法等等。

所以架構師不是SA/SD，但一個合格的架構師必須要能做到SA/SD的工作。

IEEE1471對架構的定義是： Thefundamentalorganizationofasystemembodiedinitscomponents,theirrelationshipstoeachother,andtotheenvironment,andtheprinciplesguidingitsdesignandevolution.(系統的基本組織，體現在其組件，彼此之間以及與環境的關係中，以及指導其設計和發展的原理。

) IEEE1471對架構師的定義是： Theperson,team,ororganizationresponsiblefordesigningsystemsarchitecture.(負責設計系統架構的人員，團隊或組織。

) 愈大型的系統、複雜度愈高的系統，愈不可能只有一個人做架構設計，而可能會由一個團隊(一個架構師帶領多個SA/SD，或是多個架構師)進行，而架構師會與系統有關的利害關係人(stakeholders，通常是客戶組織內具關鍵決策權力的角色)或團隊合作，一起規劃與發展出系統的整體架構，而再交由各負責團隊進行實際的導入、開發、部署或營運，也就是說： 系統架構描述的是一系列建構系統所需要的藍圖、指南、協定、規範、方針、方法論、策略、流程等。

  因此，架構師所負責的，就是與利害關係人合作，基於利害關係人所處之專業領域與領域問題(DomainProblem)，整合專業領域內的專業知識，規劃與設計出符合利害關係人之專業領域所需要系統，並能解決利害關係人所面臨的領域問題(通常這會轉換為系統需求)。

架構的長相是? 一般開發人員看到的架構，多半是軟體架構，例如實作一個大型的軟體系統元件是怎麼配置、彼此間的關聯性、運作的流程、分工、資料的流向等等；一般的系統架構也差不多，只是角色換成了硬體；而一個領域、一間公司、乃至於一個產業所運作的機制，也能變成一套架構，而這套架構稱為BusinessArchitecture；一個大型企業的架構則是EnterpriseArchitecture。

其實不管是哪一種架構，都不脫元件的配置、關聯性、流程、分工等等，只是運作的高度與範圍不同而己 例如下圖是一套軟體架構(圖來源：網路)：下圖是一個系統架構(圖來源：網路)： 下圖是一個EnterpriseArchitecture(圖來源：網路)： 這些架構圖都描述了元件的配置、關聯性、流程、分工等要素，但有趣的是，它並沒有定義很明確的、很細節的東西，而這也是架構的主要精神，它並不會交代很細節的內容，這些細節要由基於架構下實作的團隊去定義、實作、維運，而架構必須要指導或要求團隊必須遵循的方法、流程、範圍等邊界。

架構除了用圖表示外，也會以一系列的文件、指南等表示，形成一系列的規範，用以指導團隊進行其下的規劃與實作發展。

架構師的要求 架構師的要求其實很簡單，只要滿足下圖的條件即可(圖來源：http://www.codingthearchitecture.com/presentations/sa2009-broadening-the-t/)。

這張圖要求的兩個條件是： 廣度：對技術的基本知識、市場動態、商業思維、管理能力、規劃、溝通與協作、執行能力等要有寬廣的知識，包含領域中的專業知能，尤其是管理、溝通協調能力與規劃能力，將有助於架構發展時對制度面、流程面、管理面的思考、規劃與設計等。

深度：對核心技術能力掌握的程度，基本上就是指實作能力，包含程式設計、網路、系統、資料庫、伺服器設定、元件設定、服務存取(WebService/RESTfulAPI/...)、介接方式等等，主要用於實現架構時對技術團隊的指導、指示、協助等工作。

擁有足夠的廣度，才能在分析、規劃與設計上能掌握利害關係人的需求，產出利害關係人所需的架構，並能合適的運用組織的資源、人力、能量等保證架構確可實現；擁有足夠的深度，才能在實現架構時使用適合的技術、方法、元件、流程、結構等，讓架構實現的成功率提升。

若想要當一位架構師，就不能只接觸技術層面的東西，而要多方涉獵接觸學習，尤其是軟實力的那一塊，包含溝通協調、管理、協作能力等，除了能透過坊間課程外，也可以善用公司資源與機會歷練，畢竟軟實力不是只有一個人能學會的，在組織中才有較多學習這一塊的機會。

參考： Whatistheroleofasoftwarearchitect? IEEE1471 架構師系統架構軟體架構架構設計實戰 回首頁 本頁段落 架構師到底是什麼？ 架構的長相是? 架構師的要求