转载

谁没救过火？但是不能一直救火：我对架构师职责的思考与定位

最近两年，随着互联网红利的消失，对于人才需求似乎已失去往年那种唇枪舌剑的感觉，但我却发现，无论在社交平台，还是技术大会，又有人对 “架构师是用来干嘛的？ ” 这样的伪命题开始津津乐道，缘由也许是无事生非？还是抒发感情？又有谁在乎呢。

相信任何一家含有技术属性的企业，或多或少都会有一名（或者多名）扮演架构师身份的人存在，在许多人眼里他们是站在技术金字塔最顶端的神秘人物，具有快速切入，举一反三，一句顶一万句的特殊技能，而且逻辑思维能力很强，思路清晰，有洞察力，善于抓重点，但也有人说他们的强项只是打酱油、和稀泥、背黑锅、拉仇恨……

很显然，评价之所以产生如此大的差异，抛去调侃的成分，我觉得还是由于每家企业对架构师职责的定位不同，而且这种不同，会随着技术发展与业务规模的变化，甚至组织结构的调整产生变化。

在进入正题之前，我们先来看看维基百科是如何对 “架构师” 进行分类的：

软件架构师
信息架构师
网站架构师
业务架构师
中间件架构师
基础架构师

与 “官方分类” 相比，好买技术团队中的架构师岗位，不但起源较晚（没记错的话应该是2013年），而且刚开始定位模糊、职责不清，如把这五年的演进进行梳理的话，可简要分为三个阶段：

谁没救过火？但是不能一直救火：我对架构师职责的思考与定位

图1. 好买架构师职责的演进过程

| 第一阶段： 技术救火员

2013年，技术团队刚从十余人扩展到几十号人，应用系统也随着业务功能的迭代而增加到三个。

在从 0 到 1 的技术创业阶段，无论开发狗还是业务猫，似乎都更关注功能性需求，往往一个简单粗暴的 MVC 项目就可以搞定一切，但随业务量逐渐增大，用户需求逐渐多样化，非功能性突发情况变得越来越多，而此时也有越来越多的人开始意识到，在技术上遇到难以攻克的问题，如果招俩牛X的架构师在身旁，似乎解决系统的疑难杂症都是小菜一碟。

这一阶段的架构师，无需具备多伟大的宏观设计能力，只要开发小伙伴遭遇技术难题之时，能像美国队长一样挺身而出，施展拳脚，攻克技术细节便可。

| 第二阶段： 项目技术评审

2015年，技术团队又从几十号人发展到上百号人，应用系统伴随着 “持续污染” 扩展到了近百个。

众所周知，应用越多，人也就越多，然后功能需求的延期现象越来越严重，直到无法再承受的那天一拍脑门做出决定。

A君提出： “咱们成立PMO（项目管理部）吧，按瀑布迭代的方式推进，这样对项目的控制力会强一些”。

B君质疑： “好是好，但当前引起延期的主要原因都集中在应用架构与技术选型上，使用PM形态应该也无法解决吧？”

A君解答： “那就让架构师参与到每个项目中，对每个项目进行技术评审，并逐渐将技术公共服务抽象，这样一来，短期/长期的问题、隐患不都迎刃而解了吗？”

B君同意： “的确是个好方法，开干吧！”

看似完美无缺的套路，可实施起来又如何呢？

由于第一阶段的发酵，架构师自身并没有深入参与应用系统的业务环节（当时这个环节是由各应用系统研发Leader管辖的），在业务上的沉淀不足，导致对于软件工程的理解、目标没有清晰的认识。

在做架构设计与技术选型时，非常容易泛泛而谈，甚至与应用系统研发Leader 产生冲突，冲突的原因也无非是觉得太过高屋建瓴，缺乏对具体实现的理解和把握。许多架构设计方案，仅仅停留在PPT上，具体的落实完全依靠一线开发人员。

通过一年的磨合，虽说演化出类似缓存系统、调度中心及统一配置服务等多项中间件雏形，但最终由于组织结构的变更，从2017年起，架构师不再参与项目技术评审，此项工作由应用系统研发Leader 全权负责。