一直以来，信息技术(IT)领域存在着一大隐忧，不论是所谓的企业内(In house)或是软件公司(Software house)的IT团队，大多数都缺乏架构设计师(Architect)的编制。架构规划的工作大都由项目经理、系统分析师与程序设计师兼任或分摊了，导致普遍轻忽软件架构专业人才的培养与任用。再不然就是常常将架构设计师(architect)职位作为留住项尖开发人员所用的升级奖励。其实架构设计师与系统分析师、程序设计师的专业领域与角色并不相同，接下来我还会进一步点出其中的根本差异。上述情形在以往系统架构并不复杂的状态下，还不至于发生太大的问题。但在分布式架构到处可见的现在，系统本身涉及的实体层面愈来愈复杂，再加上系统服务的范围与重要性在e化的潮流下与日俱增，遂使诸如安全性(Security)、可用性(Availability)、可靠性(Reliability)、延展性(Scalability)、效能(Performance)…等系统层次的非功能性需求(Non-Functional requirement)日益重要。请看以下两则最近才发生的新闻：
「“财政部”表示，如果纳税人不愿所得资料上网，在四月二十日以前，
仍可以透过网际网络提出申请。不过，财政部的报税网站（http://tax.nat.gov.tw）最近因为涌入大量浏览人次，经常塞车，甚至爆掉，许多纳税人等待二、三个小时仍无法连上网络。」
-----4/16联合报 (申请报税资料免上网 一团乱)
「刑事局针对资料隐码攻击手法可能对网站的危害分析后，发现八成以上的电子商务网站与各级政府网站，普遍有这种安全漏洞，会被骇客乘隙而入。更惊人的是，某些电子商务网站已经安装防火墙与防毒软件系统，并使用网络交易安全机制，确认网络交易的身分认证权限，但是资料隐码攻击者还是可以轻易找到漏洞，破坏交易安全的认证制度。」
-----4/23联合报 (资料隐码攻击 八成网站躲不过)
急于在最后期限之前申请个人所得资料不上网造成报税网站大塞车，曝露网站系统在可用性、延展性、效能等等系统层次的问题。资料隐码（SQL njection）模式的骇客攻击，显示安全性始终是信息系统最重要的考量。在这些一连串新闻背后都是信息系统架构层次的问题。因此国外有专家戏称开发系统若不妥善规划处理这类非功能性需求，就容易发生所谓的「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)。这种巨观/微观的角度分野，在其它学科也常看见，如总体经济学与个体经济学，大历史观与微历史观等等。这种巨观角度的本质，就是架构设计师专业领域与其它软件开发人员最根本的不同之处。
从巨观的角度，举凡架构规格与决策、排定架构审阅时程、解决所有架构相关的问题、所有主要技术决策的核可、维护架构规格等等都是架构设计的主要工作。一位好的架构设计师通常具有以下专业领域的技术素养：
-企业需求
-硬件与软件架构
-分析、设计与开发
-产品支持
-效能、安全性、容量规划(capacity planning)、网络
通常在项目的一开始，需求与初始分析等工作流程会产生规划的企业流程与预期系统完成的功能。有了这些信息，架构设计师就能研拟最初的高阶架构蓝图(blueprint)并列出影响架构可能因素的清单。另外，架构设计师也要担负估算项目成本的职责。这通常是经由审慎评估这些将会付诸实施的项目计划对系统既有基础结构(infrastructure)与架构的冲击，以及计算可能付出的成本与所带来的效益而订定。
除了上述任务以外，检查初期架构规划设计、影响因素与成本，维持与企业架构决策的一致性也是架构设计师的重要职责之一。这通常要找出制定项目的架构决策与其优先级的判断基准、定义问题领域(Problem Domain)、决定可能解决方案的制约条件、确认有关可能解决作法的假设状况以及辨识模块重用的可能性。架构设计师也必须负责确保需求的达成，以及硬件、软件、基础结构、效能、安全性、容量、可用性和系统运作、管理与维护等等属于系统层次相关技术之间的协调与平衡。在某些关键时刻，他也要做出系统与架构在协调、妥
协与平衡上种种必须当机立断但又很困难判断的决策。
架构设计师必须设法降低可能的技术风险(technical risk)对系统的冲击。在规划初期，技术风险对一般人来说通常都是不可知、不可验证也不可测的。风险大多与系统层次的需求有关，有时也会与企业需求有关。不论任何风险的类型，有经验的架构设计师都可在项目的先期也就是构建架构时期，预先列出这些可能的风险，然后在后续的开发时期配合开发人员予以适当地处理与解决。另外，架构设计师也必须领导开发团队，保持与其它成员的良好互动，确保开发人员是根据架构蓝图来构建系统。
就如我之前所说，一个好的架构设计师通常也是策略制定、组织协调高手、称职的顾问与领导者。他主要的任务就在规划与系统架构层次相关的事务，评估可能的风险与成本，并有效运用有限的人力、物力资源达成系统层次的需求。这样的专业人员在很难预知何时涌入大量浏览使用者，广泛运用诸如多层(Multi-tier)、集群式(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
