架构师职责

一、架构师划分 按照架构师专注的领域不同微软将架构师划分为：企业架构师EA(Enterprise Architect)、基础结构架构师IA(Infrastructure Architect)、特定技术架构TSA(Technology-Specific Architect)和解决方案架构师SA (Solution Architect)。

EA的职责是决定整个公司的技术路线和技术发展方向。例如，比尔盖茨。

IA的工作就是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件，这些都是一个技术型公司传承下来的最宝贵的财富之一。

TSA，他们主要从事类似安全架构、存储架构等专项技术的规划和设计工作。

SA的工作则专于解决方案的规划和设计，“解决方案”这个词在中国已经到了严重泛滥的程度，大忽悠们最喜欢把它挂在嘴边。所谓解决方案，就是把产品、技术或理论，不断地进行组合，来创造出满足用户需求的选择。售前工程师一般都是带着它到客户那里去发挥的。

实际工作中，我们也经常会见到另一种比较简单的分类方式，把架构师分为软件架构师和系统架构师。软件架构师基本上是TSA+IA，这也是程序员最容易突破，最可能走上的一条道路，比如JAVA架构师、DotNet架构师、LAPM架构师等等。系统架构师实际上是SA+TSA，更着力于综合运用已有的产品和技术，来实现客户期望的需求。系统架构师要求通晓软、硬件两方面的知识，所以它的知识体系相对庞杂。 如果把架构师分为软件架构师和系统架构师，则涉及到公司的系统工程(System Engineering)和开发工程(Development Engineering)两个部门。系统工程部主要的责任是根据市场需求文档(由市场部编制)实现系统级与子系统级的技术需求定义与分解，并将分解的结果形成一定的文档。文档类型包括需求文档、接口控制文档、系统架构文档、信息模型文档等。系统工程部的工程师被称为系统架构师(System Architect)或直接称为系统工程师(System Engineer)。开发工程部则根据系统工程部的输出文档开发出最终的软件产品。软件开发架构师(Development Architect)是开发工程部最早参与产品开发的人。

二、软件架构师主要职责　　

1、确认需求　　

在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。　　

2、系统分解　　

依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。　　软件架构师的功力基本体现于此，这是一项相对复杂的工作。　　

3、技术选型

　　架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。　　Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。　　架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。

　　4、制定技术规格说明

　　架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。

　　架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。

在实际工作中，软件架构师需要做的事情如下：

1、参与审查(Review)系统工程部的所有文档。系统工程部门的设计方案必须得到所有网元(Network Element，这是电信行业的术语，它是指一个系统中的子产品)级软件架构师都理解和认可以确保其可开发性，这是通过让软件架构师审查系统工程部的输出文档来保证的。软件架构师在审查的过程中可以让相关的开发工程师参与进来，以保证审查质量。出现这种情形，是因为软件架构师存在对具体实现细节不如工程师了解这种情形。

2、作为系统工程部与开发工程部的接口人。在系统工程部需要开发工程部的帮助以了解软件实现细节时，系统工程部会通过软件架构师获得帮助。反之，开发工程部需要系统工程部的帮助时软件架构师就是桥梁。

3、主导网元级研发工作量的评估。在公司计划开发一个新功能或特性时，需要先评估其工作量，软件架构师需要组织网元级工作量的评估，并负责将评估结果录入相应的管理工具中。值得一提的是，评估工作是发生在系统工程部和开发工程部开始具体开发工作之前。

4、实现技术需求网元级的细化和参与需求管理。软件架构师需要根据系统工程部的技术需求做进一步的细化，使得软件开发工程师能实施开发工作。细化后的需求需要与系统工程部的需求进行关联，关联工作也是由软件架构师来完成的。

5、编制软件架构文档。软件架构文档描述了网元的实现包含哪些软件模块，并定义各模块的角色和模块间的消息交互(包括消息名和消息格式)。软件架构文档与网元级的需求(由前面第2项产生)是软件开发工程师工作的输入内容。

6、帮助软件开发工程师答疑解惑，内容包括软件业务逻辑方面的和编码方面的。软件开发工程师如果对需求所描述的业务逻辑存在疑惑，会向软件架构师寻求帮助。如果软件架构师也无法解决，则软件架构师需要向系统工程部获取帮助。软件架构师需要接触软件代码，并在必要的时候需要亲自实施软件设计和编码工作。

7、审查概要设计和详细设计。开发工程师完成概要设计后，需要招开设计审查会议，软件架构师是审查会议中的重要角色。同样地，开发工程师完成详细设计后，也需要邀请软件架构师参与到代码审查会议中。

8、审查测试用例。开发工程师用于验证软件实现的测试用例需要经过软件架构师的审查。

9、参与或发起开发流程的改善工作。对于系统工程部发起的大范围的流程改善工作，软件架构师是开发工程部的代表。对于开发工程部内部的流程改善工作，软件架构师是发起者和组织者。

10、 领导软件疑难问题的攻坚工作。软件架构师因为大多有丰富的经验，自然在解决软件疑难问题时需要扮演重要的角色。

11、负责项目在不同研发中心的技术转移工作。当一个项目需要从一个研发中心转移到另一个研发中心时，软件架构师是主要的技术负责人和领导者。 从上面列出的职责来看，软件架构师在软件实现阶段起着非常重要的角色。

三、软件架构师与系统架构师的区别

1) 系统工程师专注于业务逻辑，不关注代码实现。因此，系统工程师需要对行业规范有很全面和深入的了解。

