好友在写微信公众号，上个月找我约了个稿，写一下程序员成长为架构师的话题，而我也刚好想对这么些年的工作，有一个阶段性的总结，于是有了这篇文章。

朋友公众号文章首发，地址在此。我这里就算留个底。

——————————

0、前言

架构师是一个没有被严格定义的角色。

在写这篇文章之前，我特意把这几年看过的关于架构和架构师的书重新翻了一遍，结果发现它们的定义或多或少有一些不一样，而经过了这几年，一些之前同意的观点，现在的我也不敢苟同了。另一方面，业界对于架构师这个岗位，其实也没有统一的角色定位。在阿里巴巴，前几年是有专职的“架构师”职位的，现在已经回归到“工程师”、“专家”、“研究员”这样的纯技术职位。而我面试过的人中，也有各种各样的“架构师”，很多小团队里，项目经理就经常自认为架构师。大概架构师目前还不至于称为一个职业，更多的是在项目中的一个角色，而其角色定位也是模糊的，因此，这个文章里，我主要还是从自己的理解出发，阐述一下这个角色的定位和个人发展的建议。

1、架构师的定义

架构师：任何复杂结构的设计人员。

架构师的名字来自于建筑业，Software Architect直译应该叫“软件建筑师”。从很多方面讲，软件架构师的工作跟建筑师很像，为了寻根问祖，曾经我也看了不少建筑设计的书（推荐一本《建筑的永恒之道》），最后我发现，两者一脉相承，现阶段分道扬镳，未来也许殊途同归。

一脉相承——不管是建筑师还是软件架构师，都是为了“大图”而存在，做好顶层设计，充当需求方和实施者的桥梁，是其最重要的两个职责。

分道扬镳——两者的发展阶段不同所致。建筑业实践绵延数千年，理论根基有数百年，真正成为一门学科也有一百多年，而软件架构真正出现不过二十年。建筑业已经在足够高的层面上模式化，建筑师能够真正去“设计”，也就是决定“做什么”。而软件行业还在高速发展中，各个层面的技术还在百花齐放。技术的选择意味着权衡，因此软件架构师更多还在关注“怎么做”——这也是建筑师可以称设计师，而软件架构师只能算高阶工程师的原因，设计师更关注美感，而美感在软件架构师的考虑优先级里，排不上第一。

殊途同归——计算机发展的几十年，也是技术不断往上抽象和模式化的几十年。SOA、IoT、IFTTT等技术理念已经接近于建筑行业的模块化级别，各种“智慧城市”、“生态城市”已经在架构层面上考虑“做什么”。假以时日，架构师也许能成为一个真正的纯“设计”的职业，到时候大学里也可以开设“软件架构”的专业了，那一句“建筑设计师在成为建筑设计师之前，是不会成为建筑工人或工程师的“也能在软件行业成为现实。

当然，这只是可能的未来，这需要我们这些前辈技术人员，能够和建筑行业的前辈一样，把技术规范化，设计模式化，还要有一套关于架构美学和功能设计的完整统一的约束，任重而道远。

2、架构的职责

在软件技术发展的前几十年，是没有架构师这个称谓的。所有的人都是程序员，可能有个带头的人，叫主程序员。随着计算机技术的发展，软件覆盖的领域越来越大，软件本身也越来越复杂，现在，动辄几百万行、几千万行代码的软件系统已经非常普遍。软件的复杂化，对于开发人员的脑力负担也不断增大，而人脑所能处理的信息量是有限的，于是，软件开发工具、开发方法也在不断发展，从汇编语言到高级语言，从函数到框架，从面向过程到面向对象，从设计模式到架构模式，总体而言，人类在软件开发工具的各个维度上都在做着”封装“和”抽象”，架构设计是这种抽象和封装的最高层次。从架构的维度上，已经不需要考虑语言、函数、设计模式这一类的抽象，而是站在整体软件系统的高度上，考虑系统设计的技术合理性，需求实现的完整性，商业诉求的匹配度（主要是成本和效率）——这是架构的技术职责。

另一方面，随着行业的发展，软件项目的参与角色和人员也越来越多，从起初只有程序员和需求方，发展到技术、产品、设计、商务、项目管理多团队，技术团队内部的分工也越来越细化，前端、后端、测试、运维、售前售后技术、集成技术等应运而生。架构师是技术团队面向产品设计等团队的接口人，承担着弥合技术与非技术团队之间知识和语言体系差异的职责，同时作为技术团队的带头人，要负责勾勒蓝图，明确边界，让不同技能的团队通力协作，最终完成软件系统的整体建设和发布——这是架构的组织职责；

2.1、架构的技术职责

首先，架构师经常被类比于建筑师，但是有两个建筑领域的基础理念，在软件架构领域是不成立的（至少现阶段不成立）：

