演化：这五年里，我们对架构师职责的思考与定位
来源：吃草的罗汉
最近两年，随着互联网红利的消失，对于人才需求似乎已失去往年那种唇枪舌剑的感觉，但我却发现，无论在社交平台，还是技术大会，又有人对 “架构师是用来干嘛的？” 这样的伪命题开始津津乐道，缘由也许是无事生非？还是抒发感情？又有谁在乎呢。
相信任何一家含有技术属性的企业，或多或少都会有一名（或者多名）扮演架构师身份的人存在，在许多人眼里他们是站在技术金字塔最顶端的神秘人物，具有快速切入，举一反三，一句顶一万句的特殊技能，而且逻辑思维能力很强，思路清晰，有洞察力，善于抓重点，但也有人说他们的强项只是打酱油、和稀泥、背黑锅、拉仇恨……
很显然，评价之所以产生如此大的差异，抛去调侃的成分，我觉得还是由于每家企业对架构师职责的定位不同，而且这种不同，会随着技术发展与业务规模的变化，甚至组织结构的调整产生变化。
在进入正题之前，我们先来看看维基百科是如何对 “架构师” 进行分类的：
- 软件架构师
- 信息架构师
- 网站架构师
- 业务架构师
- 中间件架构师
- 基础架构师
与 “官方分类” 相比，好买技术团队中的架构师岗位，不但起源较晚（没记错的话应该是2013年），而且刚开始定位模糊、职责不清，如把这五年的演进进行梳理的话，可简要分为三个阶段：
图1. 好买架构师职责的演进过程
| 第一阶段：技术救火员
2013年，技术团队刚从十余人扩展到几十号人，应用系统也随着业务功能的迭代而增加到三个。
在从 0 到 1 的技术创业阶段，无论开发狗还是业务猫，似乎都更关注功能性需求，往往一个简单粗暴的 MVC 项目就可以搞定一切，但随业务量逐渐增大，用户需求逐渐多样化，非功能性突发情况变得越来越多，而此时也有越来越多的人开始意识到，在技术上遇到难以攻克的问题，如果招俩牛X的架构师在身旁，似乎解决系统的疑难杂症都是小菜一碟。
这一阶段的架构师，无需具备多伟大的宏观设计能力，只要开发小伙伴遭遇技术难题之时，能像美国队长一样挺身而出，施展拳脚，攻克技术细节便可。
| 第二阶段：项目技术评审
2015年，技术团队又从几十号人发展到上百号人，应用系统伴随着 “持续污染” 扩展到了近百个。
众所周知，应用越多，人也就越多，然后功能需求的延期现象越来越严重，直到无法再承受的那天一拍脑门做出决定。
A君提出：“咱们成立PMO（项目管理部）吧，按瀑布迭代的方式推进，这样对项目的控制力会强一些”。 B君质疑：“好是好，但当前引起延期的主要原因都集中在应用架构与技术选型上，使用PM形态应该也无法解决吧？” A君解答：“那就让架构师参与到每个项目中，对每个项目进行技术评审，并逐渐将技术公共服务抽象，这样一来，短期/长期的问题、隐患不都迎刃而解了吗？” B君同意：“的确是个好方法，开干吧！”
看似完美无缺的套路，可实施起来又如何呢？
由于第一阶段的发酵，架构师自身并没有深入参与应用系统的业务环节（当时这个环节是由各应用系统研发Leader管辖的），在业务上的沉淀不足，导致对于软件工程的理解、目标没有清晰的认识。
在做架构设计与技术选型时，非常容易泛泛而谈，甚至与应用系统研发Leader产生冲突，冲突的原因也无非是觉得太过高屋建瓴，缺乏对具体实现的理解和把握。许多架构设计方案，仅仅停留在PPT上，具体的落实完全依靠一线开发人员。
通过一年的磨合，虽说演化出类似缓存系统、调度中心及统一配置服务等多项中间件雏形，但最终由于组织结构的变更，从2017年起，架构师不再参与项目技术评审，此项工作由应用系统研发Leader全权负责。
| 第三阶段：中间件产品化
2017年，技术团队到达了200人的规模，组织结构也被拆分成了互联网化的FeatureTeam，应用系统也打着 “拆” 字的旗号发展到了成百上千的程度。
图2. 中间件平台与服务系统的关系
随着业务支撑场景的复杂度加大，外加FeatureTeam形成后需避免重复性建设，在推动一些全局横向技术工作时，需要有人与应用研发一起突破架构上的各项难题，通过前两阶段的磨练后，架构师是最为合适的人选。
截止到这个阶段，也有一部分架构师转型成为了FeatureTeam团队的Leader，还有一部分架构师则专职负责中间件平台的建设，而每个中间件服务则被划分为不同的产品线，再挑选出几位不但精于技术领域，还能有跨团队、部门沟通，推进事情能力的架构师担当负责人，对技术落地的进度、风险进行把控。
图3. 2017年 - 中间件平台全景图
其实，这样对架构师的职业发展路线也不是坏事，只不过从原先的 ‘身兼数职’ 变为 ‘垂直一职’，对于 "本身酷爱技术" 的他们来说也是一种对于能力的锻炼。
- 感慨 -
演化，有时候就是选了一些完全出人意表的道路，有时只有当回望的那一刹那，你才能分辨好与坏，才能感受到这其中的酸甜苦辣……
你家架构师的演进历程是什么样的？快到评论区分享下吧。