法则五:架构师为什么要关注技术体系的外部适应性?

架构系列课专栏目录总览

前四条法则分别讲了目标、资源、人性和技术周期,这些都与架构活动的外部环境有关。那么今天我们来讲讲在架构活动内部,也就是在架构师可控的范围内,应该遵守哪些法则。今天这节课,我们就先从技术体系的外部适应性讲起。

达尔文说过:“既不是最强壮的也不是最聪明的物种,而是最适应变化的物种最终生存了下来。”从这个角度来看,企业也是一个物种。一个企业在行业内与其他企业形成了竞争关系。那么最终在竞争中胜出的,不一定是体量最大的,也不一定是技术最先进的,而会是最适应竞争环境变化的企业。

计算机行业有很多这样的例子。比如大企业 Lucent、Kodak、Compaq 都在竞争中没落了,曾经技术非常先进的 SGI、Sun Microsystems、Digital Corp 到后来也都挂了。一个正面的例子是,微软在云计算领域原本慢了大半拍,但他转身非常彻底,后来很快就追上了,成了异军突起的赢家。

那么你作为架构师,能在企业的竞争中做些什么,同时也为自己创造增量价值呢?答案是:通过技术手段为企业注入更多的外部适应性。

这就是第五条生存原则要覆盖的内容:架构师要通过优化架构方案、干预架构活动,以保证最终交付的项目不仅能满足既定目标,还能适应不断变化的外部环境。这个过程有一个总的指导原则,那就是为最终产生的架构设计不断注入外部适应性。

架构师能注入外部适应性?

外部适应性是指一个企业对外部环境变化的适应能力,以及对新机会的捕捉能力。

我特别要强调“外部”这个词。它表示适应性不是面向企业内部的,而是企业在外部环境发生变化时、在与其他企业竞争时所具备的适应能力。这是一个攘外而非安内的能力。

怎么理解呢?像苏宁和塔吉特(Target)这样的线下卖场,打磨了很多年之后,他们的效率很高。但当用户的购买行为都转到线上后,他们适应新的竞争环境的能力就不够了。也就是说,他们在互联网时代的外部适应性不足。

在企业中,不同职能所处的视角不同。那么你作为架构师,需要从自己的视角为企业注入外部适应性。同时在这个过程中,提升自己独立创造价值的能力。

不同职能之间视角的差异性

在企业中,很多职能都可以为企业注入外部适应性,举几个例子:

业务同学通过商业和投资手段,来迅速捕捉外部的商业机会,从而为客户创造价值,为企业获取竞争优势。比如大公司通过兼并小公司进入一个新兴市场。

运营同学通过新场景迭代效率,来提升企业的市场竞争力和市场占有率。比如阿里的大促运营,就是通过一系列营销手段来提升获客效率和销售额的,从而扩大了市场渗透率。

产品经理通过不断打磨产品来提升用户体验,从而达到提升企业竞争力和市场占有率的目标。比如抖音创作者和用户端的产品优化。

技术同学通过打磨技术体系来支持产品和运营,从而达到提升企业外部竞争力的目标。比如各个互联网公司都在打磨个性化算法、运营后台、数字化运营体系。

架构师是技术职能的一种,所以也是通过打磨技术体系来为企业注入外部适应性的。当然,架构师这个职能有自己的特殊性。首先,架构师与研发经理不同。后者具有人员管理的职责,因而可以通过人才招聘、培养和组织架构的调整来创造价值。

然后,架构师也不同于研发人员。研发人员可以通过优化数据模型、算法迭代、代码重构和模块升级来为企业直接注入外部适应性。而架构师仅仅可以通过组织架构活动与优化架构方案设计,来为企业注入外部适应性。

可以看到,我特别区分了几种职能所处视角的差异。为什么这么做呢?我发现,很多架构师把帮助他人创造价值与自身创造价值这两件事混为一谈,这样做,你就很难提升自己独立创造价值的能力。

举个例子。在大公司某个程序员晋升时经常会套用这样一个逻辑:“我们的大促业绩同比增长了 50%,所以我应该晋升。”

仔细想想,这个增长到底是业务方在大促期间多拓展了一倍商家带来的?还是产品同学重新设计了大促的商品圈选和反向招商逻辑,导致平台商品增长了 30% 带来的?还是你通过技术创新,用知识图谱把商品之间的语义标签做得更多更准,导致交叉售卖的量增长带来的?

所以说,你负责大促的商品模块,不代表大促中所有商品售卖赚来的钱都是你挣来的。这个时候,你就需要展示自己从技术视角上创造的价值,这才是你独立创造的增量价值。如下图所示,展示了业务、产品和技术视角的差异性。

法则五:架构师为什么要关注技术体系的外部适应性?

业务、产品和架构师所处的技术视角,分别代表研发活动的三个不同层次。

第一个层次,研发活动由业务驱动,直接在业务人员的指挥下响应外部机会。我们把这一组研发人员称为业务线研发。在一些公司里,这些人一般直接向业务部门汇报。比较常见的是增长的产品和技术人员同时汇报给增长业务部门,以迅速响应新的业务机会。

