在技术圈，架构师一方面是已经被说烂的职务，另一方面也是让人困扰的职位，行业发展到现在似乎人人都是架构师，各种架构图绚丽多彩漫天飞舞，同时永远有人在抱怨架构太烂、坑太多。

那么到底什么是架构师？如果有一天把你丢到架构师的位置上你会怎么做？ 做什么呢？今天，阿里国际技术事业部的无叶，与大家坐一起，聊一聊。

一、两种架构师

工作五年以上的童鞋，或多或少都会有这样的经历：在小团队或者项目中承担非明确的架构师职责，我们做项目或者产品的关键设计和实施；负责产品基础设施；引入新的理念，框架；解决团队中的复杂问题；在团队成员中享有较高的声誉；被老板认为是团队的关键人物。

如果有一天我们决定（或者其他原因）去做一个专职架构师，那么这两者会有什么区别呢？是否只是之前的方式的延续就足够？

我把第一种状态称之为“兼职架构师”，因为处于这种状态下的同学大部分的时候担当开发人员、PM的角色，只有在小部分时间承担了架构师的部分角色。做的绝大部分事情是自己可控的，自己做架构自己做实施或者在小团队中推行。而后一种“专职架构师”则面临的是：他们不负责具体的业务系统，而又对所有的系统负责，他们也很少直接负责项目，但是职责却要求他们必须对项目要有提前把控，他们面对的是更大的团队，更大的问题域。

当然每一个人对是否应该存在“专职架构师或团队”都有自己的想法，从阿里的历史来看单独的架构团队也是分分合合。在这里不去探讨，我们关心的是如果有，可以怎么做。

二、专职架构师的职责

首先要弄清楚的是专职架构师的职责到底是什么？

微软对架构师有一个分类：

企业架构师EA(Enterprise Architect)、 基础结构架构师IA(Infrastructure Architect)、 特定技术架构TSA(Technology-Specific Architect) 解决方案架构师SA (Solution Architect)。

这个分类是按照架构师专注的领域不同而划分。

在阿里除了EA之外的领域大家可能会同时涉及到，只是不同的时期偏重点不一样。比如前面说的“兼职架构师”可能偏重SA？专职架构师偏向IA+TSA。另外一个角度专职架构师更多考虑问题域和相应的系统架构，而“兼职架构师”更多的是产品的系统架构，具体来说我认为专职架构师重要的职责如下：

职责一：全局的技术规划

架构师第一个最重要的职责是技术规划，架构师最重要的产出是架构，架构就是蓝图，就是阿里常说的一张图。画蓝图就是做“全局的技术规划”，这张图上有什么？ 没有什么？什么时候有？什么时候没有？当你尝试去画图的时候一连串的问题拷打着你。对于一个架构师的心力和体力都是很大的考验。只有这张图非常清晰明确才能指引整个团队在同一个时间向同一个方向前进。

为了这张图你必须和业务紧密沟通，你必须有对应的技术深度和广度，在选型上有自己的方法论，敢于做出判断和决策。

另外一个重点是全局。全局我的理解是全面+格局，全面就是你的技术规划包含各个方面的，在所有的领域都有明确的指引，所以这张图本质是一系列的图的集合；格局上不要只关注短期利益，更多关注长期利益。不止关注团队利益，更多从公司角度出发，只有这样长期才能为团队带来更多的成长。

职责二：统一的方法&规范&机制

架构师第二个重要的职责，我们不仅仅要提供蓝图，还要提供配套的方法论&规范&机制来保障有序进行。蓝图确保整个团队在同一个时间向同一个方向前进。规范确保前进是有序的。为了有序，你必须拆解你的图，纵向、横向、功能内聚等等纬度拆解到权责清晰对等。这是一项相对复杂且繁琐的过程。

职责三：完备的基础构建

