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