第二个层次,研发活动由产品规划驱动。产品把业务活动抽象为一组产品,沉淀出产品矩阵,并通过产品运营不断打磨用户心智。在这个过程中,相应的技术人员会不断提升自己对产品的理解,并通过技术手段放大产品提供给用户的增值。

比较常见的产品有营销产品、供应链产品、物流产品等。除了产品特性本身外,一些纯技术手段,比如营销的资金池优化、反作弊、供应链优化、物流调拨等等,也会为产品带来新的增值手段。

第三个层次,研发活动就是由架构师主导的架构活动。架构师和研发同学对业务、产品做了一系列的抽象,最终形成由技术驱动的技术产品。比如工作流引擎、风控引擎、策略引擎、算法的特性引擎和标签引擎,都属于这一类产品。

案例指引

我拿一个物流领域的场景来举例。如图所示:

法则五:架构师为什么要关注技术体系的外部适应性?

假设你所在的企业有比较复杂的物流场景,那么业务团队经常会找新的物流供应商, 为平台提供物流的外包服务,或者是覆盖一个新场景,也或者是覆盖一个新路线。那么相应的业务线物流团队,就需要与供应商对接,迅速完成接入。

但是随着时间的推进,团队在物流上的经验变得更丰富了,物流线路也越来越多,单个供应商对接的方式只会越来越低效。这个时候,就需要有一个产品团队,把企业内部与物流相关的服务抽象成一组产品,让产品替代人力完成供应商的接入需求。

这时候,产品和技术同学可能抽象了一组物流的自动接入 API,定义了要交换的数据和相应的交换标准,甚至提供了沙箱环境,为第三方软件服务提供商提供便利。他们甚至可以介入,帮助物流供应商迅速接入。

随着产品和技术能力的进一步提升,技术同学可能会看到更多机会。比如对不同物流提供商的履约能力、履约时效、服务质量、用户满意度等做评分,形成一个供应商的信用系统。这个信用分可以用来控制履约成本,保障履约质量,以及提升供应商的合作意愿。

事实上,这个系统的很多设计都可以抽象出来,提供给物流之外的供应商使用。比如品控的供应商、仓储的供应商、安装维修的供应商等等,这就形成了一套供应商信用管控、供应商管理,以及根据供应商服务能力与成本做成的动态路由的体系。

之后,这个技术体系还可以在多个领域重复使用。那么自顶向下,一个公司的外部适应性就逐渐得到了提升。从最顶层对单个业务场景的直接响应,到下一层多个业务场景对单个产品的抽象,使得该产品和相关技术能够直接服务到多个业务场景。最后,多个产品被架构活动抽象成了一组底层技术产品。而这些技术产品,就可以在多个领域的产品中得到复用,使得多个产品领域和这些产品支持的多个业务领域,都能提升自己的外部适应性。

通过以上分析我们就比较清楚了,架构师需要在技术层面为整个企业的技术体系注入外部适应性,这才是你独立于其他职能所创造的长期价值,是你有底气的自尊的源泉。

那么架构师怎么做才能为企业的技术体系注入最大的外部适应性呢?想逼近这个问题的答案,就必须理解削弱一个技术体系外部适应性的因素都有哪些。

影响技术体系外部适应性的因素有哪些?

我们可以从三个角度来分析。

企业内部压力的影响

先从职能角度来分析。技术之外的同学,比如业务和产品同学,几乎不关注技术体系的外部适应性。一来他们不擅长,二来这也不是他们工作的优先级。遗憾的是,业务线的技术同学,以及与产品密切配合的技术同学,往往也很少关注技术体系的外部适应性。这里面的原因比较复杂,主要有三个。

第一,业务交付时间的压力。技术同学经常受到来自业务和产品同学交付时间的压力,这样一来,技术质量都很难保障,更不用说技术的外部适应性了。

第二,技术岗的供给压力。最近几年技术岗的供给比较缺乏,很多技术同学频繁跳槽,在一家企业的工作时间较短,因而他们在客观上就不太关注自己的技术口碑。

第三,考核的压力。不少企业把技术岗的考核内容、考核周期都与业务线牢牢绑定。而需要长期打磨的技术能力,既不能被关注和度量,也没有资源被孵化。结果就是短期效应非常明显,自然,技术同学就很少关注技术的长期适应性了。

除了团队内部的压力外,企业也面临着不少压力。首先,时间对于所有的职能而言都是稀缺资源,大多数互联网企业都采用了小步快跑的迭代方式,很少有企业是先把问题研究清楚才入场的。大家都是边打边学。不论是业务岗、产品岗,还是技术岗,都是摸着石头过河,这就不可避免地导致所有职能都被自己的认知局限所羁绊。

比如你经常听到技术同学说“产品同学不靠谱,一天到晚改需求”。产品呢,则每天抱怨业务同学从早到晚变方向,朝令夕改。

事实上,这种行为在越是高速增长、竞争激烈的行业越是常见。等你完全看清楚一个行业,新的商业机会早就不在了。

