之前其實就有想寫這一篇，但是因為很忙而擱著，今天看到了某些網路文章，才讓我起意把這篇補起來。早期我寫了一系列關於架構師先決條件的文章 "邁向架構師的暖身運動"，簡單說明了怎麼由架構的角度去思考系統設計的方略，今天就用這篇文章將它做個總結吧 (謎之音：其實是你自己懶吧)。
當寫軟體寫到了一定程度，基本上都會開始有了一些程式碼整理、模組化、共用、乃至於規劃整個系統流程的經驗與能力，這時多半已對至少一種語言、技術、框架的運用相對的熟稔，並且能運用自如，同時，可能職務已經不只是做程式開發的程式設計師，或許已歷練了資深工程師或系統分析師 (SA) 的職務，視野會比做一個程式設計師要來得寬廣一些，至少已經知道程式設計已經不只是寫寫程式那麼回事了。不過，即便做了 SA/SD，也未必能做架構師。
架構師到底是什麼？
架構 (Architecture) 這個字是源自於建築界，建築師也叫做 Architect，建築師設計了一幢建築物的構型、管路、電力、空間配置、動線以及建築設備 (如消防安全) 等等，一幢房子的構造藍圖就是 Architecture。同理，軟體系統的架構也是相似的概念，一套系統的軟體架構，涵蓋了系統運作所需要的元件，包含軟體和硬體。
硬體：主機 (伺服器)、網路拓樸 (含設備、連結方式、協定等)、分散式環境必須的系統層級規範與要求等等。
規範：專案管理、軟體工程、品質管理、部署方式、維護作業、需求管理、客戶關係等等。
資源：人力資源、專案資源、系統資源、客戶協力等等。
因此一套系統的設計，只看如何設計程式、軟體是不夠的，還要因應客戶的需求、市場的變化、技術的演進、團隊人力的能量、專案資源的配置等，將這些因素都考慮進去後，所規劃與設計出來的，就是解決方案架構 (Solution Architecture)，其上又可分為對硬體的系統架構 (System Architecture) 以及對軟體的軟體架構 (Software Architecture)，而負責規劃與設計這類架構的角色，就是所謂的架構師 (Architect)。 而架構師除了系統與軟體之外，為了要讓兩者能相互合作發揮綜效，還可能需要定義、研究或發展一系列的管理規則、流程、政策、方法等等。所以架構師不是 SA/SD，但一個合格的架構師必須要能做到 SA/SD 的工作。
IEEE 1471 對架構的定義是：
The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. (系統的基本組織，體現在其組件，彼此之間以及與環境的關係中，以及指導其設計和發展的原理。)
IEEE 1471 對架構師的定義是：
The person, team, or organization responsible for designing systems architecture. (負責設計系統架構的人員，團隊或組織。)
愈大型的系統、複雜度愈高的系統，愈不可能只有一個人做架構設計，而可能會由一個團隊 (一個架構師帶領多個 SA/SD，或是多個架構師) 進行，而架構師會與系統有關的利害關係人 (stakeholders，通常是客戶組織內具關鍵決策權力的角色) 或團隊合作，一起規劃與發展出系統的整體架構，而再交由各負責團隊進行實際的導入、開發、部署或營運，也就是說：
系統架構描述的是一系列建構系統所需要的藍圖、指南、協定、規範、方針、方法論、策略、流程等。
因此，架構師所負責的，就是與利害關係人合作，基於利害關係人所處之專業領域與領域問題 (Domain Problem)，整合專業領域內的專業知識，規劃與設計出符合利害關係人之專業領域所需要系統，並能解決利害關係人所面臨的領域問題 (通常這會轉換為系統需求)。
架構的長相是?
一般開發人員看到的架構，多半是軟體架構，例如實作一個大型的軟體系統元件是怎麼配置、彼此間的關聯性、運作的流程、分工、資料的流向等等；一般的系統架構也差不多，只是角色換成了硬體；而一個領域、一間公司、乃至於一個產業所運作的機制，也能變成一套架構，而這套架構稱為 Business Architecture；一個大型企業的架構則是 Enterprise Architecture。其實不管是哪一種架構，都不脫元件的配置、關聯性、流程、分工等等，只是運作的高度與範圍不同而己
例如下圖是一套軟體架構 (圖來源：網路)：
下圖是一個系統架構 (圖來源：網路)：
下圖是一個 Enterprise Architecture (圖來源：網路)：
這些架構圖都描述了元件的配置、關聯性、流程、分工等要素，但有趣的是，它並沒有定義很明確的、很細節的東西，而這也是架構的主要精神，它並不會交代很細節的內容，這些細節要由基於架構下實作的團隊去定義、實作、維運，而架構必須要指導或要求團隊必須遵循的方法、流程、範圍等邊界。架構除了用圖表示外，也會以一系列的文件、指南等表示，形成一系列的規範，用以指導團隊進行其下的規劃與實作發展。
架構師的要求
架構師的要求其實很簡單，只要滿足下圖的條件即可 (圖來源：http://www.codingthearchitecture.com/presentations/sa2009-broadening-the-t/)。
這張圖要求的兩個條件是：
- 廣度：對技術的基本知識、市場動態、商業思維、管理能力、規劃、溝通與協作、執行能力等要有寬廣的知識，包含領域中的專業知能，尤其是管理、溝通協調能力與規劃能力，將有助於架構發展時對制度面、流程面、管理面的思考、規劃與設計等。
- 深度：對核心技術能力掌握的程度，基本上就是指實作能力，包含程式設計、網路、系統、資料庫、伺服器設定、元件設定、服務存取 (Web Service / RESTful API / ...)、介接方式等等，主要用於實現架構時對技術團隊的指導、指示、協助等工作。
擁有足夠的廣度，才能在分析、規劃與設計上能掌握利害關係人的需求，產出利害關係人所需的架構，並能合適的運用組織的資源、人力、能量等保證架構確可實現；擁有足夠的深度，才能在實現架構時使用適合的技術、方法、元件、流程、結構等，讓架構實現的成功率提升。
若想要當一位架構師，就不能只接觸技術層面的東西，而要多方涉獵接觸學習，尤其是軟實力的那一塊，包含溝通協調、管理、協作能力等，除了能透過坊間課程外，也可以善用公司資源與機會歷練，畢竟軟實力不是只有一個人能學會的，在組織中才有較多學習這一塊的機會。
參考：
