在很多程序员的大脑中,都会有这样一个打怪升级的路径:
曾经,我对这个路径深信不疑,现在想想,也许是因为初出茅庐的我所看到的江湖太小。慢慢地,在江湖中久了、视野开了,就发现自己想得太简单了。
第1个对“架构师”的定义
当时的后端主流技术是Struts+Spring+Hibernate,也就是当时业内常说的SSH;前端的主流技术是HTML+jQuery+原生JS。那时还没有管理jar包依赖的maven,也没有开箱即用的SpringBoot,如果在新的项目中要将上述技术整合起来供开发人员适用,往往需要几天甚至几周的时间,而这些工作都是架构师的职责。
于是,我给架构师下了第一个定义:
架构师就是把各种框架整合到一个项目中,提供通用的代码,支撑开发人员完成业务功能的开发及提供必要的技术支持的人。
后来我回到了西安,此时的我,凭借自身的不断努力,已经将上述的几个技术掌握的很好了。在西安的一家规模不大的软件公司中,我也做起了架构师,同时给自己定了一个工作原则:
不参与业务功能的开发,只为程序员提供通用能力和技术支持。
在之后的几年中,我一直坚守自己对架构是的定义,原理业务知识,一心钻研各种炫酷的技术,也一直作为团队中面对困难的最后一道防线为开发人员提供支持。
第2个对“架构师”的定义
现在,我已经在江湖中摸爬滚打了12年,在架构师这个岗位上也已经有8年左右,原本简单的认为“架构师即巅峰”的我,中间有一段时间迷失了方向。在不断地与人沟通加上多次的面试经历后,似乎在每个人的心里,对“架构师”这个名词的理解都是不一样的。
有一次,在参加一个架构师训练营的时候,培训教材中有一幅图给我留下了很深的印象,虽然原图我已无法找到,但表达的思想如下图所示:
讲师将架构师类比为交响乐中的指挥家,在他的描述中,架构师的视角应该比别人高,关注点并非独立的一个个具体问题,而应该是用全局的视角去通盘考虑、整体规划,然后指挥别人去将规划落到实地。如果架构师过分的深入细节,只会让他因无法抬头看路而迷失方向,就像“不识庐山真面目,只缘身在此山中”一样。
于是,我对“架构师”有了第二个定义:
架构师就是一个站在比别人更高的角度上看待问题,凭借更高的视角而统领全局,不会拘泥于技术细节的人。
但这样一个定义也让我在之后的面试中不断地被面试官挑战,在大部分的面试中,面试官对架构师的要求依然是某项技术的深度,而非整体的技术广度。
第3个对“架构师”的定义
在近几年的工作经历中,我又接触到了另一类架构师,他们常常被称作“解决方案架构师”、“行业架构师”、“交付架构师”和“售前架构师”等。
在我最初从事这类工作的时候,我将之前给架构师下的两个定义又重新审视了一遍,似乎此时的工作内容与那两个定义都完全的不同。
经过近2年在解决方案架构师这个岗位上的历练,发现这类架构师实际上是作为客户的咨询顾问存在的。工作内容几乎已经脱离编码了,而是给予某一个技术和产品体系,在客户购买前、中、后提供贴身的咨询服务,帮助客户规划技术方向、产品组合以及提供实践方案等。
此时,“架构师”的第三个定义在我的心中诞生了:
架构师就是站在战略的层面,对企业中信息化技术提供整体解决方案、路线图规划以及合规性监管等工作的人。
后来我考取了有“架构师黄金证书”的TOGAF,也向我打开了“企业架构”的大门,这也让我更加确信我对架构师下的第三个定义。
“架构师”不是这么定义的
虽然我心中对架构师有了3个定义,然而它们非但没有让我对架构师地认识更加清晰,反而让我更加地迷惑。尤其是在面试架构师这个岗位时,明明自己很强,但却总觉得自己跟面试官的对话不在一个频道上。这也一度让我对自己的能力产生了怀疑,开始了自我否定。
在深入的思索及阅读相关的资料后,我发现,问题的根源在于对“架构师”这个名词的滥用。
Martin Fowler(微服务架构提出者之一)在其一篇谈论架构师的文章中说到:
不管架构是什么,它都包含了重要的事物,而架构师就是关注这些重要事物的人。
我认为,“架构师”这个名词的滥用,也正是因为这个岗位关注的是重要的事物,因此,行业中在招聘时,只要涉及重要的事物,就会称其为“架构师”。
架构师的分类
其实,架构师是分很多种类的,每一类架构师都有自己的成长路径——这与打怪升级是不同的。
首先,我将“关注竟要的事物的人”拆分为三类,如下图所示:
对于上图中的“架构师”而言,还可以继续拆分,如下图所示:
架构师的工作方式
(1)集权型架构师
集权型架构师通常在某一领域内拥有出众的能力,是以“问题终结者”的角色出现在团队之中的,当出现其他团队成员无法处理的问题时,集权型架构师会成为团队的最后一道防线。
集权型的优点有:
集权型的缺点有:
(2)连接型
连接型架构师就像黏合剂,他们更善于与他人合作。这类架构师可能不具备出众的个人技术能力,但他们拥有丰富的经验和沟通能力,通过和不同职能团队之间深度合作,协助团队解决问题,必要时可为团队提供相应的资源和授权。另外,连接型架构师会成为技术人员和非技术人员之间的桥梁,将业务部门和技术部门连接在一起。
在我工作的早期一段时间,我都非常支持集权型,因为我觉得这样的沟通成本最少、效率最高,但现在来看,其缺点也是不容忽视的,并且,系统越庞大缺点也就约明显。因此我目前的推荐方式是以连接型为主,集权型为辅。
总结
在对架构师这一岗位深入的思索后,提出了架构师的分类体系。笔者认为,被滥用的“架构师”一词实际上表达了包括技术专家、架构师和产品、行业专家在内的不同方向,并对架构师这个方向继续分类为:研发类架构师、业务类架构师和企业架构师三类。
总之,架构师关注重要的事物,视角应该更高,避免陷入细节;系统越庞大,越是需要连接型的架构师,当团队踌躇不前时,需要集权型架构师快速地决断。
▼
更多相关内容,欢迎阅读作者新书《企业架构与绕不开的微服务(双色)》!