郭东白的架构课_04_03法则一如何找到唯一且正确的架构目标
你好，我是郭东白。
上节课我们讲了目标，在架构规划的重要性，也明确了目标缺失的两大根因。
那么这节课我们就来聊聊怎么寻找正确的架构目标，以及如果目标制定错误，该怎么挽回。
我们先来讨论第一个问题，怎么寻找正确的架构目标，我会分三种情况来讨论第一种情况，确认一个正确的目标，然后试图逼近它。
一般来说，我们相信达尔文的进化论是普遍使用的，那么企业的所有活动都应该指向一个终极目标。
那就是他要能够为企业带来长期的生存优势架构活动，作为企业活动的一种，自然也逃不出这个终极目标的五指山。
但是这个终极目标太难验证了，怎么知道我们的架构设计会对公司产生什么深远的影响呢？我不就设计一个五十人日的评价体系或者是流量归因服务嘛，我不至于还要在架构设计文档里评估对企业的生存优势吧。
再说了，就算我想做，也不知道怎么评估啊，你肯定会有这么一串疑问，而标准答案是什么？其实我也不知道。
不过在做架构设计之前，我永远会问自己这样一个问题，这个架构规划为什么可以给企业带来生存优势？对这个问题的回答，其实渗透了你对几个价值创造维度的理解。
他们是第一，促进企业规模化。
第二，加速企业模式，探索。
第三，提升企业效率。
第四，提升用户体验。
当然，最理想的情况下，你还应该把一系列可以量化的指标作为架构方案的预期产出。
然后你就可以用评分卡的方式，对架构方案有个全局的产出度量。
当然，在现实中，这种产出很难量化到这些目业务目标上，尤其是技术主导的项目，比如说数据模型、标准化、网关统一，架构升级就更难了。
那么对这个项目必要性的论证，就需要有更直接的量化工具。
就像我做CTO,如果我去赞助一个项目，我一般期望项目在半年内的回报要大于投入。
也就是说你投入一百人日做一个技术项目，那么你半年内就要审出一百个人日来否非有其他的动力因素存在，比如说审计、合规、安全等等。
否则我就不能做这个项目的赞助了。
很明显未来充满不确定性，这个最大化生存的终极目标很难验证。
不过通过反复问自己这个问题，我们就可以逼近这个目标，就像人生意义这种终极问题一样，很多哲学家也没办法给出一个确定答案。
但是正是对这个问题的讨论，让我们一直在逼近真理的路上。
另外如果你留心的话，你会发现很少有人会在架构设计中讨论这个问题，而这恰恰就是架构设计的万恶之源。
事实上，在中国的互联网行业，架构师往往不是在两个最大化生存优势的选项之间做选择。
更多时候，你是在一个不能带来太多优势和一个甚至会带来劣势的画蛇添足的方案中间去做选择。
为什么我特别强调中国的互联网行业呢？因为在过去十年，中国的互联网公司有比全球任何目家更多的资金和人才供给，甚至是共大于虚的。
我们有千团大战、共享经济大战、新零售大战、社区团购大战，几乎每个流行词的背后，都是不惜一切代价的资金和人才投入。
在这种背景下，许多架构设计都是以饱和攻击的方式，全方位最大化投入的。
或许参战各方都在想，先想尽一切办法活到明天再说。
但当我们去研究各个大战的最后胜出者，就会发现，他们都不是靠全程饱和攻给取胜的。
他们是靠对阶段性精确目标的最大化投入。
而在惨烈竞争中，胜出的架构其实也是一模一样。
那么你作为一个架构师，怎么判断一个目标是不是正确呢？我的建议有这么三个，首先要用企业的战略意图去鉴定架构目标的正确性。
接着，如果目标与战略意图不匹配，那么你试着影响甚至改变这个目标。
你可以跟架构项目的发起人反复沟通，陈述你的理由，建议他去寻找另外一个更接近战略意图的目标。
最后，如果目标与战略意图相匹配，那你要看看是不是存在一个更合理的目标，可以让企业能够更快逼近战略意图。
如果你能保持这么做，哪怕你不知道终极目标，你也已经在不断逼近了。
而且能做到这一点，你就已经超越大多数架构师了。
因为你在不断检验目标的过程，也是你判断你在不断提升的过程。
不过这里有两个关键问题，第一，什么才叫匹配呢？第二，我该用什么样的标准来衡量匹配度呢？我认为一个架构、目标和战略意图相匹配，指的是架构活动。
如果对一组KPI有贡献的话，那么这组KPI就和表达战略意图的KPI形成增强关系。
简单来说就是你的KPI对战略意图有战向贡献。
举个例子，大多数公司的战略力都对客户第一有某种形式的表达。
假设你的架构活动有一个作用是提升性，比如说减少用户交互过程中的延迟和等待。
那么你的架构活动在这一点上对战略意图的贡献是正向的。
反过来，假设你的架构活动需要用户做强制的安全身份验证，那么用户的正常活动往往被打断。
这时候你的架构对战略意图的贡献就是负向的。
第二，如果我们发现目标不正确，该怎么办呢？一般来说，一个架构活动的发起往果有比较充分的论证，那么他的目标往往是正确的，但你肯定会遇到目标不正确的架构活动。
这个时候你作为一个架构师，就义务指出来了。
不过很多架构师在这个时候却是萎缩的。
因为在一个架构活动中，架构师的角色往往要低于赞助者或者是技术资源提供方的角色。
甚至对你来说，好不容易拿到了这个机会，哪怕方向错了，也要硬着头皮冲上去。
在这种情况下，我期望你有良知，也要有勇气去阻止企业犯错。
我自己曾经因为三次阻止一个顶级项目，在职业发展中受到了不小的伤害。
但也正是因为我这么做了也让我能够从容的面对自己的良心。
更重要的是，之后的事实证明，我的判断是对的这让我对自己的决策自信心得到了很大的提升。
这也就是决策自信心是一个架构师从架构活动中获得的最宝贵的礼心。
在多个比你自身并且比你权力更大的人的面前，你坚持了与他人不同的正确的判断。
当然，多数时候不是对和错的判断，而是判断架构目标是不是最优。
那么在这种情况下，该作为一个架构下，该怎么影响架构目标呢？我们接下来就从技术和业务两个维度来分析。
我们先来看关于技术驱动的目标。
技术人员往往缺少全局视角。
这种情况下，你可以通过引导的方式帮他找到一个更好的方案，让他从战略角度去思考一个架构方案。
对公司的终极价值，最终要找到能够最大化公司长期价值并且成本合理可控的情形。
我们先讲讲上节课提到的，在公司引入新技术方案的情形。
在公司引入新技术，虽然偶尔有个人利益驱动的情形，不过大多数研发人员还是有非常积极正面的出发点的。
在这种情况下，你首先做的不是全盘否定，而是站在他的视角看到。
并且理解他的出发点的正确部分。
接着在彻底理解新方案的价值之后，你就可以比较客观的思考这么六个问题。
第一，新方案的实现成本有多少？第二，新方案上线后带来的短期价值有多大？第三，这个新方案是不是可以全面替代现有方案？第四，全面替代的实施成本有多么？第五，全面替代之后，这个新方案带来的长期价值是什么？第六，如果不能全面替代，而是两套方案并存，那么增量的维护成本有多大？事实上，大多数人看一个新方案，只是思考了前两个问题，然后就匆忙的做了判断。
要知道，这完全不能让建议者看到他的这个方案在全局上的影响。
毕竟，许多方案根本不具备全面替代性或者全面替代的，实施成本太大，根本没法完成。
一旦新方案被通过，虽然能暂时提升局部的效率，但是该长远来看还是会损失整体架构的合理性。
但如果拿出方案可以完整的回答这六个问题，那就值得你去长期规划并认真投入了。
就拿我们上节课提到的引入抛洒的案例来说，要在公司里全面替代卡夫卡的成本很大，短期内回报完全不合理。
所以提出这个方案的同学最后也觉得不合适。
除此之外，在实际工作中，我们更需要考虑的问题是，对于不具备长期价值的项目，我们该怎么拒绝，并且还不伤害建议者的积极性。
但面的四个问题这时候就要发挥作用了。
你可以引导建议者去思考替代方案的实施成本。
你也可以帮助他寻找这些问题的最优答案，让他理解你做出决策的出发点和正确性。
我们甚至可以把最困难的事情交给他。
比如说让他去负责调研，全面替代的成本，这样他才能从你的视角看到问题，从而得出跟你相同的判断。
这样一来，不仅他的判断力可以得到成长，你也可以多一个榜首，而不是对立者。
所以你看，哪怕我们做出了正确的决策，但考虑到人才的成长和团队稳定性，在执行过程中也要关注研发同学的心理感受。
顺便说一句，这个案例也适用于调和局部架构和全局架构的冲突。
总结一下，通过这个案例，我想强调的是，关于架构目标的决策，对于一个人或者团队的影响都是巨大的。
当我们有了一个正确的关于架构目标的决策，我们只是有了一个起点，我们还要认真思考这个决策的实施路径。
最终我们要大家团结在正确的架构目标上，而不是自己一个人举着架构目标变成孤家寡人。
现在我们谈另一种情况，业务目标太多或者不明确导致架构活动目标缺失的话，你该怎么办？作为架构师，在业务目标确定上，我们往往没有最终话语权。
那么这个时候我们面临的问题就变成了在没有权利改变业务目标的情况下，该怎么做才能最大化公司的生存呢？我们先看一个比较棘手的案例，假设碰到上节课讲的业务方大搞运动的情形，作为架构师应该怎么办呢？这里我要引入两个概念，决策权和取舍权。
决策权决定要什么，取舍权，决定保留什么。
一个决策者必须要行使自己的取舍权，在自己的决策领域内做取舍。
那种天天喊着，既要也要还要的人，其实就是不知道客户要什么。
他们使用了自己的决策权，做了全部都要的决定。
但是他们放弃了自己的取舍，权用全方位的搜索，来代替自己的思考，无能。
做技术管理，做产品，做业务都一样，我们必须要有，且仅有一个明确的目标。
这里我强调一下，我们不是说一个项目不能同时优化多个KPI,可以的。
但如果这么做，你必须要给出权重。
比如说做电商，可以同时优化GMV和成交客户的满意度，那么决策者就需要在这两个目标之间给出一个权重，做联合的多目标优化。
这么做的本质，其实是把两个KPI合成一个最大化高满意度的GMV.这个时候其实你还是只有一个明确的目标。
事实上，取舍权是一个决策者最重要的权限，这个权利决定了别人说既要也要还要的目标，到底哪个必须要，哪个可以先舍弃。
不幸的是，这个权限却经常不明不白的被下放了。
原因在于决策者不是在目标上做取舍，而是选择向团队做无度的索求，制定一个又一个的目标。
但是呢无度的索求是不可能被完全满足的这就导致取舍权被分散给了执行者。
举例来说，假设决策者要求三天内上线一个新的商业模式，这种情况下，团队肯定会给你上线一个商业模式。
但究竟是不是你想象中的商业模式，那很难说。
至于稳定性就更不用提了，因为决策者完全没有给团队留出做稳定变更的。
可能。
我特别要强调一下，这里所说的决策者不一定是顶层管理者，那是任何一个层级上能够做决策的人。
这意味着在你的决策范围内，如果你不做取舍，那么你就只能让别人来替你做。
很显然，在充分竞争环境下胜出的公司，几乎没有任何一个是通过大范围的收缩商业模式去寻找增长的，战术上的勤劳，永远也没办法补救战略上的错误。
这里面有非常多的经典商业案例，比如说柯达deck, some michael systems都是由于战略错误，导致公司最终被淘汰。
很遗憾放弃决策权。
在一个企业里可以说是每时每刻都在发生态遗我，我能做做是是么呢？很少有有事事情，你可以做注意，这是一个fail over的过程。
首先我办法反馈这个情形，耐心解释给当初的决策者，请他来做取舍。
这个本来是第一步，也应该是你唯一的一步。
但是就像有四壁，老王说的，你永远也不不行装退的人。
所以这个办法往往不管用。
其次，你自己做个取舍优先级，想办法通知到决策者，你可以用评分卡模型对项目的优先级做个判断。
如果你自己不确定，也可以邀请资深的同学给项目打分。
不过注意要排除掉跟他利益相关的项目，通过这个方式，你应该能做出相对正确的取舍了。
另外我想强调一下，通知是个非常有挑战的事情，我就见到过坚决不接受取舍的CEO.但是哪怕这样的CEO,他一般也会接受你给他的上限顺序。
那么接下来的是，如果刚才说的这两个方法都不管用，该怎么办呢？这个时候，你可以尝试自己拿下取舍权，你需要清晰的表达自己取舍背后的思考逻辑，并邀请相关利益方参与辩论。
如果他们的输入合理，该可以调整取舍，如果输入不合理，那你可以选择拒绝他们的要求。
当然这么做有个前提条件，就是你与真正的决策者之间有足够的信任，并且你也有足够的资深每果不是的话，那么你这么做可能会受到惩罚，尤其在最终业务结果不理想的情况下，最后也是最常出现的情况。
如果上面三种方法你都试了，但是依然失败了。
这个时候你可以通过技术手段来延迟或者隔离决策，这个方法对业务目标不明确的场景也同样适用。
比如说你可以采用类似设计模式中的策略模式，把一个或者多个业务尝试隔离在策略实现中。
每次尝试对主流程都不产生影响，每个尝试逻辑都分装在单个策略中。
这样一来，业务尝试失败之后，你就可以迅速下线策略，而主流程的架构就可以保持整洁，这是一个最小化爆炸半径的方案。
关于寻找正确的架构目标的问题，我们就讨论在这里。
最后我还想再分享一种比较极端的情况，就是说企业有一个非常明确的目标，就且跟公司的战略意图相匹配。
但是对于企业线下的发展情况来说，目标太超前没法实现。
这种情况下，说明公司对一个领域的技术价值判断是正确的。
如果能够实现出来，肯定会给企业带来巨大的生存优势。
但这也意味着企业将面临巨大的挑战。
那么我们作为架构师该怎么办呢？举个我自己见到过的例子，两零一零年我在微软美国参与了一个医疗领域的大数据智能产品的开发工作。
技术方案提出是基于这样一个想法，就是大量语义化的、实时的、来自不同部门的医疗图像和文本数据。
在同一个地方实时聚合之后，会帮助科研人员和管理者发现之前被忽视的创新和绩效机会。
这个论断是成立的，而且被证实又成功案例，当时的产品和技术架构却是失败的。
后来公司被卖给了g翼，多年后又卖给了另外一家公司。
你可能想说，你是不是在劝我遇到这种情况应该放弃呢？我不是这个意思。
如果你喜欢研究初创企业的成功故事，你会发现很多企业就是在这种战略意图和自身能力极不匹配的情况下，一点点成长起来的。
就像这种情形，当时公司的战略路径完全正确，那么哪怕烧钱慢一点，最初的团队也可以完全坚持到现在。
而如果他们真的坚持到现在公司使用的关键技术，大数据、人工智能实时处理的一已经非常成熟，这十几年的行业积累肯定也会带来非常大的竞争优势。
所以在这种情况下，你可能改变世界，也可能一败涂地。
我没办法给你一个坚持还是放弃的建议。
如果你相信这家公司的使命，那你就坚持下去。
如果你不相信，你也可以毅然决然的离开这个医疗项目，对我的架构决策还产生了另外一个重要的影响。
那就是让我意识到，无论在什么时候都要有勇气去做正确的架构决策。
为什么这么说呢？我想你在做架构设计和技术选型的时候，你肯定想不到人命关天这四个字。
但是这个医疗项目让我意识到了一个架构师，必须要有良知，因为一个普通软件的决策可能会关系到一个人的生命。
美国的医疗行业比较喜欢拥抱新技术，但美国医疗行业又是各个科室完全独立采购，任何软件，完全由医生说了算。
所以一个大医院的CIO根本没有什么话语权。
想想看，一个相当于我们国内三甲医院大小的地方，就可能有近百套不同的系统。
这么多完全封闭的系统，其实把病人的档案信息都碎片化了。
这样一来，就连发现病人药物反应这么简单的应用，都需要投入大量的病人的人力才能保证上限。
从某种角度来说，这些部门到处都是局部最优的医疗软件选型决策。
但是从整体来看，得到的却是适得其反的效果。
这些部门医疗软件的错误选型，其实等同于杀人，让本来技术相对容易实现的实时药物反应，报警成了一个几乎不可逾越的技术障碍。
你可以查一下学术报道。
二零一八年，美国统计直接因为药物反应的致死率在所有死亡病人的百分之零点三限。
而在急救场景下更是高达百分之十。
我们所在的领域可能没有美国医疗这么极端，但更常见的情况下，就是我们作为架构师，天天执着于灭火，头疼医头，脚疼医脚，忘了去追逐公司战略层面的正确目标。
你肯定听说过这样的例子，一次黑客攻击领导认为安全不够，要求团队三天内解决问题。
团队发现，唯一能在三天内实现的方案就是提升登录注册的身份验证安全等级。
于是团队三下五除二上线了复杂的风控和身份验证方案。
安全问题虽然在三天内解决了，但是紧跟着新用户的注册成功率下降了百分之五。
假设你这么做了，虽然你不是在杀人，你其实在杀公司，你只是基建的执行任务。
你的决策并没有把公司带到离目标更近的地方。
反过来，你在间接的浪费着你周围的人的心力和生命，甚至更有极端的就是故意迎合领导，主动支持错误决策的架构师。
我唯一的建议就是远离这种架构师以及任用他的人。
因为他们是站着研发人员的人血馒头保护的人。
好了，今天的内容就是这些。
最后我来总结一下，所以到了这里，我不得不重复重申一遍。
今天讲的架构生存法则架构师必须保障整个架构活动有且仅有一个正确的目标，并且这个目标必须和公司的战略意图相匹配。
这是架构活动的起点，也是甄别架构方案的主要输入架构师，有义务影响和干预这个目标，以确保目标本身的正确性。
如果这个原则能起什么作用的话，我想就是在你最需要勇气的时候，帮助你，让你能够找到现有方案的弱点，让你看到这个目标和公司大目标不匹配的地方，让你有勇气站起来，敢讲真话。
你讲真话的时候，不是你在反对你的上级，而是你在用一个架构原则来来判断另外一个人的决策质量。
最后是我们的思考题环节，三个题目选择你最有共鸣的一个回答。
第一题，你有没有参与设计过看起来不太合理的架构方案呢？请回想一下，你当时有没有思考过为企业创造生存优势这个问题呢？可以分享一下你设计这个架构方案的过程吗？第二题，你有没有做过一个能为企业带来生存优势的技术项目呢？是成功了还是失败呢？成功和失败的核心因素是什么呢？第三题，你有没有成功劝阻过一个目标错误的架构项目呢？结果是什么呢？欢迎你把你的思考和想法分享到留言区，我会和你交流。
同时我也会把其中不错的问答置顶供大家学习讨论。
最后我看看了一下，这几天大家在留言区的评论，有同学说提到这个课是不是到了哲学层面？针对这个问题，我简单回复一下。
在课程中，我们的确会讨论一些架构哲学。
你可能会觉得我们不一定能驾驭得了哲学层面的内容。
你也可能会疑惑，课程里是否能找到正确的答案。
事实上我没有答案，我只有问题，以及我对这些问题的思考和我的一些观点。
在之后的不断学习中，你会逐渐感受到，我大多时候不是想给你灌输一个答案，是想和你讨论一个问题。
如果说我的问题问对了，就已经是个非常不错的开始。
如果我们探讨答案的过程，让你有深度的思考，那么课程目标也就达到了。
因为你一步步走过来，会发现，对你探讨成功最有帮助的不是答案，而是探索答案的能力，耐心心和勇气。