除了蓝图确保整个团队在同一个时间向同一个方向前进、规范确保前进的有序的、我们还需要提供强大的武器库，基础构建的完备程度决定你的团队装备是小米+步枪，还是飞机+大炮。完备的基础构建是否全部作为实际架构的职责，可以因情况而定，比如是否有实体的架构组。但是架构对此应当负责。

职责四：落地的规划才是架构

如果规划不能落地就是传说中的PPT架构师，我甚至觉得这是对专职架构师最大的挑战，前面的几个职责更加偏向硬实力，而这一个更多的是软实力的体现。专职的架构师如果不去关注落地的话慢慢就会架空，变成PPT架构师，那差不多就game over了。

三、专职架构师的权利

正如前面说到对架构师最大的挑战是落地层面，实际上“完备的基础构建”已经涉及到落地层面的事情，但是和完备的基础构建不同的是整体架构的落地涉及到方方面面，面临是更多影响因素：和业务的关系、组织结构、权责定义等等。

所以有人从“架构师的权利和职责”的角度出发推论谁合适做架构师。得出的结论是一个组织的领导者。因为只有他才能调动、协调组织。也有人认为架构师既不能完全负责技术团队，也不能完全游离在技术团队之外。因为负责容易屁股决定脑袋，游离就只能靠个人声望值吃饭了。

如正架构分类中EA的存在，很多领导者也确实身体力行的践行架构师的职责，然而精力终有限。实际上更多是平衡的过程。当然最高境界是影响力。

四、专职架构师的考核

针对前面的职责怎么考核？或者怎么设定自己目标？虽然说在不同的团队阶段，不同外在环境，不同的权责情况下不一样，但是在结果导向的背景下落地肯定是架构师重要的考核指标之一。

考核一：全局的技术规划

相比其他几项这一项是最重要又最难评价的，技术规划的好坏、全面性、前瞻性都是定性的描述，如何指引我们做出一个理性的评价呢？回归到本质上“技术规划”只是一个指路灯，团队中每一个人能不能看到“指路灯”就到达目的地是指路灯价值的体现。所以无论是唯价值论还是唯口碑论衡量的其实是同一个东西。

考核二：统一的方法&规范&机制

这一项的考核就相对容易多了，无论是业界还是每一个架构师本身都有自己的一套方法，所以只需关注这些东西对应的产出。

考核三：完备的基础构建

我认为在大公司，大部分重量级的基础构建已经是非常完备，对于架构师来说更难的不是从0到1，而是克制、边界和从1到2的过程。对于架构师也好、技术团队也好“从0到1”总是充满了吸引力，加上技术人的特征，

大公司

技术史上永远不缺少重复的轮子，创建这些轮子成就了一代一代的同学，拆除这些轮子再成就了一代的同学，所以克制尤为重要；有了克制跨团队的合作就尤为重要，对应的有两个点一是清晰边界，二是共建。

考核四：落地的规划才是架构

虽然说落地是非常不控的事情，但是考核却很容易的：做到就是做到、没有就是没有、质量好就是质量好，标准非常清晰。过程中只需要紧跟拆解的事情结合实际的组织和业务情况做出决策。

五、实施的一些想法

对现阶段团队的情况来说，我认为第一是建立“架构语言”，有了语言才有沟通协作的基础，所谓的“架构语言”并不是什么新的东西，而是产品的业务架构，用例和领域模型；研发的应用架构，组件和时序图； 运维的部署架构等等。

第二是建立“认同体”，无论是通过技术能力、知识传递、领域组织等各种方式逐渐形成“认同体”，且在其中形成架构体系对应的人员体系。

第三永远做服务者，架构师对应的客户是团队的每一个成员，必须始终保持客户第一的心态。架构师存在的目的是成就研发团队每一个同学，我们提供必要的平台、服务和空间，然后彼此成就。

最后借用一句话：从无到有的是架构；从表到里的是抽象；从粗到细的是设计。大家对架构师有哪些看法，也欢迎在留言区留言，我们一起交流讨论。