在很多程序员的大脑中，都会有这样一个打怪升级的路径：

曾经，我对这个路径深信不疑，现在想想，也许是因为初出茅庐的我所看到的江湖太小。慢慢地，在江湖中久了、视野开了，就发现自己想得太简单了。

第 1 个对“架构师”的定义

十多年前，在我初入江湖的时候，首先进入了一家位于深圳的大型软件公司，研发人员的规模上千。面试我的人据说是公司中的架构师，我当时心里真的是对这个架构师充满了仰慕之情，以至于至今我都依稀能够回忆起他的容貌和声音。

当时的后端主流技术是 Struts+Spring+Hibernate，也就是当时业内常说的 SSH；前端的主流技术是 HTML+jQuery+原生 JS。那时还没有管理 jar 包依赖的 maven，也没有开箱即用的 SpringBoot，如果在新的项目中要将上述技术整合起来供开发人员适用，往往需要几天甚至几周的时间，而这些工作都是架构师的职责。

于是，我给架构师下了第一个定义：

架构师就是把各种框架整合到一个项目中，提供通用的代码，支撑开发人员完成业务功能的开发及提供必要的技术支持的人。

后来我回到了西安，此时的我，凭借自身的不断努力，已经将上述的几个技术掌握的很好了。在西安的一家规模不大的软件公司中，我也做起了架构师，同时给自己定了一个工作原则：

不参与业务功能的开发，只为程序员提供通用能力和技术支持。

在之后的几年中，我一直坚守自己对架构是的定义，原理业务知识，一心钻研各种炫酷的技术，也一直作为团队中面对困难的最后一道防线为开发人员提供支持。

第 2 个对“架构师”的定义

现在，我已经在江湖中摸爬滚打了 12 年，在架构师这个岗位上也已经有 8 年左右，原本简单的认为“架构师即巅峰”的我，中间有一段时间迷失了方向。在不断地与人沟通加上多次的面试经历后，似乎在每个人的心里，对“架构师”这个名词的理解都是不一样的。

有一次，在参加一个架构师训练营的时候，培训教材中有一幅图给我留下了很深的印象，虽然原图我已无法找到，但表达的思想如下图所示：

讲师将架构师类比为交响乐中的指挥家，在他的描述中，架构师的视角应该比别人高，关注点并非独立的一个个具体问题，而应该是用全局的视角去通盘考虑、整体规划，然后指挥别人去将规划落到实地。如果架构师过分的深入细节，只会让他因无法抬头看路而迷失方向，就像“不识庐山真面目，只缘身在此山中”一样。

于是，我对“架构师”有了第二个定义：

架构师就是一个站在比别人更高的角度上看待问题，凭借更高的视角而统领全局，不会拘泥于技术细节的人。

但这样一个定义也让我在之后的面试中不断地被面试官挑战，在大部分的面试中，面试官对架构师的要求依然是某项技术的深度，而非整体的技术广度。

第 3 个对“架构师”的定义

在近几年的工作经历中，我又接触到了另一类架构师，他们常常被称作“解决方案架构师”、“行业架构师”、“交付架构师”和“售前架构师”等。

在我最初从事这类工作的时候，我将之前给架构师下的两个定义又重新审视了一遍，似乎此时的工作内容与那两个定义都完全的不同。

经过近 2 年在解决方案架构师这个岗位上的历练，发现这类架构师实际上是作为客户的咨询顾问存在的。工作内容几乎已经脱离编码了，而是给予某一个技术和产品体系，在客户购买前、中、后提供贴身的咨询服务，帮助客户规划技术方向、产品组合以及提供实践方案等。

此时，“架构师”的第三个定义在我的心中诞生了：

架构师就是站在战略的层面，对企业中信息化技术提供整体解决方案、路线图规划以及合规性监管等工作的人。

后来我考取了有“架构师黄金证书”的 TOGAF，也向我打开了“企业架构”的大门，这也让我更加确信我对架构师下的第三个定义。

“架构师”不是这么定义的

虽然我心中对架构师有了 3 个定义，然而它们非但没有让我对架构师地认识更加清晰，反而让我更加地迷惑。尤其是在面试架构师这个岗位时，明明自己很强，但却总觉得自己跟面试官的对话不在一个频道上。这也一度让我对自己的能力产生了怀疑，开始了自我否定。

在深入的思索及阅读相关的资料后，我发现，问题的根源在于对“架构师”这个名词的滥用。

Martin Fowler（微服务架构提出者之一）在其一篇谈论架构师的文章中说到：

不管架构是什么，它都包含了重要的事物，而架构师就是关注这些重要事物的人。

我认为，“架构师”这个名词的滥用，也正是因为这个岗位关注的是重要的事物，因此，行业中在招聘时，只要涉及重要的事物，就会称其为“架构师”。

