©2003 http://www.kevinjin.

com

架構設計師的專業與角色
金興昇
(2002.05.05 首次發表, 2003.03.07 修正)

一直以來，資訊技術(IT)領域存在著一大隱憂，不論是所謂的企業內(In house)
或是軟體公司(Software house)的 IT 團隊，大多數都缺乏架構設計師(Architect)
的編制。架構規劃的工作大都由專案經理、系統分析師與程式設計師兼任或分攤
了，導致普遍輕忽軟體架構專業人才的培養與任用。再不然就是常常將架構設計
師職位作為留住項尖開發人員所用的升級獎勵。其實架構設計師與系統分析師、
程式設計師的專業領域與角色並不相同，接下來我還會進一步點出其中的根本差
異。上述情形在以往系統架構並不複雜的狀態下，還不至於發生太大的問題。但
在分散式架構到處可見的現在，系統本身涉及的實體層面愈來愈複雜，再加上系
統服務的範圍與重要性在 e 化的潮流下與日俱增，遂使諸如安全性(Security)、
可用性(Availability)、可靠性(Reliability)、延展性(Scalability)、效能
(Performance)…等系統層次的非功能性需求(Non-Functional requirement)日益
重要。請看以下兩則最近才發生的新聞：

「財政部表示，如果納稅人不願所得資料上網，在四月二十日以前，仍可以透過
網際網路提出申請。不過，財政部的報稅網站（http://tax.nat.gov.tw）最近因為
湧入大量瀏覽人次，經常塞車，甚至爆掉，許多納稅人等待二、三個小時仍無法
連上網路。」
-----2002/04/16 聯合報 (申請報稅資料免上網 一團亂)

「刑事局針對資料隱碼攻擊手法可能對國內網站的危害分析後，發現國內八成以
上的電子商務網站與各級政府網站，普遍有這種安全漏洞，會被駭客乘隙而入。
更驚人的是，某些電子商務網站已經安裝防火牆與防毒軟體系統，並使用網路交
易安全機制，確認網路交易的身分認證權限，但是資料隱碼攻擊者還是可以輕易
找到漏洞，破壞交易安全的認證制度。」
-----2002/04/23 聯合報 (資料隱碼攻擊 八成網站躲不過)

急於在最後期限之前申請個人所得資料不上網造成報稅網站大塞車，曝露網站系
統在可用性、延展性、效能等等系統層次的問題。資料隱碼（SQL Injection）模
式的駭客攻擊，顯示安全性始終是資訊系統最重要的考量。在這些一連串新聞背
後都是資訊系統架構層次的問題。因此國外有專家戲稱開發系統若不妥善規劃處

©2003 http://www.kevinjin.com
 ©2003 http://www.kevinjin.com

理這類非功能性需求，就容易發生所謂的「CNN 時刻」 (當資訊系統發生重大

問題而造成 CNN 頭條新聞的時刻)。也就是說在媒體發達的今日，軟體功能的完
善與否固然重要，但是系統架構層次(亦即非功能性需求所對應的層次)一旦出現
問題，馬上就有可能成為媒體競相報導的題材，造成企業形象無可彌補的損失。
因此開發團隊若沒有職司因應架構層次需求的架構設計專業人員，由於相關技術
人員責任不清、角色不明，對於目前愈來愈複雜的分散式架構，難免就會發生捉
襟見肘，難以支應的狀況。這種情況就好比要蓋一棟現代化大樓的建築公司缺乏
建築技師一樣，這在建築業是不可思議的事，可是在軟體業卻是司空見慣。

之前為了準備這篇短文用「Architect」上網搜尋相關資訊，無意間看到網友談到
這個英文字的中文翻譯與意涵：

「由於 Engineer 聽起來太過死板, 所以就算在電腦的世界中有人會覺得稱他

們自己為 Architect 比較有設計/創造者的意味在裡頭, 基本上英文是非常活的
語言, 如果你頭腦夠活, 你高興用 Software Director/Designer/Artist/Architect
都無所謂... 」
-----tw.bbs.lang.english
(Re: "Architect"一詞除作"建築師"之外尚有何翻譯?)

在 Marc Sewell 與 Laura Sewell 去年出版的「The Software Architect's

Profession: An Introduction」一書中，曾很俏皮的在該書前言中引用牛津英文字
典對「Architect」的解釋(一般字典都將其視為建築師、或其它諸如造船工業等
技術領域作解釋)，並加入以下一段注釋突顯在軟體領域上的解釋：
「c In full software architect. A designer of software based technology, who
prepares plans, and superintends construction. 」

