只做决定的架构师会成为团队的瓶颈!

共 2813字,需浏览 6分钟

 ·

2022-04-11 13:44

我在阿里巴巴工作期间是一个名副其实的“刺头”,批判中台、批判架构师、批判技术管理者,当然,也包括自我批判。

今天来聊聊批判架构师!

Martin Fowler在他的一篇IEEE论文“Who Needs an Architect?”中提到,

能使团队更加敏捷的架构师比只做决定的架构师要更有价值,因为只做决定的架构师会成为团队的瓶颈(bottleneck)。显然,一个架构师的价值和他做的决定是成反比的。

实际上,在这篇文章中,Martin甚至不认为架构师(Architect)这个名词是合适的,他认为更合适的叫法应该是向导(Guide),即一个更有经验的人带领团队走出复杂的迷雾。


尴尬的架构师


在进入阿里巴巴工作之前,我就职于eBay的支付部门。当时有一位架构师,所有的设计和方案都需要获得他的审批才能通过,结果他成了整个团队的瓶颈,很多事情都堆积在他那里。

工程师很难受,光是给他介绍和讨论业务及系统设计就需要花费大量的时间(因为时差原因,经常要讨论一周才有定论);他也不容易,要理解每个系统的结构和业务细节也是很累的。

这里存在的主要问题是这位架构师不在执行团队内部,不了解细节,所以很难给出有价值的建议。对于很多细节,我们认为他不懂,他的方案也无法让我们信服,合作起来自然就很困难。


尴尬的架构部门


如果说架构师是轻量级解决方案,那么还有一个“大规模杀伤性武器”——设立一个专门的架构部门

在阿里巴巴的B2B部门曾经就有这样一个架构组。我记得在当年的启动会上,负责人要求我们画架构图,我质问他这个架构组存在的意义是什么。如果只是画架构图,给老板当PPT用的话,那么我不愿意画这个图。

实际上,画架构图这种务虚任务还好,虽然用处不大,但也构不成杀伤力。真正构成杀伤力的是架构组不甘无为而挖空心思要“做事情”。可以说,在业务技术部门,架构组这种想做事的行为是很危险的,事情越大,杀伤力越大。

为什么这么说呢?我们不妨先来看一下,在业务技术部门中的架构组能做什么。

(1)业务架构?我是营销域的、订单域的、商品域的、供应链域的……如果架构组想比产品经理、运营人员、工程师更懂业务领域、业务流程和业务细节,恐怕很难。一个合格的产品经理应该能做好业务领域的抽象和业务流程的抽象,至于细节,好像没有人比一线开发人员更懂。——架构组,卒!

(2)应用架构?需求相对清晰之后,在应用架构领域有一些影响力的团队负责人(Team Leader,TL)在和团队讨论边界划分和设计方案的时候,尚且会时常争论不休。架构组的“外人”想来指手画脚?这是多么碾压程序员的自尊心啊!——架构组,卒!

(3)技术架构?好吧,让我们架构组回归技术本身,做点纯技术的事情。可是对不起,但凡有点价值的技术中间件都已经有中间件团队在做了。——架构组,带着整个部门一起,卒!

因此,在企业内部设立架构部门是一件要十分谨慎对待的事情。

对一个企业来说,在某个特殊阶段,也许的确需要实体架构组织去保障落实架构工作。但在大部分情况下,特别是在技术体系已经相对完备的情况下,最好不要在部门(Business Unit,BU)内设立专门的架构组织。在我的职业生涯中,我看到过很多业务技术部门尝试设立技术架构组织,基本都以失败告终。


人人都是架构师


架构师不行,架构部门也不行。那由谁来做架构的事情呢?

看一下你左边的同事,再看一下位右边的同事,再看一下你的主管……别看了,他们的确要做,然而你自己也要做——人人都是架构师。

在探讨架构师的工作职责之前,我们先来看一下什么是架构。关于这个问题,每个人的答案可能都不一样。我曾经看过一本技术书,其中用了一章的篇幅讨论架构的定义,但是最终也没有说得很明白。我个人比较认可的关于架构的定义是来自IEEE的定义。简单来说,架构的定义就是要素结构+关系+指导原则。要素(Components)是指架构中的主要元素,结构是指要素之间的相互关系(Relationships),再配合指导原则(Guidelines),便构成了架构,如图1所示。

图1  架构的定义

从架构定义中,我们不难发现,架构师所要具备的架构能力实际上就是一套分析问题、解决问题的方法论。它需要你具备洞察问题本质要素、厘清要素之间的关系,以及制定相应策略的能力。

从这个角度出发,架构能力就是核心竞争力,每个工程师都应该具备一定的架构能力,人人都应该是架构师。

(1)作为技术一线的员工,如果你工作的时间并不长,架构能力相对较弱,那么没有捷径,只有学习学习再学习、成长成长再成长,架构能力是可以习得的,没那么高深,但也没那么容易,需要长期积累。

(2)作为技术团队负责人(TL),你必须要具备一定的架构能力。不管是对于业务架构,还是应用架构,TL都应该具备发现问题的本质要素及厘清要素之间关系的能力。如果你是一名比较欠缺架构能力的TL,那么你需要尽快去补足,不足没有关系,可怕的是停止了学习和成长。正如我比较欣赏的一位技术负责人怀素所说的,很多后劲不足的人主要是过早地停止了学习和成长,你的能力应该是围绕着你的层级上下震荡的,这个震荡范围偏差不会太大,迟早会归于一个相对合理的区间。

(3)作为首席技术官(CTO),那么没的选了,你必须是一个非常优秀的架构师才行。你不仅要熟悉业务架构、精通技术架构,还要通过组织架构设计去解决部门墙问题,让生产关系适应生产力的发展。唯有如此,才能使技术稳定高效地支撑业务发展。

有一些互联网公司没有CTO,他们每个业务单元都有一套自己的技术栈和中间件,大家各自为政,如图2所示。

图2  各自为政的技术体系

针对上述技术体系,最好设置一名CTO。因为对于通用的技术解决方案,比如大数据处理、技术中间件,没必要重复造轮子,显然复用是更科学的做法。

本文节选自《程序员的底层思维》一书,想要了解更多相关内容,欢迎阅读本书!



《程序员的底层思维》

张建飞 著

  • 这是一本超越具体编程技法的技术书:职场晋升不仅需要技术能力,更重要的是思维能力。本书带你学会用底层思维解决复杂技术问题,突破职场“天花板”。

  • 这也是一本培养思维能力的通用技能书:打破认知局限,培养通用的思维能力。本书帮你跳出思维定势,轻松解决生活及工作中遇到的问题。

本书涵盖程序员应知应会的16种思维能力,共18章,分为三部分。

第一部分主要介绍抽象思维、逻辑思维、结构化思维、批判性思维、维度思维、分类思维、分治思维、简单思维,以及成长型思维等解决日常问题的基础思维能力。

第二部分结合软件行业的特点,主要介绍解耦思维、契约思维、模型思维、工具化思维、量化思维、数据思维,以及产品思维等专业思维能力。

第三部分主要是对上述思维能力的综合运用实践。

粉丝专享六折优惠,扫码即购!


 
如果喜欢本文
欢迎 在看留言分享至朋友圈 三连


抽奖赠书


截止时间:2022年4月8日 13:00

如何抽奖:点击下方卡片,参与抽奖


浏览 30
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报