建筑设计师在成为建筑设计师之前，是不会成为建筑工人或工程师的。——现阶段的软件架构师，一定是从软件工程师成长起来的。

建筑学和工程学之间的区别表现在“做什么”和“怎么做”：建筑师决定做什么，工程师想出怎么做。——现阶段的软件架构师，除了决定做什么，也要决定关键部分怎么做。

架构的技术职责分为三大块：

• 抽象设计；
• 非功能设计；
• 关键技术设计；

首先是抽象设计。架构师需要能自由地在不同的抽象层次和视角上分析需求，不同的架构层次/视角提供了不同的视图，这些视图互相验证，又能构成整体的设计大图。架构的抽象层次分成两个维度：

• 垂直维度

从上到下，分成企业架构、解决方案架构、应用架构、系统架构等，这个分层的逻辑，是提供不同颗粒度的业务建模。CTO关注企业架构，它提现了一个企业整体的IT技术建设的战略选择，典型的就是集中式和SOA、大型机和云计算的选择等；产品经理和运维关注应用架构，这里映射了产品的业务流程和应用的整体部署依赖；外部客户关注解决方案架构，它定义了如何通过产品的整合和协同，解决特定客户的特定的技术方案需求；研发工程师关注系统架构，这里定义了单个系统的领域建模和系统框架。

• 水平维度

具体到对某一个业务的架构设计，又可以区分出业务架构、数据架构、技术架构、应用架构几个不同的视角。业务架构是对业务领域和业务流程的分析抽象，需要提炼出业务的核心领域模型，业务的可变和不变部分，这是架构师和产品经理协同完成的；数据架构基于业务架构提炼的核心领域模型做数据模型和存储模型的设计；技术架构基于业务的性能，可用性，安全等非功能性指标，确定语言、框架、中间件、部署等技术选型；应用架构基于业务抽象设计应用系统的层次结构、系统边界等。

在这些架构划分中，企业架构匹配商业模式，业务架构匹配业务模式，其他几个架构的划分，更多的是从技术的不同视角来看，他们提供了从不同的抽象层次，不同的切面对于功能需求的分析和建模。

同时需要说明的是，架构的抽象是匹配于业务的，就像桥梁设计师不能直接转做摩天大楼设计，架构抽象也是区分领域的，每一个业务领域都有自己的独特性，因此在架构上也是千人千面的，好的架构设计也是对于业务抽象得最好的设计。

架构师的另一个技术职责，是对非功能需求的分析，这也是“架构服务于功能，高于功能”的含义。这里的非功能性需求包括了软件系统的可靠性、扩展性、可测性、数据一致性、安全和性能等。考虑到成本和运行环境等限制，这些非功能性需求很多时候是不能同时满足的。这个时候就需要“权衡”，空间换时间的算法层面的权衡，性能和可测性、可靠性的权衡，一些权衡甚至上升到了学术层面，变成无完美架构的理论根基（如CAP理论）。

架构师的最后一个技术职责是关键技术设计。建筑师不只是做整体外观设计的，建筑师也需要考虑关键部分的细节设计——曾经在巴塞罗那圣家堂，我甚至看到高迪连教堂里一把椅子都留下了详细的设计图纸。同理，架构师也需要对可能影响到软件系统整体质量的关键部分，做更细节的详细设计。

2.2、架构的组织职责

架构师是企业的一员，作为“边界人”，承担着在不同角色、团队之间沟通协调的作用。

• 和业务、产品团队的协作

软件系统是解决现实世界的问题的，任何的软件系统都是业务相关的，当一个软件系统的商业模式确定之后，架构师就开始和业务、产品团队紧密合作，确定软件系统的业务架构和领域模型。业务和领域模型抽象的好坏，决定了软件产品是一次性的解决方案，还是可以持续支撑业务成长的真正的产品。

需要说明的是，业务、产品方和架构师是需求方和实施方的关系，所以，双方之间既是合作的关系，有时候也是谈判双方的关系，特别是对于外包型的软件产品而言，这个时候，架构师又承担着在业务方和技术团队之间找到诉求契合点的重任。

• 和技术团队的协作

研发阶段，有架构师参与的项目，往往牵涉多个不同方向，不同业务领域的研发团队。架构在其中的作用，是整体大图的传导，以及应用和团队研发边界的划分，对于影响到整体的非功能需求的关键技术点，架构师也要能亲力亲为完成设计。归根结底，架构师为软件系统的整体质量负责，也为研发团队的研发分工负责。

部署阶段，架构师需要和运维团队一起评估满足整体非功能需求的前提下，软件系统部署的硬件成本和部署拓扑结构。例如对于互联网应用，针对性能要求，是否需要CDN，带宽需求；针对可靠性，是否需要多机房部署；针对安全，是否部署相关的安全软件。最终的部署策略，仍然是基于成本和需求的一个权衡。

