0、前言
架构师是一个没有被严格定义的角色。
在写这篇文章之前，我特意把这几年看过的关于架构和架构师的 书重新翻了一遍，结果发现它们的定义或多或少有一些不一样，而经过了这几年，一些之前同意的观点，现在的我也不敢苟同了。另一方面，业界对于架构师这个岗 位，其实也没有统一的角色定位。在阿里巴巴，前几年是有专职的“架构师”职位的，现在已经回归到“工程师”、“专家”、“研究员”这样的纯技术职位。而我 面试过的人中，也有各种各样的“架构师”，很多小团队里，项目经理就经常自认为架构师。大概架构师目前还不至于称为一个职业，更多的是在项目中的一个角 色，而其角色定位也是模糊的，因此，这个文章里，我主要还是从自己的理解出发，阐述一下这个角色的定位和个人发展的建议。
1、架构师的定义
架构师：任何复杂结构的设计人员。
架构师的名字来自于建筑业，Software Architect直译应该叫“软件建筑师”。从很多方面讲，软件架构师的工作跟建筑师很像，为了寻根问祖，曾经我也看了不少建筑设计的书（推荐一本《建筑的永恒之道》），最后我发现，两者一脉相承，现阶段分道扬镳，未来也许殊途同归。
一脉相承——不管是建筑师还是软件架构师，都是为了“大图”而存在，做好顶层设计，充当需求方和实施者的桥梁，是其最重要的两个职责。
分道扬镳——两者的发展 阶段不同所致。建筑业实践绵延数千年，理论根基有数百年，真正成为一门学科也有一百多年，而软件架构真正出现不过二十年。建筑业已经在足够高的层面上模式 化，建筑师能够真正去“设计”，也就是决定“做什么”。而软件行业还在高速发展中，各个层面的技术还在百花齐放。技术的选择意味着权衡，因此软件架构师更 多还在关注“怎么做”——这也是建筑师可以称设计师，而软件架构师只能算高阶工程师的原因，设计师更关注美感，而美感在软件架构师的考虑优先级里，排不上 第一。
殊途同归——计算机发展 的几十年，也是技术不断往上抽象和模式化的几十年。SOA、IoT、IFTTT等技术理念已经接近于建筑行业的模块化级别，各种“智慧城市”、“生态城 市”已经在架构层面上考虑“做什么”。假以时日，架构师也许能成为一个真正的纯“设计”的职业，到时候大学里也可以开设“软件架构”的专业了，那一句“建 筑设计师在成为建筑设计师之前，是不会成为建筑工人或工程师的“也能在软件行业成为现实。
当然，这只是可能的未来，这需要我们这些前辈技术人员，能够和建筑行业的前辈一样，把技术规范化，设计模式化，还要有一套关于架构美学和功能设计的完整统一的约束，任重而道远。
2、架构的职责
在软件技术发展的前几十年，是没有架构师这个称谓的。所有的 人都是程序员，可能有个带头的人，叫主程序员。随着计算机技术的发展，软件覆盖的领域越来越大，软件本身也越来越复杂，现在，动辄几百万行、几千万行代码 的软件系统已经非常普遍。软件的复杂化，对于开发人员的脑力负担也不断增大，而人脑所能处理的信息量是有限的，于是，软件开发工具、开发方法也在不断发 展，从汇编语言到高级语言，从函数到框架，从面向过程到面向对象，从设计模式到架构模式……
总体而言，人类在软件开发工具的各个维度上都在做着“封装” 和“抽象”，架构设计是这种抽象和封装的最高层次。从架构的维度上，已经不需要考虑语言、函数、设计模式这一类的抽象，而是站在整体软件系统的高度上，考 虑系统设计的技术合理性，需求实现的完整性，商业诉求的匹配度（主要是成本和效率）——这是架构的技术职责。
另一方面，随着行业的发展，软件项目的参与角色和人员也越来 越多，从起初只有程序员和需求方，发展到技术、产品、设计、商务、项目管理多团队，技术团队内部的分工也越来越细化，前端、后端、测试、运维、售前售后技 术、集成技术等应运而生。架构师是技术团队面向产品设计等团队的接口人，承担着弥合技术与非技术团队之间知识和语言体系差异的职责，同时作为技术团队的带 头人，要负责勾勒蓝图，明确边界，让不同技能的团队通力协作，最终完成软件系统的整体建设和发布——这是架构的组织职责。
2.1、架构的技术职责
首先，架构师经常被类比于建筑师，但是有两个建筑领域的基础理念，在软件架构领域是不成立的（至少现阶段不成立）：
建筑设计师在成为建筑设计师之前，是不会成为建筑工人或工程师的。——现阶段的软件架构师，一定是从软件工程师成长起来的。
建筑学和工程学之间的区别表现在“做什么”和“怎么做”：建筑师决定做什么，工程师想出怎么做。——现阶段的软件架构师，除了决定做什么，也要决定关键部分怎么做。
架构的技术职责分为三大块：
抽象设计；
非功能设计；
关键技术设计。
首先是抽象设计。架构师需要能自由地在不同的抽象层次和视角上分析需求，不同的架构层次/视角提供了不同的视图，这些视图互相验证，又能构成整体的设计大图。架构的抽象层次分成两个维度：
垂直维度
从上到下，分成企业架构、解决方案架构、应用架构、系统架构 等，这个分层的逻辑，是提供不同颗粒度的业务建模。CTO关注企业架构，它提现了一个企业整体的IT技术建设的战略选择，典型的就是集中式和SOA、大型 机和云计算的选择等；产品经理和运维关注应用架构，这里映射了产品的业务流程和应用的整体部署依赖；外部客户关注解决方案架构，它定义了如何通过产品的整 合和协同，解决特定客户的特定的技术方案需求；研发工程师关注系统架构，这里定义了单个系统的领域建模和系统框架。
水平维度
具体到对某一个业务的架构设计，又可以区分出业务架构、数据 架构、技术架构、应用架构几个不同的视角。业务架构是对业务领域和业务流程的分析抽象，需要提炼出业务的核心领域模型，业务的可变和不变部分，这是架构师 和产品经理协同完成的；数据架构基于业务架构提炼的核心领域模型做数据模型和存储模型的设计；技术架构基于业务的性能，可用性，安全等非功能性指标，确定 语言、框架、中间件、部署等技术选型；应用架构基于业务抽象设计应用系统的层次结构、系统边界等。
在这些架构划分中，企业架构匹配商业模式，业务架构匹配业务模式，其他几个架构的划分，更多的是从技术的不同视角来看，他们提供了从不同的抽象层次，不同的切面对于功能需求的分析和建模。
同时需要说明的是，架构的抽象是匹配于业务的，就像桥梁设计师不能直接转做摩天大楼设计，架构抽象也是区分领域的，每一个业务领域都有自己的独特性，因此在架构上也是千人千面的，好的架构设计也是对于业务抽象得最好的设计。
架构师的另一个技术职责，是对非功能需求的分析。这 也是“架构服务于功能，高于功能”的含义。这里的非功能性需求包括了软件系统的可靠性、扩展性、可测性、数据一致性、安全和性能等。考虑到成本和运行环境 等限制，这些非功能性需求很多时候是不能同时满足的。这个时候就需要“权衡”