你可以观察下社区团购,在短短半年多的时间里,就有数百亿的投资注入到这个模式之中。等你花半年时间准备好大举进入的时候,不但战局大变,就连监管环境也发生变化了。这个时候,由社区团购这个新模式带来的市场渗透机会就完全不存在了。

这有点儿像打猎,你不可能说:“你别动,让我打死你!”你距离猎物越近,与此同时你失去这个猎物的概率也就越大。

可以说,在时间的压力下,大家都不会在完全看清楚一个市场才行动。因此处在最底层的技术体系,在外部适应性上不太可能有充足的时间和精力去做到完美。

企业外部环境的影响

最常见的削弱一个技术体系外部适应性的外在因素就是竞争。竞争会打乱企业的部署和节奏,迫使企业不得不响应市场环境的变化,而不是有规划有节奏地做自己的业务和产品。

在这种情况下,不但技术体系不能提升外部适应性,甚至连产品和业务也没办法通过自己的方式提升企业的外部适应性。因为竞争会打乱企业的节奏,给企业各个层面带来影响:

有的影响是业务层面的。比如多个企业对流量渠道的竞争,大促和营销力度和时长,履约和服务的人群和地区性优势,等等。

有的影响是产品层面的。比如不同的用户体验和用户心智,不同的产品定位和功能,等等。

也有的影响是技术层面的。比如对长尾设备的覆盖,对创新技术的支持,商业生态、产品技术和 API 的开放性和兼容性,等等。

竞争对手在业务、产品和技术层面的动作,都会迫使企业做出相应的应对动作,很少有企业能我行我素的。

还是用打猎的比方来解释。哪怕你起得再早,准备得再好,总会有其他猎人在那里捣乱。这些猎人哪怕打不到猎物,也会放一枪把猎物吓跑。否则你打到了,他就再也没机会了。

除了竞争外,还有其他环境因素也会影响技术体系的外部适应性。比如用户需求的流行趋势、宏观经济周期、监管环境、资源供给、技术趋势等等,无时无刻不在发生变化,这些也可能导致企业原有的外部适应性的计划失效。

举个宏观经济环境的例子。在大多数风险投资充足的地区,尤其是中国和美国,大多数企业其实并不具备对外部适应性做长期规划的条件。因为一旦某个外部环境的变化被市场感知到,这种变化如果不能被已有玩家高速响应的话,那么资本市场,尤其是风险投资,必然会迅速入场。

就像在国内,很少有明显的机会能够在半年内都没被资本深入挖掘的。往往是机会一旦出现,资本会在一两个月内迅速集结力量做出响应。

企业组织结构的影响

最后一类削弱技术体系的外部适应性的因素,与企业的组织结构有关。不论是业务线研发、产品研发,还是基层技术的研发,这些同学的本能反应,都是先维持自己的生存空间。

另外,因为各个领域的内部目标、具体挑战和资源环境都不相同,所以每个领域的研发人员设计出来的软件架构自然也存在差异。

也就是说,研发人员由于自身认知局限、沟通的局限,或者是为了保护自己团队的利益,导致他们的设计都是局部最优,而不是全局最优。这种局部和全局的冲突,在一个跨团队的大型架构活动中很容易外化出来,导致整体的外部适应性随着组织复杂度的提升而被削弱。

那么你作为一个架构师,就要通过技术抽象为一个企业创造出经得起时间考验的整体设计,从而为企业的整个技术体系注入外部适应性。那么如何做到这一点呢?我们下节课就来讨论这个问题。

小结

这节课我们聊到了一个很重要的话题:你作为独立于其他职能的架构师,可以创造什么价值?有些 leader 认为自己创造的价值就是被自己管理和影响的人的创造的增量价值之和。也就是说,这些 leader 是间接创造价值的。架构师当然可以通过参与架构活动的每个人间接创造价值。 但是在此之外,你要通过为软件系统注入外部适应性而为企业直接创造价值。

我认为架构活动是企业软件进化的一个特殊节点。在这个节点上,所有参与者都在重新审视现有架构体系的不足,然后引入新的设计和技术。在这个过程中,你其实在为企业注入新的技术基因。

从这个视角来说,上帝经由你的手来改变企业这个物种。那么你就要抓住这个机会,运用我们前几个法则中传递的知识:逼近正确的目标、尊重人性、最大化商业价值,以及利用好技术生命周期,然后通过你的架构设计和对架构活动的决策来最大化企业的外部适应性。

免责声明:
1.本站所有内容由本站原创、网络转载、消息撰写、网友投稿等几部分组成。
2.本站原创文字内容若未经特别声明,则遵循协议CC3.0共享协议,转载请务必注明原文链接。
3.本站部分来源于网络转载的文章信息是出于传递更多信息之目的,不意味着赞同其观点。
4.本站所有源码与软件均为原作者提供,仅供学习和研究使用。
5.如您对本网站的相关版权有任何异议,或者认为侵犯了您的合法权益,请及时通知我们处理。
火焰兔 » 法则五:架构师为什么要关注技术体系的外部适应性?