這句話指出「Architect」主要就是準備計劃並監督建構過程的軟體技術設計人
員，這也就是我會用「架構設計師」作為其譯文的原因。其實一個好的架構設計
師不只是位受到尊敬的資深技術人員，通常也是策略制定、組織協調高手、稱職
的顧問與領導者。這是因為軟體架構規劃與設計主要就是以巨觀(Macro View)
的角度切入系統架構，一般所謂的設計(Design)則是以微觀(Micro View)的角度
切入。比如一般設計師通常考慮的層次是一個使用者按下按鈕時所發生的狀況，
而架構設計師考慮的則是成千上萬個使用者按下按鈕時所發生的狀況。架構設計
師規劃系統的角度主要都是從 Top-Down 方式著手，而一般設計師則是多半從
Bottom-Up 的方式著手。另外，就以大家耳熟能詳的設計模式(Design Pattern)
為例，其實它也被稱為微架構模式(Micro Architecture Pattern)，而諸如
Model-Control-View (MVC)等涉及架構層次的 Pattern 則被稱為架構模式
(Architecture Pattern)。這種巨觀/微觀的角度分野，在其它學科也常看見，如總

©2003 http://www.kevinjin.com
 ©2003 http://www.kevinjin.com

體經濟學與個體經濟學，大歷史觀與微歷史觀等等。這種巨觀角度的本質，就是
架構設計師專業領域與其它軟體開發人員最根本的不同之處。
從巨觀的角度，舉凡架構規格與決策、排定架構審閱時程、解決所有架構相關的
問題、所有主要技術決策的核可、維護架構規格等等都是架構設計的主要工作。
一位好的架構設計師通常具有以下專業領域的技術素養：

-企業需求
-硬體與軟體架構
-分析、設計與開發
-產品支援
-效能、安全性、容量規劃(capacity planning)、網路

通常在專案的一開始，需求與初始分析等工作流程會產生規劃的企業流程與預期
系統完成的功能。有了這些資訊，架構設計師就能研擬最初的高階架構藍圖
(blueprint)並列出影響架構可能因素的清單。另外，架構設計師也要擔負估算專
案成本的職責。這通常是經由審慎評估這些將會付諸實施的專案計劃對系統既有
基礎結構(infrastructure)與架構的衝擊，以及計算可能付出的成本與所帶來的效
益而訂定。
除了上述任務以外，檢查初期架構規劃設計、影響因素與成本，維持與企業架構
決策的一致性也是架構設計師的重要職責之一。這通常要找出制定專案的架構決
策與其優先順序的判斷基準、定義問題領域(Problem Domain)、決定可能解決
方案的制約條件、確認有關可能解決作法的假設狀況以及辨識模組重用的可能
性。架構設計師也必須負責確保需求的達成，以及硬體、軟體、基礎結構、效能、
安全性、容量、可用性和系統運作、管理與維護等等屬於系統層次相關技術之間
的協調與平衡。在某些關鍵時刻，他也要做出系統與架構在協調、妥協與平衡上
種種必須當機立斷但又很困難判斷的決策。
架構設計師必須設法降低可能的技術風險(technical risk)對系統的衝擊。在規劃
初期，技術風險對一般人來說通常都是不可知、不可驗證也不可測的。風險大多
與系統層次的需求有關，有時也會與企業需求有關。不論任何風險的類型，有經
驗的架構設計師都可在專案的先期也就是構建架構時期，預先列出這些可能的風
險，然後在後續的開發時期配合開發人員予以適當地處理與解決。另外，架構設
計師也必須領導開發團隊，保持與其它成員的良好互動，確保開發人員是根據
架構藍圖來構建系統。

就如我之前所說，一個好的架構設計師通常也是策略制定、組織協調高手、稱職
的顧問與領導者。他主要的任務就在規劃與系統架構層次相關的事務，評估可能
的風險與成本，並有效運用有限的人力、物力資源達成系統層次的需求。這樣的
專業人員在很難預知何時湧入大量瀏覽使用者，廣泛運用諸如多層(Multi-tier)、

©2003 http://www.kevinjin.com
 ©2003 http://www.kevinjin.com

叢集式(clustering)等複雜分散式架構，系統效能、安全性、可靠性動輒成為媒體
報導焦點的 e 化潮流下，更加突顯其無可替代的重要性。

「一個具有架構設計師的開發團隊未必就一定能妥善處理系統層次的需求，但一
個不具有架構設計師的開發團隊則肯定沒有人會專責處理系統層次的需求。」

參考書籍
1. “Software Architect's Profession, An Introduction” by Marc Sewell, Laura
Sewell Prentice Hall 2001
2. "Sun Certified Enterprise Architect for J2EE Technology Study Guide" by
Mark Cade, Simon Roberts Prentice Hall 2002

作者簡介
金興昇
專業技術顧問 (Independent Consultant, 網址 http://www.kevinjin.com)
從事物件導向技術相關工作十餘年，曾任物件導向分析設計、J2EE 技術顧問以
及 Borland Taiwan 產品經理。

©2003 http://www.kevinjin.com