系统架构师的职、责、权

一、 名称与定位

1 职业名称

　　系统架构师（System Architecture）

2 职业定位

　　系统构架，是对已确定的需求的技术实现构架、作好规划，运用成套、完整的工具，在规划的步骤下去完成任务。

　　系统架构师是一个最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。他主要着眼于系统的“技术实现”。

　　系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单，等等。

二、 架构师的主要任务？

架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。　　

ü 领导与协调整个项目中的技术活动（分析、设计和实施等）

ü 推动主要的技术决策，并最终表达为软件构架

ü 确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”

ü 确定设计元素的分组以及这些主要分组之间的接口

ü 为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻

ü 理解、评价并接收系统需求

ü 评价和确认软件架构实现的专业技能

三、 架构师是如何参与到项目/产品研发中的？

1 需求整理分析

　　有人认为架构师是在需求规格说明书完成后介入的，但我认为架构师应该尽可能的从项目最开始的阶段参与进来。理由有很多：

首先，第一手的信息损失最少，架构师能够更好的把握需求；

其次，分析人员在与客户交流时，往往不会深入挖掘需求，因为有很多隐藏的需求客户自己都不见得意识的到，而架构师则可以依靠敏感的软件嗅觉发现这些需求，减少以后的变数；

第三，分析人员往往脱离开发团队，盲目接受客户需求，而架构师能够清楚把握现有的研发团队能做什么，不能做什么，提前预知风险，降低项目失败的机率。

2 系统分解

　　在收集完需求信息后，架构师需要将用户需求转化为软件需求，同时要补充非业务需求，如健壮性，扩展性等等。如何区分和化解用户需求与软件需求，如何有效把握用户需求与软件需求的区别，是系统分解的核心。这是最考验架构师的地方，也是只有架构师参与的工作。

3 技术选型

　　这一步要根据软件需求决定项目该使用何种架构，开发模型，及依赖选项。如使用多层架构还是分布式架构，是瀑布模型还是RUP，是使用MySQL还是SQL Server，是否需要使用企业库，是否需要使用ORM。架构师对项目的技术选型提供多种不同的方案，并为每种不同方案提供详细说明文档，用来阐述每种方案的优势，劣势，可行性等内容。这些文档供领导决策最终的技术选型。

4 系统设计

　　依据软件需求和技术选型，架构师需要和软件工程师一起将软件需求落实到软件详细设计说明书中。架构师负责将软件需求分解，重组织为子项目，子系统，组件和模块，以及它们之间的逻辑关系，从而形成不同的逻辑组成部分，最后还需要确定各个子系统及组件间的接口。这些都是作为进一步的团队分工的依据。同系统分解一样，系统设计是考验架构师能力的重要职责。

5 培训与指导

　　在软件详细设计说明书完成后，为保证项目的顺利进行，架构师需要对整个团队进行技术培训，让团队中的每个人明白自己的职责范围，该做什么，不该做什么。在项目实施过程中，架构师需要参与到具体开发过程中，给与每个开发人员有效指导，以避免团队成员对系统设计的误解而造成项目的延误。在我看来，这点对于新手比较多的团队尤为重要。因为国内新手的一个通病是眼高手低，刚学会了一点点就认为自己什么都会；当他们拿到真正的设计时又往往不知所措，畏首畏尾。

6 保持沟通

　　沟通是保证项目顺利开展的有效保障。架构师要从多方面跟踪项目进度，及时与项目经理或直属领导汇报项目进展，与技术开发人员沟通遇到的问题，如果是迭代开发，还需要与用户沟通需求变更。

四、 公司项目实战

以上是一个项目开发过程中架构师的职、责、权。以下就我在担保集团二期中做的一些事，做一下描述：

n 背景

首先说明一下，我当时在技术部，不是该项目的专职架构师，只是以架构师的身份参与到该项目中。因此，在该项目中我无法履行一个架构师的全部职、责、权。与上文中的描述略有不同。

n 参与的工作

1、 项目售前支持

Ø 与售前项目经理一起去客户现场沟通需求，主要是获取用户的需求，以及关注的核心功能与识别未来可能的变化。担保集团二期项目与一期类似，主要的需求是：业务数据的录入、修改、删除、多级审批、数据分析与统计等需求，以及与第三方平台（一期平台、单点登录平台、电子签章）等实现无缝对接。

Ø 与第三方平台厂商面对面沟通，对涉及到的接口和技术详细讨论，提前预估出存在的风险。

Ø 由于需要与第三方平台实现无缝集成。最核心的关键点是与一期项目平台实现完整对接。而一期开发商与我们是竞争关系，无法获取到任何支持。建议项目经理和市场人员想办法获取一期项目源代码及数据库结构等技术资源，分析技术细节。

2、 项目规划与前景框架

通过以上售前相关的支持，识别出存在的风险、客户的系统运行环境、系统的非功能性需求、业务特性、以及可能存在的需求变更风险，制定前景框架：

Ø 与第三方平台的整合，需要独立开发一套基于JDBC的单点登录平台，实现一期、二期项目人员、角色、权限的统一读取和主体界面的展现。简单点说，就是独立开发一个登录、主界面展现的平台，同时访问和操作一期、二期两个数据库。

Ø 由于客户业务的不确定性，主要表现在：业务单据不确定、业务流程不确定，业务流转条件不确定、业务数据异常、流程步骤回滚等不确定性等因素，需要一套扩展性好、配置简单、能够与业务实现无缝集成的业务工作流引擎。

Ø 基于业务数据分析与统计的需求，需要一款报表工具支撑客户业务的变化，同时考虑报表工具的易用性、成本等，最终选型ireport。

Ø 数据整合：二期项目中的很多初始数据来源于一期项目，需要一款ETL数据抽取工具。为了使用方便，以及我所掌握的技术，推荐使用SQL Server中的SSIS工具，并为项目组员提供技术使用培训。

3、 开发过程

项目进入研发阶段，组织项目组，分析、讨论客户需求的特点，将需求转化为软件开发思想。

Ø 为项目组提供业务工作流引擎的设计思路、功能实现、数据库结构设计、技术（编码）实现方式和思路。对项目核心组员进行架构实现思路的培训(澄清技术细节)，帮助组员理解架构设计的思想，为组员解惑。

Ø 为项目组提供简单的数据库设计规范培训

Ø 为项目组提供简单的编码规范培训

Ø 项目组在研发过程中的疑难支持

n 小结

通过架构师的架构设计，提前预估并规避项目存在的风险。通过技术手段降低系统开发难度，并将业务置于技术架构应用之上，使技术架构能够支撑业务的不确定性。

在系统研发阶段，技术人员几乎不用关注用户的业务，也不需要懂得用户的业务，基础平台研发出来之后，只需要将用户的业务在平台上面进行配置（业务实施），技术与业务相对独立，又相辅相成。