被滥用的 “ 架构师 ” ！

本文主要是介绍被滥用的 “ 架构师 ” ！，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

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

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

第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）连接型

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

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

总结