系统架构师
架构师负责理解系统的业务需求，并创建合理、完善的系统体系架构。架构师也负责通过软件架构来决定主要的技术选择。这典型的包括识别和文档化系统的重要架构方面，包括系统的需求、设计、实现和部署"视图"。
职责
- 负责公司系统的架构设计、研发工作；
- 承担从业务向技术转换的桥梁作用；
- 协助项目经理制定项目计划和控制项目进度；
- 负责辅助并指导 SA 开展设计工作；
- 负责组织技术研究和攻关工作；
- 负责组织和管理公司内部的技术培训工作；
- 负责组织及带领公司内部员工研究与项目相关的新技术；
- 管理技术支撑团队并给项目、产品开发实施团队提供技术保障。
应该具备能力
- 具备 8 年以上软件行业工作经验；
- 具备 4 年以上 C/S 或 B/S 体系结构软件产品开发及架构和设计经验；
- 具备 3 年以上的代码编写工作经验；
- 具备丰富的大中型开发项目的总体规划、方案设计及技术队伍管理经验；
- 对相关的技术标准有深刻的认识，对软件工程标准规范有良好的把握；
- 对相关编程技术（如PHP/.Net/JAVA）及整个解决方案有深刻的理解及熟练的应用 ， 并且精通架构和设计模式（如WebService/J2EE），并在此基础上设计产品框架；
- 具有面向对象分析、设计、开发能力（OOA、OOD、OOP），精通 UML 和 ROSE，熟练使用 Rational Rose、PowerDesigner 等工具进行设计开发；
- 精通大型数据库如 Oracle、Sql Server、MySQL 等的开发；
- 对计算机系统、网络和安全、应用系统架构等有全面的认识，熟悉项目管理理论，并有实践基础；
- 在应用系统开发平台和项目管理上有深厚的基础，有大中型应用系统开发和实施的成功案例；
- 良好的团队意识和协作精神，有较强的内外沟通能力。
与其他角色的关系及区别
- 系统构架师与产品经理的关系及区别
- 产品经理通常是指负责产品设计的“专人”。一个优秀的理想的产品经理，应同时具备较高的商业素质和较强的技术背景。产品经理要有深厚的领域经验，也就是说，对该软件系统要应用到的业务领域非常之熟悉。比如，开发房地产销售软件的产品经理，应该对房地产公司的标准销售流程了如指掌，甚至比大多数销售人员还要清楚。如果开发的是通用产品，他/她还具备对市场、潜在客户需求的深刻洞察力。
- 那么，系统架构师与产品经理有什么不同呢？我们不应该把二者混为一谈，这是不少论述和实践常犯的错误。我看来，如果把开发软件比作摄制电影，产品经理之于系统架构师，就正像编剧之于导演。产品经理虽然要有一定技术背景，但仍应属于“商业人士（business people）”，而系统架构师则肯定是一个技术专家。二者看待问题的立场、角度和出发点完全不同。
- 系统构架师与项目经理的关系及区别
- 软件项目经理是指对项目控制/管理，关注项目本身的进度、质量，分配、调动、协调、管理好人、财、物等资源的负责人。对于软件项目经理来讲，包括项目计划、进度跟踪/监控、质量保证、配置/发布/版本/变更管理、人员绩效评估等方面。优秀的项目经理需要的素质，并不仅在于会使用几种软件或是了解若干抽象的方法论原则，更重要的在于从大量项目实践中获得的宝贵经验，以及交流、协调、激励的能力，甚至还应具备某种个性魅力或领袖气质（Charisma）。
系统架构与软件架构
再深一层分析，无论是建筑工程领域，还是其他工程领域（包括计算机科学），从它们的演化历史来看，直觉上我们似乎能够发现其共同点：即从哲学的角度上来说，它们都是人类为了克服与生俱来的恐惧而进行的创造、演化和发展。
人类到底恐惧什么呢？
我们可以注意到，人类本能当中有这样一个重要的共同点：对不确定的、感觉到威胁的事物具有强烈的不安全感。这就激发了人类尽量把这些恐惧的因素控制在最小范围内的愿望。这也就是各个工程学科（包括系统及软件工程领域）在日积月累的发展历程中，逐步规范化、科学化、系列化以及统一化，最终保证人类在复杂环境中，当不确定的因素存在时，依然能够进行有效的控制和协调。
基于同样的目的，计算机科学中也诞生了一个重要的概念，即“系统架构（System Architecture）”。
1997年，Eberhardt Rechtin与MarkW.Maier在其著名的研究论著中，为计算机科学界总结了人类在系统架构方面的实践成果，从而奠定了系统科学和系统架构在计算机科学中的基石。他们通过实践总结，列举了一系列系统架构的应用领域：工业系统、航空系统、软件与信息技术系统等。无论是什么样的系统架构应用领域，应用系统架构原理的目的都是一样的，即完整地、高一致性地、综合全面地、平衡各种利弊地、有技术和市场前瞻性地设计系统和实施系统。Eberhardt Rechtin 与MarkW. Maier这样的方法论级的实践总结，当然立即受到了工程界的热烈欢迎。因为本能的不安全感，会让我们不由自主地摒弃那些不确定的、不系统化的架构经验。
我们平常还能看到这样一种现象：有的行业的架构设计从业人员把自己叫做“系统架构师”（System Architect）；有的软件工程领域的架构人员把自己也叫做“系统架构师”，而不是“软件架构师”。从比尔·盖茨称呼自己为“软件架构师”（Software Architect）来看，他非常明白这两个词的联系和区别。严格地讲，Eberhardt Rechtin与MarkW.Maier提出的“系统架构”或“系统设计”，与我们平时所谈到的“软件架构”或“软件设计”既有千丝万缕的联系，又有比较明显的区别。
当我们把软件技术与其他技术（例如物理技术、化学技术、机械技术、电子技术等）一起放在历史的河流中进行比较时，我们就会发现：为了开发和生产一个产品，其他相关技术的投入和花费的逐年增长率，要远远低于软件设计与开发投入的逐年增长率，如图所示。
在软件技术方面投入的增长率高于在其他技术方面投入的增长率，其主要原因是系统或产品不像过去那样严重受制于硬件或其他技术，而是更加依赖那些非功能方面的要求，这体现在更加依赖于系统对软件及其架构品质的要求。
我们可以以一个医疗行业的CT机（Computed Tomography，计算机X线断层摄影机）系统为例来进行分析。CT机是现代医学诊断中不可缺少的设备。通过X线束对人体的某一部分按一定厚度的层面进行扫描，由于人体各种组织的疏密程度不同，X线的穿透能力也不同，所以检测器接收到的射线就有了差异。由此产生的信号转变为数字信息后由计算机进行处理，并输出到显示屏上，显示出人体组织的图像，以发现病变并确定病变的相对空间位置、大小、数目等。
由于CT机的关键部件包括X线系统、高压发生器、检测器、成像系统、机架与床等，涉及电子、机械、图像处理、计算机等学科。综合考虑，针对CT机质量方面的系统级要求（CT机系统级的要求其实很多，仅列出部分作为参考）如下：
* 安全性（Safety）
* 保密性（Security）
* 可靠性（Reliability）
* 健壮性（Robustness）
* 可制造和装配性（Manufacturability and Assembly，机械设计的人员对这个词不会陌生）
* 可测试性（Testability）
* 可服务性（Serviceability）
* 可配置性（Configurability）
* 可安装性（Installability，你可以在国际软件测试资质认证委员会ISTQB提供的软件测试标准术语表里找到这个词）
* 可演化性（Evolvability）
* 可移植性（Portability）
* 可升级性（Upgradeability）
* 可扩展性（Extendability）
* 可维护性（Maintainability）
* 可处置性（Disposability，环境工程的人员对这个词不会陌生）
除了CT机系统级的质量要求外，我们还可以列出CT机在其他非功能性方面的要求，例如：
* 可用性（Useability）
* 有吸引力的图像界面
* 强吞吐量的生产能力（Throughput or Productivity）
* 快速的响应时间（Response Time）
* 高质量的图像处理
* 状态可重现性（Reproduceability）
* 状态可预测性（Predicatability）
* 高精度计算
* 低廉的成本
* 低廉的运行操作成本
* 与周边环境的强交互能力（CT机操作人员、病人、维护人员等）
* 耗电低
* 较低的其他资源消耗（水、空气、化学药剂等）
* CT机的大小和重量适中
* 资源利用率高
* 运输和移动方便
* CT机市场技术领先性
* CT机设计与行业标准吻合
如果把上述所有CT机系统的非功能性要求做一下汇总和分析，我们就能发现：这些要求都是系统级的设计要求；如果加上CT机的功能要求，就能够代表要生产的CT系统是什么样子、未来会如何运作；这些非功能性的要求，有些是与机械和电子设计相关的，但绝大多数是与软件架构和设计相联系的。这也就意味着，一个完整的CT机系统的非功能性指标要求是由多个子系统和多种技术结合在一起才能得以实现，即一个系统往往是软硬结合的。
从CT机系统这个例子，我们可以清晰地看到：一个系统的实现是结合了各种子系统和各种技术的实现。系统架构的主要任务是界定系统级的功能与非功能的要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段，同时利用各种学科技术完成各子系统的结构构建。
而软件架构首先要理解系统架构，并从软件架构学科的视角对系统架构提出相应的意见，同时从软件的视角协助规划、设计那些实现系统级的各项要求的手段，并最终为各软件子系统提供架构和设计。
从中可以看出，在系统架构活动中，由于对软件越来越深入的依赖，软件架构的任务也显现出重要的作用。而且系统架构与软件架构是紧密联系和互相依赖的。本书的重点将主要集中在“软件架构”，而非“系统架构”上。