郭东白的架构课_13_12法则五如何提升一个架构设计的外部适应性
你好，我是郭东白。
上节课。
我们讲了外部适应性这个概念，也强调了架构师的职责是通过架构活动，为企业不断注入外部适应性，从而帮助企业更好的实现它的战略意图。
那么，该怎么注入外部适应性呢？其实上节课在讲影响技术体系，外部适应性因素，这部分我们就提到了挑战企要来自三个办法，分别是企业内部的压力、企业外部环境以及企业的组织结构。
这三方面的挑战也为我们指引了应对的思路。
那么这节课我们就来讲讲解决办法。
那么先来看怎么解决企业内部压力的这个挑战，企业内部压力的挑战。
具体来说，也有三个，一个是业务交付时间的压力。
二是技术岗供给压力导致技术人员稳定性差，涉及短视。
三是由于考核压力带来的短期效应，先看业务交付时件的压力。
这其实是指在一个高速迭代的业务中，该怎么维持技术体系的外部适应性。
虽然大多数科技公司都会在技术上做比较充足的人员投入，但是业务和产品职能对技术的首要要求往往是在需求实现的时效上，这个态度非常合理，毕竟商业机会稍纵即逝。
那么高速响应机会肯定是每个职能的本能。
所以我们真正要解决的挑战应该是，技术人员怎么在高速响应业务和技术需求的同时，还能保障技术体系的外部适应性。
我们在法则一里讲过，必须依据目标做出正确的取舍。
为什么要做取舍呢？根据我的经验，绝大多数的业务和产品尝试只是一个小尝试，并不是战略性投入。
对于业务尝试响应速度是第一优先级，只要不破坏外部适应性就行了。
不过其中还是有一些挑战的。
首先，我们大都处在一个博弈状态下，比如业务、产品、技术，这三个职能在互相做博弈。
如且每个职能内部也在互相博弈。
在这种情况下，没有任何一个业务、产品和技术人员愿意主动承认自己的需求，是个小尝试。
大多数人都试图找出充足的理由去说服其他人，把自己的需求作为最高优先级。
如果你有比较深度的业务理解，其实很容易对业务尝试和战略投入做出区分。
你甚至可以判断一个需求的商业价值和成功概率究竟有多大。
当然，你也可以跟高层不断沟通，从而确认自己对业务尝试和战略投入的判断。
因为更高层级的决策者，一般对两者是有清晰的区分的对业务务尝试，我们需用最低低的本去完成，并且从这个尝试中得出一个有效的结论。
这种情况下，你要做的就是在保障尝试结论的有效性前提下，最小化这个尝试对系统的冲击。
因为大多数尝试试是不不成功的么？是结论有效性性。
如果把一一个范范围尝尝试放更大范围内，它的价值依然存在，方法依然有效，那么结论就是有效的。
它跟产品的完整性、技术性、可扩展性、安全性、可维护性等等，几乎没有任何冲击。
这意味着你在实现这些需求的时候，可以忽略多数的横向问题，把开发成本降到极致。
这因思结论有效性跟实验环境有非常大的关系。
比如说圈选的尝试，目标人群营销预算，在什么季节做投放等等。
都说属于实验环境，许多算法承诺，许多算法同学都知道，有的团队经常发天花乱坠的战报，还有各种经过严格AB测试后得出的转化增长的结论。
不过，最终这些本来独立的实验很少有累计效，甚至随着时间会逐渐衰减，其中有竞争人群等复杂因素。
不过有一个原因很关键，那就是很多人都试图挑选有利于结果的实验环境来做结论。
所以说那些所谓的成功尝试结论，有效性是要打个折扣的。
从架构设计的角度来说，不过该怎么做呢？我们要把大多数的尝试尽量分钟的一个小的领域内，这个时候多次的业务尝试不会随着时间而导致混乱，不会技术体系的外部性适应性甚减，技术体系的外部适应性。
这个时候有四个架构，原则非常重要。
第一，单一职责原则指的是要把每个业务尝试尽量分装在一个单一模块中，一旦尝试失败，就可以迅速把业务逻辑下线，避免影响整体的复杂性。
我的经验是，业务尝试在百分之九十的情况下都是不符合预期的。
在这种情况下，符合单一职责的设计，很容易下线旧逻辑。
你这么做很重要，你在接受一个烂摊子的时候，肯定恨死那些不下线无效逻辑的前辈们了。
第二，最小依赖原则指的是整体的架构设计，要保障，大多数业务尝试可以在业务层内完成。
如果每个业务方的需求都会侵入到底层的逻辑，那么每次尝试都会变成跨团队的合度，这种架构会大幅降低业务尝试的速度。
第三，最小数据共享原则。
一个正在尝试中的业务，应该尽量减少自己跟其他业务模块的数据交换，尤其是输出，这样才能最小化爆炸半径。
第则，这个业务尝试的数据模型会污染到其他业务，在尝试失败之后，对其他业务的影响也很难剥离。
第四，最小暴露原则指的是在业务尝试期接口不对部门或企业外部暴露，否括API数据共享事件、消息流的一切对外界造成影响的通讯机制。
你可能会说我们公司不一样啊，我们的项目都是基于百分之一百的科学决策，多数项目都是战略级项目。
你们这些原则都是小铺快跑的公司里才会用到的对，我们不适用。
那我给你一个战略级项目的简单判断原则吧。
战略级项目应该在公司层面明示，而且要维持足够长的时间。
所谓足够长，对于阿里、腾讯这样的大厂来说，至少要三年期。
如果你的部门体量小，至少也要一年期。
所以如果你的业务方每月给你一个新战略，那你可以非常确定的告诉自己，这哥们儿分不太清楚业务常识和企业战略，他的需求我还是乖乖的分装，好吧。
华为创始人任正非有一句话可以完美总结这个原则，那就是先开一枪再打一炮。
这就是意味着我们对业务方尝试的技术设计，都应该先开一枪，尽量最小化变更范围迟到。
拿到一个结果，让我们非常笃定，这个技术项目可以上升成战略级项目了，才能改变做法。
顺便说我认为华为的成功跟这个原则有非常大的关系。
你如果能够准确区分业务尝试和战略投入，也学会了这些业务尝试的分装方法。
那么对于战略投入可以用同样的方法吗？不是的，你如果真的碰到了三年一遇的战略转型，方法就不一样了。
这时候你的架构设计会遇到一个很大的不连续性。
这样一来，你的目标不是保障这次变更的最小爆炸半径，而是让战略转型做的尽量彻底甩掉尽可能多的老包袱，让未来的企业变得更灵活。
分析到这里，你就明白为什么我们要区分业务尝试和战略转型项目了。
因为场景不同，架构原则也完全不同。
其实区分业务尝试和战略转型项目，还有一个很简单的办法，你可以问问业务方，你是想让我尽快上线呢，还是让我花大量精力准备好一次战略大进攻呢？我相信百分之九十的情况下，你得到的答案是前者。
也就是说大多数时候保护技术体系长期的外部适应性跟实现当下的需求一样重要。
接下来我们看看技术岗供给压力这个问题，这呢会导致技术人员稳定性差以及设计短时。
那么作为架构师，你可以这么做。
第一，提升对分装能力重要性的认知。
你要帮助每个技术同学认识到，他们都要有有效分装业务尝试的能力，而这个能力最终会转化为你提升技术外部适应性的能力。
这是一个技术人员的基本功。
从你写代码的第一天的能力，只不过随的职业的发展，你从分装代码逻辑到了分装业务逻辑，最后到了分装业务尝试。
如果是一个程序员，在日常工作中忽略了这方面的能力训练，我觉得是一个不明智的选择。
这是建设复杂度控制机制。
业务尝试呢也要有设计评审。
而评审的一个固定环节，就应该是逻辑数据以及接口的最小爆炸半径设计。
第三，推行最小必要的架构原则。
比如，在公司范围内推行奥卡姆、提刀原则，任何增加功能，引入复杂性的设计都要做一个正式评审。
不过简化的行为就不需要了。
接下来再看一下短期效应这个问题。
短期效应这种挑战它的根因在于公司的激励机制不够合理，这是制度上的问题，要靠改变公司的制度来修复才行。
架构师其实没有真正有效的抓手。
我见到比较好的办法是把绩效考核仅仅跟业务结果绑定，而把技术性的晋升跟长期的技术体系建设绑定。
阿里在这一点做的非常不错，尤其是p八p九层级的晋升比较看重这一点。
我觉得大多数公司都可以借鉴。
如果你所在的企业没有做到这一点，那你可以向CTO建议在晋升中加入跟技术体系建设相关的考核，也可以建议逐渐增加这个考核维度的占比。
比如从百分之十逐渐提升到百分之三十甚至是百分之五十。
到这里，第一类挑战的解决办法就讲完了。
不过刚才我们提到了业务理解这个话题，这是技术人员所严重缺乏的一个技能。
所以我会再花些时间为你着重讲解一下你需要比较深的业务理解，才能辨别一个需求的战略价值。
这和我们上节课提到的一个互联网现象有关。
在时间的压力下，业务产品和技术人员都不会在完全看清楚市场之后才行动。
所以处在最底层的技术体系，在外部适应性上，就不太可能有充足的时间和精力去做到完美。
这个时候就需要技术同学有深度的业务理解，才能保障技术体系的长期外部适应性。
业务理解这个概念到处都是我经常看到技术同学晋升的时候，展示自己的业务理解，就是把自己的团队的业务再讲一遍，这个重复一个业务leader宣讲的内容。
甚至有些同学的PPT还是从业务团队要过来的这跟真正的业务理解有天壤之别。
我们接下来就看看什么是真正的业务理解。
我在文稿里放了一张图，可以看一下。
同时未来再解释一下。
在一个互联网企业，特别是小公司，业务、产品、技术同学需要一起去认知行业、市场和竞争等外部环节。
这意味着每个职能的认知是同步的，是平行迭代的，是没有偏差的。
只不过你作为一个技术人员，要从技术视角去理解业务，并且把业务的认知转化成一个技术动作。
而这个技术动作最终会和业务动作、产品动作一起，把企业带到一个更好的生存位置上。
这才是真正的业务理解，也是你独立于其他职能所创造出来的长期价值。
你会发现，这是你通过了解外部环境而获得的第一手的业务认知，而不是你从业务产品同学那里获得的二手三手的认知。
在某种程度上来说，这是多个职能在做分布式的学习。
在学习的过程中，你只是一个技术锤子，你用技术的视角理解业务。
这个钉子你不仅要看懂业务人员做业务，产品，人员做产品，还要看出门道，最好能够提出建议以及预测一个结果，这才是你的业务理解。
总结来说，一个架构师要拥有业务理解的能力，是基于自己对业务深度认知之后的技术洞察，然后通过这个技术洞察来推动业务发展。
拥有了技术洞察之后，你甚至从业务视角上看业务机会，或者从产品视角上看到产品机会。
再进一步。
你的技术洞察可以为业务和产品赋能，最终三个职能合力，推动企业的发展，而不是三个职能单打独斗。
另外，技术视角和动作也不止一种，对架构师来说，就是架构抽象和架构设计。
对数据工程师来言，就是数据建模和数据资产建设。
对算法工程师而言，就是建模和算法调优。
这些技术动作最终都会作用到业务层面上，从而创造出增长和新的业务机会。
讲了这么多，我们看个案例，就用上节课提到的物流的例子来具化一下技术动作吧。
假设你通过架构抽象定义了物流服务供应商这样的概念，那么你对供应商的能力就可以进一步的抽象和量化。
比如说你抽象出了四个维度，第一个维度是容量，指的是某供应商对某个类型的服务能提供的最大服务容量。
这是一组跟业务场景相关的度量。
第二呢是价格曲线，指的是这个供应商的服务价格。
随着服务容量变化的关系。
第三个维度是质量曲线，指的是这个供应商的服务质量，有了服务容量变化的关系。
那第四个呢是最小容量，指的是这个供应商维持商务关系所要保持的最小服务的容量。
有了这些维度的度量和建模，你就可以设计一个调度引擎，在多个供应商之间做调拨，同时呢最大化服务质量最小化成本。
而有了这个调拨能力，业务的运营也会发生变化。
你可以不断量化和监控服务商的真实服务容量，还有服务质量曲量。
同时呢你可以对价格和质量曲线的预测做出调整。
而业务方呢也可以通过自主监控和对业务未来走势的预测决定，是不是要对现有的供应商做出调整。
一旦有了这些数字业务方就可以有新的运营方法。
比如说通过最低容量保障去刺激某个供应商，来扩大自己的服务容量，或者提升他们的服务质量承诺，甚至可以把某些质量监控直接返回给供应商，让供应商主动响应质量分的反馈。
更进一步的业务方呢可以开始度量和管理供应商的可运营度。
也就是说，当业务方用一组规则驱动一个供应商做出容量或者质量改变的时候，这个供应商响应这些规则的能力和时间延迟也可以被度量出来。
最后，这些度量就可以转化成一个数字化的可运营度的指标。
未来可以用来筛选那些有潜力的运营商。
这种数字化的运营方式，就是技术推动业务发展的一个典型案例。
这时候你可能要挑战我了，你是怎么一下子找到这四个维度呢？他们充分且必要吗？而且这些维度到了的新行业还是不是有效呢？其实答案很简单，这就像你写代码的时候，做类和接口的设计一样。
这是一个循环迭代的认知提升的过程。
你做的多了就会看到一些长见的模式，这也是你做架构师的经验所在。
或许你还会问，架构师的首要任务难道不是提升技术实力吗？如果花很多时间来理解业务，那么我的取舍是不是错了？长期这么做，会不会我的技术比不上做技术的业务比不上做业务的。
是的，一个架构师。
当然要以技术实力取胜，但你想在架构师这个职业走得更长远，就必须比别人付出更多的努力下更大的功夫，提升自己对业务的理解。
这是一个内卷的时代。
你除了卷技术，还可以主动卷一下业务理解。
啊，接下来呢我们看第二类挑战。
具体来说就是在一个充分竞争的行业，大多数企业并不具备对外部适应性做长期规划的条件。
针对这种情况，架构是该怎么应对呢？解法呢？其实跟我们前面讲的业务理解的过程相类似，以不过这里更侧重于站在业务运营产品和技术的条件不断的监控和思考竞争对手，然后用技术手段做出应对方案。
先举一个利用技术来竞争的正面例子。
在电商竞争中，最常见的就是对新买家的争夺，而新买家的常见行为就是比价。
以至于有的电商平台会专门建设新人专区，通过打折的方式来提升他们对平台价格竞争力的认可度。
这里就有很多的技术视角的创新机会了。
比如说你可以设计一个竞争对手，商品价格监控网络，确保自家专区的商品定价低于竞争对手。
而这个监控能力又会衍生出大量的新技术机会，向商家识别、商品识别商品的SKU的建模、商品主数据、同款识别、图文相似性和数价计算、竞争价格趋势分析等等。
有的领域甚至复杂到需要多个博士学位的研发人员而发展，衍生出一些对抗能力。
再举一个非正面竞争的例子，你可以开发风控能力来对付费流量和新人做出识别，防止老买家和黑客团伙反复注册来薅羊毛。
这里的风控能力又可以拓展到多个技术方向。
比如说通过深度学习来发现新的风控方向，这就是一个现在比较热门的创新方向。
再想风控呢可能跟竞争没啥关系，但是风控就像一个财主家的高墙，再果你的墙就是个木篱笆，一推就倒，那么贼就会蜂拥而至。
而和你形成竞争的躲在砖墙后面的老财主就平安无事。
也就是说，打磨风控技术能够提升一个企业的相对竞争力。
最终会帮助企业提升百部适应性。
这两个例子的应用方向呢看起来很窄，似乎呢每个领域都要花不少时间和人力来搭建。
从我个人的经验来看，这属于一个比较正常的现象。
一个竞争对手的出招，如果靠一两个成熟技术就能应对，那么这个竞争对手也不高明，估计很快就会被淘汰。
真正高手出招之前，肯定是经过了深思熟虑的，会防止被你一步绝杀。
所以说，商业竞争是一个持续对抗的过程，深度理解市场竞争环境。
还有另外一层含杀会可以帮助你认识到技术驱动业务的天花板，避免过分乐观。
为什么呢？因为很多商业上的对抗属于消耗战，不可能无限期的打到底。
这就意味着很多技术动作带来的业务价值并不能做大尺度的外延。
这意味着你利用技术招数挖掘市场竞争中的机会其实是有限的。
我们还是用物流来举个例子。
假设呢几个物流供应商在进行充分的竞争，他们都有自己的冗余运力，都需要用更便宜的竞价来获取额外的订单，扩大自己的规模和市场份额。
在这个假设下，物流调拨系统可以在多个供应商之间肆意挑起，并且放大价格战，从外最大化。
你作为甲方的利益，但事实上不是任何一个市场都是充分竞争的。
供应商呢仅仅会在一段时间内通过烧钱来争夺市场份额。
如果长时间亏钱，供应商呢也撑不住。
另外供应商也不是随便受你摆布的。
如果你在供应商之间做调拨游戏，而你的竞争对手却采用了完全不同的策略。
比如说保底单量资金注入股权交易，或者跟供应商形成了商业伙伴关系，然后换取长期的有保障的深度和做。
那么你的策略就不奏效了。
可以说，供应商路由这样的技术手段仅仅在某段时间某个地区发生充分竞争的时候才有效。
如果天时不对，比如你发明路由算法的时间竞争格局一定，那么头部玩家根本不会和你做动态竞价，哪怕做动态竞价，吃亏的也是你。
所以你一定要多和业务同学讨论，尤其是单凭技术视角做大尺度外延的时候，你一定要论证有效性。
最后一类挑战呢就是研发人员的人性以及企业的组织结构。
人性这一块，我们在法则二已经深入探讨过了企业组织结构这个话题，它和既企业的文化环境有很大关系。
我们接下来会在法则六中做深入探讨。
今天的内容就是这些信息量比较大我在文稿里放了一张思维导图，你可以看一下，帮助你理解消化。
总结来说，作为一个架构师，处在一个主动的位置上，是可以做一件很了不起的事情的那就是为企业注入技术基因来帮助他长期生存。
那么你可以怎么做呢？首先你要有意识主动思考，注入外部适应性这件事情。
这个思考呢会引导你做具有清晰业务价值的技术创新，从而为企业创造出经得起时间考验的架构设计，提供更持久的外部适应性。
而能做好这一点的前提，就是要深度理解业务，在这个基础上寻找价值点。
当然，这里还有一个大前提，就是你需要深厚的技术实力来帮助你最大化价值的挖掘。
不过，因为竞争和市场的作用，哪怕是逻辑上再完美的尝试，最终往往仅在短时间内有效。
也就是说，你对一个行业的理解是必须持续提升，而且你的创新也不能停止。
另外就是外部适应性，最终是一个循环往复的认知迭代过程，同时也是一个试错过程，要靠尝试、靠创新。
而不是靠祖传的招数。
因为你每一步尝试都在消耗企业的资金成本、时间成本、人力成本以及心力。
这就回到了我们法则。
三中所讲的最大化LI的决策过程。
所以你看这些法则呢，其实不是孤立的，而是互相关联的。
当然在第二个模块中，我还会分享一些具体的招数，来帮助你提升这个成功的概率。
最后呢是我们的思考题环节依然是三道题。
第一，你所在的企业或者是行业，由技术带来的外部适应性的场景是什么？请你解释一下具体的场景技术手段带来的价值，以及维持这个价值创造的方法。
第二，我刚才提到了物流供应商这个失败案例。
虽然技术创新的逻辑非常清晰，但某些假设却在商业环境的动态变化中失效了。
除此之外，你还借过其他的类似案例吗？为什么会是这样呢？第三，在小范围的尝试上，也就是先放一枪再开一炮的方法。
你有成功的案例可以分享吗？在这个过程中，你在技术上可以做些什么？把提高成功的概率呢？如果今天这节课对你有帮助，欢迎你点击课程右上角的分享按钮，把课程转发给你的同事，或者是朋友，大家一起交流进步。
我们下节课再见。