架构师的分类

其实，架构师是分很多种类的，每一类架构师都有自己的成长路径——这与打怪升级是不同的。

首先，我将“关注竟要的事物的人”拆分为三类，如下图所示：

• 常见的技术专家有：数据库架构师、缓存架构师、框架架构师、工作流架构师”、大数据架构师等，这些架构师专注于对应领域的技术细节。

• 常见的产品、行业专家有：售前架构师、解决方案架构师、交付架构师、某某行业架构师等，这些架构师的关注点不在于研发和技术，而在于某个产品体系或某个行业的通用诉求。

对于上图中的“架构师”而言，还可以继续拆分，如下图所示：

• 研发类架构师：为一个 IT 项目或产品负责，责该 IT 系统的技术规划、研发和运维等工作。常见的岗位名称有：系统架构师、软件架构师、技术架构师等。

• 业务类架构师：普遍存在于各行各业，负责规划其所在企业的业务逻辑。常见的岗位名称有：领域专家、业务架构师、总设计师等。

• 企业架构师：普遍存在于各行各业，负责企业内外 IT 系统的规划和建设。在非 IT 企业中时，主要负责企业内部 IT 的建设，为业务部门提供信息化的支撑；在软件或互联网等 IT 企业中时，则可仅负责企业内部系统也可内外系统均负责。

架构师的工作方式

这里所说的工作方式主要分为两类：集权型和连接型。

（1）集权型架构师

集权型架构师通常在某一领域内拥有出众的能力，是以“问题终结者”的角色出现在团队之中的，当出现其他团队成员无法处理的问题时，集权型架构师会成为团队的最后一道防线。

集权型的优点有：

• 作为决策的唯一制定者，可以高效地统一团队内的思想，保证了团队内的一致性。

• 作为团队内的经验和技术方面的专家，会为其他成员带来安全感。

集权型的缺点有：

• 集权型架构师作为唯一的决策者可以高效地统一思想，但在实际工作中，架构师往往并非距离问题最近的人，架构师的误判也是比较常见的，由于集权型架构师是唯一的决策者，其他成员只能跟随，因此极有可能做出错误的决策。

• 集权型架构师自身强大的个人能力在为其他成员带来安全感的同时，会让其他成员对集权型架构师形成依赖，导致其他成员的积极性和主动性降低，集权型架构师自身的工作强度随之上升。

（2）连接型

连接型架构师就像黏合剂，他们更善于与他人合作。这类架构师可能不具备出众的个人技术能力，但他们拥有丰富的经验和沟通能力，通过和不同职能团队之间深度合作，协助团队解决问题，必要时可为团队提供相应的资源和授权。另外，连接型架构师会成为技术人员和非技术人员之间的桥梁，将业务部门和技术部门连接在一起。

在我工作的早期一段时间，我都非常支持集权型，因为我觉得这样的沟通成本最少、效率最高，但现在来看，其缺点也是不容忽视的，并且，系统越庞大缺点也就约明显。因此我目前的推荐方式是以连接型为主，集权型为辅。

总结

笔者结合自己在软件研发行业 12 年的工作经历，提出了在不同阶段对架构师这个岗位的 3 种定义。在与各类人群针对架构师的讨论过程中，得出“架构师”一词在行业中被广泛的“滥用”这一结论。

在对架构师这一岗位深入的思索后，提出了架构师的分类体系。笔者认为，被滥用的“架构师”一词实际上表达了包括技术专家、架构师和产品、行业专家在内的不同方向，并对架构师这个方向继续分类为：研发类架构师、业务类架构师和企业架构师三类。

总之，架构师关注重要的事物，视角应该更高，避免陷入细节；系统越庞大，越是需要连接型的架构师，当团队踌躇不前时，需要集权型架构师快速地决断。

▼

更多相关内容，欢迎阅读作者新书《企业架构与绕不开的微服务（双色）》！

企业架构与绕不开的微服务（双色）.jpg

▊《企业架构与绕不开的微服务（双色）》

樊超 著

• 在理论方面，介绍了企业架构标准、云原生思想和相关技术、微服务的前世今生，以及领域驱动设计等；

• 在实践方面，介绍了用于拆分微服务的“五步法”、包含 4 个维度的“企业云原生成熟度模型”，以及衡量企业变革成果的“效果收益评估方法”等。

本书的核心内容包括：

• 企业架构的定义与企业架构师的职责；

• 企业架构是否设计良好的评判依据；

• 云原生的相关思想和技术；

• 微服务的起源、演化、特性、拆分方法和落地指南；

• 云原生为企业带来的机遇与变革等。

本书可以帮助企业明确痛点、制定原则、规划路径、建设能力和评估成效，最终实现微服务架构在企业中的持续运营和持续演化，从而应对日益增多的业务挑战。