技术团队是架构师的大本营。根据不同公司的职能定位不同，有的架构师立足于技术团队，有的游离于技术团队。立足技术团队使架构师能更深入了解团队所负责的产品，因此能对业务做更合理的建模，也有利于架构师对关键技术方案做针对性设计，但是可能会限制了架构师拥有更加全局的视角。游离于技术团队的架构师能够从全局看待软件设计而不受制于屁股，因此更能从客观合理的角度规划整体设计，但是由于对技术团队没有管理职能，对于方案的落地只能依靠个人的技术号召力，而且，游离意味着疏远，如果架构师不能自觉地去跟进软件产品的实际落地，可能慢慢就会架空，变成PPT架构师。

简言之，架构师既不能完全负责某个技术团队，也不能完全游离在技术团队之外，这个，又是一个职能定位的权衡了。

同时，架构师和技术团队的协作，还有一个很重要的组织职能。如前述，架构师既决定了整体的架构选型，也决定了关键的技术方案的设计，而什么是需要架构师亲力亲为的关键技术方案，是架构师来确定的。因此，这就引申出架构师的另一个重要的组织职能——团队培养。如果架构师完成所有的技术方案设计，研发团队只管写代码，架构师会累死，研发团队也不会成长，这就要求架构师给予研发团队足够的成长空间和信任，并因此承担一定的风险和责任，这是这个角色必须承担的。

• 和其他角色的协作

除了产品和技术团队，架构师需要协作的还有项目经理，外部客户，甚至是公司财务……一句话，架构师作为技术方案的总负责人，对接所有对技术方案有关联关系的合作方。

• 如何沟通

协作就需要沟通，架构需要掌握多门沟通语言，而最好的语言是图表。对于产品来说，架构师沟通的工具是业务架构，用例和领域模型；对于研发团队来说，架构师沟通的工具是应用架构，组件和时序图；对于运维团队来说，沟通的语言又成了部署架构。图表的作用是维护共同的语言，同时也是让设计文档化以便于传承。

3、架构师的成长

上面讲了架构师的职责，职责既是能力的要求。可以看到，架构师既是一个全方位的技术专家，也是一个沟通协作的专家。因此，总结一下，架构师的成长，也是两条线：

• 技术上

架构师的首要工作是抽象建模，而首要的首要是要了解自己所处的业务领域，只有对业务足够了解，才能更好地抽象和建模，也更能沉淀通用的设计方法论。几年前，我曾经看过我司首席架构师的书单，其中有银行卡组织的介绍的，有零售银行的业务分析的，而那个时候，我司还只是金融业边上的支付公司而已。

另一方面，架构师需要在业务领域所涉及到的技术领域中，都要了解甚至精通，譬如对于互联网行业的架构师，小到语言、算法、数据库，大到网络协议，分布式系统，服务器，中间件，IDC等等都需要涉猎。一句话，架构师是技术团队的对外接口人，也应该是外部团队技术问题的终结者。广度之外也要深度，对于关键的技术模块的设计，架构师需要有技术的权威性。

• 组织和个人成长上

架构师要作为业务和技术的桥梁，因此需要精通业务和技术的语言，要锻炼沟通能力，不只是口头的沟通能力，也包括用标准化的图表表达设计思路的能力。

架构师需要一种“中庸之道”。不管是技术的选型，团队的协作、培养和分工，商业诉求和成本、产品需求和技术诉求的匹配，很多时候都是一种权衡。可以说，架构的工作主题就是权衡，这可能也是工程师成长为架构师最大的挑战。工程师经常是完美主义的，程序也总是精准精确的，但是架构师要习惯于不完美和一定条件下的不精确。

4、补充说明

上面写了这么多，其实针对的是大型的，有明确需求的，多团队参与的项目或者产品的架构师。现实世界中并不都是这样的项目，所以也并不都是这样的角色分工。例如，对于创业团队来说，活下来是最重要的，所以创业团队崇尚的是敏捷开发，快速构建，灵活试错，37signals的《Getting Real》是这种思想的最好诠释。这样的研发体系特别适用于不需要太复杂的底层设计，功能扁平化的，可以快速开发原型，小迭代不断扩展的应用，特别是web应用和APP。

另外，架构师也不是技术人员唯一的方向，甚至不是大多数技术人员的职业方向。在技术上，架构师是广度优先兼具深度，同时在技术之外附带了许多的业务性和组织职能，而很多的技术人员会更倾向于在技术的深度上不断挖掘，也不愿意投入太多的精力在业务和沟通上，这样的技术人员其实更适合的是技术专家的路线。技术专家研究的是纯粹的技术，这里面可能有算法、有编程语言、有运行容器（虚拟机、操作系统、应用服务器、中间件）、有通讯机制，这些都有足够的源源不断的问题等着技术人员去解决，而他们解决的问题，也成为软件技术不断向上抽象，不断模式化的基础，所以，技术专家的路线也是同样重要的。