被滥用的“架构师”

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

被滥用的“架构师”_第1张图片

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

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

十多年前,在我初入江湖的时候,首先进入了一家位于深圳的大型软件公司,研发人员的规模上千。面试我的人据说是公司中的架构师,我当时心里真的是对这个架构师充满了仰慕之情,以至于至今我都依稀能够回忆起他的容貌和声音。
当时的后端主流技术是Struts+Spring+Hibernate,也就是当时业内常说的SSH;前端的主流技术是HTML+jQuery+原生JS。那时还没有管理jar包依赖的maven,也没有开箱即用的SpringBoot,如果在新的项目中要将上述技术整合起来供开发人员适用,往往需要几天甚至几周的时间,而这些工作都是架构师的职责。

于是,我给架构师下了第一个定义:

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

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

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

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

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

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

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

被滥用的“架构师”_第2张图片

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

架构师的分类

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

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

被滥用的“架构师”_第3张图片

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

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

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

被滥用的“架构师”_第4张图片

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

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

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

架构师的工作方式

这里所说的工作方式主要分为两类:集权型和连接型。
(1)集权型架构师

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

集权型的优点有:

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

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

集权型的缺点有:

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

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

(2)连接型

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

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

总结

笔者结合自己在软件研发行业12年的工作经历,提出了在不同阶段对架构师这个岗位的3种定义。在与各类人群针对架构师的讨论过程中,得出“架构师”一词在行业中被广泛的“滥用”这一结论。
在对架构师这一岗位深入的思索后,提出了架构师的分类体系。笔者认为,被滥用的“架构师”一词实际上表达了包括技术专家、架构师和产品、行业专家在内的不同方向,并对架构师这个方向继续分类为:研发类架构师、业务类架构师和企业架构师三类。

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


更多相关内容,欢迎阅读作者新书《企业架构与绕不开的微服务(双色)》!

被滥用的“架构师”_第5张图片

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

樊超 著

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

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

本书的核心内容包括:

企业架构的定义与企业架构师的职责;

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

云原生的相关思想和技术;

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

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

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

你可能感兴趣的:(博文视点IT荐书吧,其他)