2) 软件架构师对行业规范的了解程度不需要象系统工程师那样高，但需了解不少代码实现细节。尽管软件架构师对行业规范的要求不是太高，但必须具备快速查找系统工程部所编制的各种文档。

3) 另一个区别前面已经讲了，系统工程师来自系统工程部，而软件架构师来自开发工程部。

四、 软件架构师的误区

1、架构师就是项目经理　　架构师不是项目经理。项目经理侧重于预算控制、时间进度控制、人员管理、与外部联系和协调等等工作，具备管理职能。一般小型项目中，常见项目经理兼架构师。

　　2、架构师负责需求分析　　架构师不是需求分析员。需求分析人员的工作是收集需求和分析需求，并与最终用户、产品经理保持联系。架构师只对最终的需求审核和确认，提出需求不清和不完整的部分，他会跟需求分析员时刻保持联系。架构师是技术专家，不是业务专家。

　　3、架构师从来不写代码　　这是一个尚存争论的问题。目前有两种观点：　　观点1：架构师不写代码，写代码纯体力活，架构师写代码大材小用。架构师把UML的各种视图交给开发人员，如果有不明确的地方，可以与架构师随时沟通。　　观点2：架构师本来自于程序员，只是比程序员站的层面更高，比程序员唯一多的是经验和知识，所以架构师也免不了写代码。　　我个人觉得这两种说法是与架构师的出身和所处的环境有关。　　架构师首先是一个技术角色，所以一定是来自于技术人员这个群体，比如系统架构师，多是来自于运维人员，可能本身代码写得并不多，或者说写不出来很漂亮的代码。软件架构师多是来自于程序员，有着程序员的血统和情怀，所以在项目开发过程中，可能会写一些核心代码。我们的理想是架构师不用写代码，但事实上有时候过于理想。架构师写不写代码，可能取决于公司的规模、文化、开发人员的素质等现实情况。另外，架构师也不是跟程序员界限分得那么清楚，按照能力也有高中低之分，写不写代码不是区分两者的根本标准。

五、软件架构师的素质

1、沟通能力　　为了提高效率，架构师必须赢得团队成员、项目经理、客户或用户认同，这就需要架构师具有较强的沟通能力。沟通能力是人类最普遍性的素质要求，技术人员好像容易忽略，想成为架构师就不能忽略。千万不要抱着这样的观念：怀才跟怀孕似的，时间久了总会被人发现的。还是天桥上卖大力丸的哥们说得对：光说不练假把式，光练不说傻把式。看看你周围的头头脑脑们，哪一个不是此中高手，我们千万不要鄙视，认为这是阿谀奉承、投机钻营，凡事都要看到积极的一面，“沟通”的确是一种能力。我认为自己是一个略内向的人，因为我是农村出来的孩子，普通话都说不好，以前或多或少带有点自卑感，幻想着是金子总会发光，所以在职业生涯中吃了不少亏。现在，我深深懂得了沟通的重要性，我会很主动地跟同事们，跟老大们不定时地沟通，感觉工作起来顺畅多了。　　这一条我认为最为重要，所以排在首位。我甚至认为下面几条都可以忽略，唯一这一条得牢记，而且要常常提醒自己。

　　2、领导能力　　架构师能够推动整个团队的技术进展，能在压力下作出关键性的决策，并将其贯彻到底。架构师如何来保证这种执行力？这就需要架构师具有领导能力。　　架构师的领导能力的取得跟项目经理不太一样。项目经理主要负责解决行政管理，这种能力与技术关系不大，他有****和财权，再扯上一张“领导”的虎皮，采用“胡萝卜加大棒”的方式，基本上可以保证执行力。架构师在项目里面可能更多地使用非正式的领导力，也就是我们常说的影响力，里面包括个人魅力、技术能力、知识传递等等。　　

3、抽象思维和分析能力　　架构师必须具备抽象思维和分析的能力，这是你进行系统分析和系统分解的基本素质。只有具备这样的能力，架构师才能看清系统的整体，掌控全局，这也是架构师大局观的形成基础。你如何具备这种能力呢？一是来自于经验，二是来自于学习。架构师不仅要具备在问题领域上的经验，也需要具备在软件工程领域内的经验。也就是说，架构师必须能够准确得理解需求，然后用软件工程的思想，把需求转化和分解成可用计算机语言实现的程度。经验的积累是需要一个时间过程的，这个过程谁也帮不了你，是需要你去经历的。但是，如果你有意识地去培养，不断吸取前人的经验的话，还是可以缩短这个周期的。这也是我写作此系列的始动力之一。

　　4、技术深度和广度　　架构师最好精通1-2个技术，具备这种技术能力可以更加深入的理解有关架构的工作原理，也可以拉近和开发人员的距离，并形成团队中的影响力。　　架构师的技术知识广度也很重要，需要了解尽可能多的技术，所谓见多识广，只有这样，才可能综合各种技术，选择更加适合项目的解决方案。有的人说，架构师技术广度的要求高于技术深度的要求，这是很有道理的。　　总而言之，一句话：架构师是项目团队中的技术权威。　　面向过程和面向对象这两个基本概念，不仅架构师需要非常清楚，程序员、设计师也要非常清楚，这也是系统分析、设计和编码最基本的常识。我接触的程序员，很多人只停留在一种“似是而非”的程度，这是不行的，想要继续前进，就得把基础夯实，所以我觉得很有必要先回回炉，补补课。