02 法则一：为什么有些架构活动会没有正确的目标？
你好，我是郭东白。今天这节课，我们就正式开始架构师生存法则的学习。
你肯定看到过这样的观点：架构设计就是一个迭代的过程，我们要不断发现并且补偿现阶段软件设计的不完美，然后通过各种手段打补丁升级。因此，架构设计永远都是螺旋上升的，没有也不需要目标的指引。
也有人认为定义目标并不是架构师的职责。毕竟目标是架构活动的一个输入，由需求发起方设定，不受架构师控制，所以架构师能做的就是想办法满足这个目标。
然而我要强调的是，在每个架构规划启动之前，应该有且仅有一个正确的目标，这是架构设计的起点。目标不正确，你和你的团队再努力都没办法成功。目标的重要性，就在于它能够一直引导我们走在正确的方向上，同时帮助我们做取舍，在多个备选架构方案中作出最优的选择。
这正是我要讲的架构师的第一条生存法则：所有的架构规划必须有且只有一个正确的目标，而且它必须与公司的战略意图相匹配，这是你架构设计的起点。否则，系统就会变得复杂和无序，缺少结构性。
架构活动为什么需要目标？
你可能不太相信为什么架构活动会没有一个正确的目标。这样的案例在现实中有很多，我来分享其中一个。
我们公司目前大多使用Kafka来做架构，但有一位架构师认为开源社区里正流行的Pulsar的设计理念与云原生趋势十分契合，值得在全公司推广。于是他经过多方调研，搭建了一套系统预研，并针对一些小场景做了测试。测试结果很让人满意，他便整理了一套PPT来找我做汇报。
他的PPT写得非常好，无论是Pulsar的设计亮点还是对我们公司的迁移场景，思考得都很全面，我从中也收获不少。但当我问他：“你这么做的目标是什么？”，他显然没有料到我会问这样一个问题，所以在沉默了一阵子之后才说：“技术先进性？”
事实上，在一个企业里，技术先进性很少会是一个架构活动的正确目标，所以很多人做架构升级都只是为了做而做。
从我过去二十多年的架构经验来看，一半以上的架构活动在发起之前都没有明确的目标。这种架构活动执行到最后，多个协同模块之间必然是一个散乱的结构，如下图所示。
如果在初期就有一个明确的目标，那么做到最后，子模块和初期目标就会是大致对齐的，同时也会最大化对目标的贡献。
目标缺失是由多种原因造成的，刚才我们讲的情形只是其中一种表现。接下来，我就来讲讲目标缺失具体有哪些根因。下节课，再来提供你作为一个架构师的具体应对思路。
目标缺失的两大根因
关于目标缺失的根因，我们可以从技术和业务两个维度来寻找。
技术上：目标缺少全局视角
由于技术原因导致的目标缺失往往有个非常积极正面的出发点：那就是技术同学对于先进技术的强烈好奇心。
很多同学会经常在社区内互相讨论新技术新趋势。当好奇心转变成行动，也就意味着我们已经从一个深受技术理念影响的评价者转变成了追随者。正是这种内在的驱动力，在推动着公司、行业乃至整个社会的技术发展。
探索新技术是一种积极正面的力量，我非常鼓励团队中的同学这么去做。
不过就像我前面提到的案例，从探索新技术变成漫无目的的架构尝试，中间缺失的就是全局思维：架构师没有从全局视角去思考架构活动的回报，以及它对企业整体复杂性的影响。
技术尝试跟业务和产品尝试一样，每一次尝试都是在耗费企业的机会成本。如果是一个正处于创新期和成长期的企业，那么每次尝试还会耗费相关同学的心力。心力是一个极其有限且宝贵的资源，一旦尝试失败，耗尽心力的同学很有可能会选择离开，加剧整个企业心力的损失。
除此之外，每次尝试都会给原有系统注入新的复杂性，从而导致整个系统的复杂和无序，这就是墒增的过程。
看到这儿你可能要问我了，如果我新起一个项目，是不是就可以引入新技术了呢？一个公司当然要引入新技术，不过还是那句话，关键在于要有一个明确的目标，而不是以一种漫无目的、浅尝辄止的态度去做技术尝试。
我曾在一个不到700人的研发团队里，看到过8个自动化BI报表工具、5套UI组件、十多套工作流引擎。对于日常运维、软件升级、安全、合规和审计而言，这简直就是灾难。我相信在这些技术设计之初，从开发同学的视角来看，或多或少都有一些技术先进性的理由。但同时我也可以断定，引入这些技术时很少有人思考过全局复杂性。这就导致整个企业的软件从一个同构的系统迅速衰变成一个混乱无章的大杂烩。
值得注意的是，在这些令人吃惊的数字后面，其实还有一个不太光彩的原因，那就是开发者的个人利益。举个极端的例子，这个团队曾经有个做大数据的负责人，匆忙引入了开源领域的一个新框架，并在会议上作了个演讲。但是讲完之后没多久就提了离职，留下个做了一半的烂尾项目。
也就是说，开发者的个人喜好、技术能力，甚至与其他开发者的关系，也会影响到自己是否会引入一个新系统。
在技术层面上，还有另外一个常见的原因，就是信息沟通不畅。因为层级低的技术同学很少做跨团队跨部门沟通，一些小范围的架构改造也找不到一个官方版本可以借用，而且从头开始的时候，总觉得别人的设计太复杂，有过度设计的嫌疑，所以都是自己去新写一个版本。而一旦业务逐渐增长，小工具长成了大工具，就变成了一个新的变种。
这里我给你分享一个案例。当年微软内部有不少人骂微软的浏览器内核性能差，说某某开源方案很好使。团队后来就请这些持反对声音的人一起去做一个内部项目，请他们在开源的基础上做起，但是要求必须支持所有的测试场景，包括向后兼容的部分。
开始的时候，开源的版本性能是好，但是等杂七杂八的需求全部堆积上去之后，性能反而变差了，没过多久项目就叫停了。
这个案例告诉我们，一方面，做业务和做产品的同学要有正确的取舍，不能见什么功能就要什么功能。
另一方面，我们做技术的同学也不要动不动就认为别人的东西过度设计了，认为我的场景简单，就应该定制自己的技术。往往你的场景简单，仅仅是因为你的业务还没做起来。等业务做大之后，会发现业务根本不是你想象得那么简单。我见到过太多所谓的“极简设计”了, 事实证明，大多数的极简设计，要么早早夭折，要么越做越复杂。到头来还是得用专业版设计进行替换。
总结来说，从技术维度去思考目标缺失的根因，就在于缺少全局视角，主要有三方面的表现：技术同学对于先进技术的强烈好奇心，开发者的个人利益，以及信息沟通不畅。
业务上：目标太多、不明确
比技术原因更常见的是业务原因，主要表现在：目标太多、目标不明确或者是目标摇摆不定。
比如业务leader有一个极具创意的方案，但业务压力大，市场调研的准确度也很难判断，所以多数时间需要靠A/B测试来决定这个方案是否要推广。可以看到，业务同学连需求之间的一致性和相容性都没搞清楚，就把需求一个接一个地转给技术同学。在这种大量A/B测试的背景下，业务逻辑层层累积，系统变得越来越臃肿，老代码谁都不敢删。
还有一种情形在大公司里比较常见。有的CEO喜欢高举高打，上任之后先大搞运动。我曾经见过一个CEO，他在一个季度里同时启动10个项目，目标五花八门。几乎是把整个部门分成了十个子公司，让他们各自为战。在巨大的交付压力之下，团队根本来不及做统一规划，每个项目各自为战，整个季度几乎全员997。
结果呢？3个月后项目完工，业务仍然在原地踏步，CEO挑出个别数据指标上有亮点的项目做了个表彰大会，就万事大吉了。运动虽然失败了。但漫无目的的、随机大撒CEO项目的玩法，却被完美保留下来发扬光大，然后演变成董事长项目、集团项目、BU项目、必保项目等新名目。
这种混乱对技术架构伤害很大，不过倒也不致命，是有技术解的，下节课中我会专门来讲。只是这种行为对团队技术文化的伤害非常大，一般来说，那些追求极客精神和科学决策的同学，往往非常反感这种随机探索的管理方式，所以大都会选择离开。
还有一种情形不太常见，但却极端致命，值得我们重视。那就是一个公司有两个明确的目标，这有点像华山派的剑宗和气宗之争。
举个例子，在一个做电商的公司中，剑宗会认为做业务要像自营一样对整个供应链做强管控，这样会有更好的用户体验，以获取更多的市场份额；气宗则认为道法自然，做业务就要走开放的平台模式，最大化平台的丰富度，由用户选择来淘汰落后的商家。
两派自然是互不服气。如果剑宗上位，公司就大兴剑宗玩法，一切设计都走供应链路线。如果剑宗连续折戟，那么气宗上位，之前的一切设计都推倒重来，全走平台模式。当然，任何时候气宗里都会有喜欢练剑法的，剑宗里面也有运气自如的。但公司内部不论是练气还是练剑，目标从来都不统一，那么在商业竞争中，结果只能是比剑输剑，比气输气。
事实上这种情形根本没有技术解。如果一个公司在战略上不断摇摆，就表明这家公司干脆没有战略意图，那么我更建议你另谋高就。
至此，我们已经把目标缺失的两大根因介绍完了。那么我们该如何应对呢？这正是我们下节课要讨论的内容。
小结
这节课我们讲了架构师的第一条生存法则，那就是每个架构规划启动之前，都应该有且仅有一个正确的目标。而你作为一个架构师，必须要搞清楚架构设计的目标到底是什么。只有找到了这个问题的答案，才能在多个方案中作出正确的取舍。
不幸的是，我们多数的研发需求和架构规划在发起前都没有明确的目标，最常见的就是竞争对手这么做了，要不我们也照搬一下做个A/B试一试？不论是业务产品还是技术尝试，除了耗费大家的心力，还会给原有系统注入新的复杂性，导致整个系统的无序。因此我们需要做架构治理，剔除无序的元素，让系统重新回到结构化的状态。
这也是为什么我一再强调，架构规划必须始于唯一且正确的目标，并且这个目标还应该和公司的战略意图相匹配。
思考题
在每节课的思考题环节，我都会留三道题。建议你任选其中一道作答，目的不是做得全，而是思考得深，让你自己有所得。
- 由于业务压力，我们经常会面临各种各样的重点项目。那么，你是怎么判断一个项目的重要性呢？怎么决定自己思考力的分配呢？注意，这里指的不是你被上级领导分配的写代码的时间，而是你发自内心觉得某件事情很重要，你主动花大量功夫去思考的过程。也就是说，你自主决策的个人注意力分配的算法是什么？
- 你或者你周围人是否曾建造过一个非常精巧的轮子，但是随着时间的推移，变成了诸多要被清理的破轮子？当时发明者有没有意识到这个轮子会增加系统的复杂性呢？为什么？
- 在你参与过的架构活动中，最让你感到兴奋的一个目标是什么呢？为什么？
欢迎你把自己的思考分享在留言区，我会和你交流。
- wesley 👍（27） 💬（3）
以一个普通的员工聊一聊我对项目的重要性问题的看法吧 大致顺序为 系统紧急修复->高优先级业务需求->收益高的技改项目->普通优先级需求->普通系统维护升级 其中，系统紧急修复，例如最近的log4j事件，是无条件全投入的 在无系统紧急修复的情况下，对于高优先级的业务需求，根据投入、收益和分配到的资源决定具体的注意力分配，优先分配给投入少收益大的项目，其次是 投入大收益大分配资源多的项目，这种项目一般为团队中比较重要的项目，这一点主要以公司的整体战略和发展为先 收益高的技改项目排在第二位，注意是收益较高的技改项目，一般公司都会要求在需求之外有额外的贡献，这种技改项目不仅锻炼技术能力，很可能也是你的晋升关键； 普通需求排第四位，这个是本职工作，不出差错即可 最后的是普通的系统维护升级，保证系统的99.999可用，一般都不需要花费太多的注意力，每周固定抽一段时间集中分析处理即可
2021-12-14 - Dom 👍（19） 💬（4）
第一个问题 业务的项目是无穷的，研发的资源是有限的，首先要明确一点是不可能用有限的资源完成无限的需求，必须针对这些项目进行排序优先级，然后再根据优先级来投入资源。 在投入资源的时候，还需要明确行业的趋势及技术趋势，与我们当前的技术能力，这中间是有Gap，需要正面这两者之间的gap，在整个的业务过程中要不断提升技术框架，达到行业水平。 面对业务的项目，我们要从两个角度来完成，分别是现有研发技术框架完成、提升技术框架完成。这两个角度就需要去做平衡，使用60%的研发资源来完成项目，再使用30%的研发资源来提升技术框架，还有10%的研发资源用于团队的技术能力提升。 那如何去判断哪些项目是60%，哪些项目是30%呢？我主要通过两个维度来衡量，分别是【业务价值】和【技术价值】，通过这两个维度去画四象限，把所有的项目划到这四个象限中，对于业务价值低&技术价值低的项目使用外包或者公共服务的方式进行，对于业务价值高&技术价值低的项目使用当前60%的，对于业务价值低&技术价值高的项目使用10%的研发资源，对于业务价值高&技术价值高的项目使用30%的研发资源 第二个问题 轮子的问题需要注意两点，分别是与业务挂钩、固定的迭代周期。技术轮子开始的时候都很好，往后更多的是一个是一个膨胀的系统，无法管理。这个时候需要想办法让整个技术轮子处于可控状态，通过与业务挂钩，能够保证整个技术轮子的资源投入，不会因为员工离职等各种理由中断。二是需要固定的迭代周期，保持技术轮子的活力，控制复杂度，让整个技术轮子形成稳定循环。 第三个问题 通过技术帮助业务成长，这个会让我觉得非常有价值。 回答完这三个问题后，我自己还想到了黄金圈原则，通过why-how-what的方式来思考业务。我们在活动过程中，经常会使用what指导我们做什么，使用how指导我们怎么样做，但是很少去问why的问题，为什么做？或者通过不断的why可以让我们更明确我们的目标到底是什么。
2021-12-23 - ivhong 👍（9） 💬（1）
思考问题二: 我在以往的经历过的团队中，设计并实现过许多精巧的“轮子”，也许我的“轮子”并不是很关键，有些“轮子”直到我离开公司，一直在转，并且几乎没有过二次维护。我分别介绍一下失败的“轮子”和一直运行的“轮子。 1）失败的“轮子”： 当时在游戏团队，为了提高玩家体验，要做一个兑换码系统，需要批量生成和核销，在接到任务的时候，只有一个需求：一个兑换码只能使用一次。当时我技术老大跟我说，虽说现在需求只有一个，但是未来，我们可能用到一个兑换码可以使用多次，或者一个兑换码可以被不同的人使用多次的情况，你要好好考虑一下哦！于是我就放飞了自我，研究出8种核销兑换码的类型，并且最后上线了。上线之后，就发生了2次bug，出于责任的压力，我直接把另外7中情况在代码中“屏蔽”了，只保留了满足需求中的情况，上线后就再也没有发现过bug。直到我离开团队，另外7种情况也没用到～～ 2）一直转的轮子： 当时团队需要一个日志报警系统，需要给制定的公众号推送报警通知。于是我接下了这个活儿。封装了腾讯SDK、报警策略、调用接口。。。等等，分别单独封装的模块做测试，然后再做整体的“黑盒”测试，最后就上线了。之后只要是接到优化日志报警系统的需求的时候，先考虑：这个需求到底是不是报警系统该做的，如果不该做的，宁愿单独写一套服务，也坚决不往这个系统里放；如果需求是报警系统里的任务，比如增加“短信”报警，或者增加报警策略，就单独增加、或者修改相应的模块，并做好单独的模块测试，再上线。 这些轮子带来的思考：1）千万不要做过度设计，2）模块划分、测试驱动 是很好的开发策略，3）目标单一，非常非常重要！！
2022-04-12 - ivhong 👍（8） 💬（2）
我是一个10多年的开发，一直是开发，我也想往“上”走，但是“上”又是哪呢？也许是性格上的缺陷，或者是学历的不足，最大可能是是“懒”，哈哈！ 思考问题一： 情况1：不该我考虑的不考虑！ 这个情况很符合我现在的工作环境，4、5个的项目（不同的框架，甚至不同的语言），一起堆过来，有时真让人抓狂！！遇到这样的问题，我会先那些提出需求的产品经理讨论项目的重要程度（安排优先级）！如果项目经理直接都说自己的项目重要，那么就把所有的项目预计的花费时间列出来，然后找到他们的领导或者我的领导叫到一起讨论优先级的问题（在我这个开发的视角中，是看不到哪个项目重要的，所以这事儿不该我考虑）。不论找不着上级领导确认，最后都要把最后的计划排期做成excel文档，邮件统一发出来，让所有人知道。 情况2:该我考虑的必须考虑！ 我对项目优先级的判断先把项目需求现做下面的分类： 1）哪个项目既能高效完成，又能带来收益 2）能高效完成，不会产生拖拉的后果，带来的收益并不是很大 3）带来的收益很大，但是占用长期的开发时间 4）既没有收益，又占用开发时间 我的选择是 1 > 2 > 3 > 4。事事难料，难免全篇一律，所以优先级选择还可能根据所处的环境做不同的选择，单基本上不会变。
2022-04-12 - neohope 👍（7） 💬（1）
感觉不同公司情况不一样，不同阶段也不一样，现在大体如下： 1. 涉及公司关键营收的项目，或者说是现在生死存亡的项目，分配50%的精力 2. 对于支撑公司日常运行的项目，分配10%精力 3. 涉及开拓新市场的创新类项目，对其中有盈利能力有增长空间的，或者说公司未来的项目，分配15%的精力 4.涉及开拓新市场的创新类项目，对其中有盈利可能的，或者说可能是公司未来的项目，分配10%的精力 5.对于一些政治类项目，用尽量短平快的方式达到目的，分配7%的精力突击弄完 6.对于一些没有盈利可能的半死不活项目，分配1%精力定期check一下 7.对于一些应该早些下线的项目，分配7%精力早日送走
2021-12-23 - escray 👍（5） 💬（2）
直接进入思考题环节 按以往的工作经历，项目的重要性可能就是按照领导的喜好，或者是即将到来的最后期限。如果让我来决定，那么可以按照重要且紧急、重要不紧急、紧急不重要、不重要不紧急的优先级来排列。 如果让我自己来选，可能也比较喜欢“极简”设计，但是从某种程度上来看，所谓“极简”或者是“敏捷”的设计，有时候也是在思考上懒惰的结果。 在我参与的架构活动中，我比较喜欢和用户接触，去了解需求的过程，因为这样才能真正解决问题。
2021-12-14 - 借你一秒 👍（4） 💬（1）
项目是否会对产品带来实质性的竞争力提升
2021-12-14 - 彭彭😄 👍（3） 💬（1）
三个因素 1.带给业务的正向价值 2.研发人效提升大小 3.架构合理化演进 其中1优先级最高，2和3稍微靠后。也要case by case的看。 在业务成长期或者瓶颈期，业务基于突破，需求偏多，倾向于快速支撑业务需求，赋能业务增长。 平稳期，业务需求相对偏少，重心倾斜到架构合理化演进及人效提升上，以期稳定、高效的支撑业务未来1-2两年的发展。不同公司的文化氛围不同，有些公司研发话语权强一些，可以顶着业务压力做一些技术侧的升级。更多的中小型公司面临生存压力，业务话语权大于研发，研发做纯技术的架构升级相对困难，可以在支撑好业务的前提下，适度的做一些技术侧的改造。
2021-12-21 - 日月星辰 👍（2） 💬（1）
如何判断一个项目的重要性？ 要是以前，我会看这个项目是否能让我感兴趣或者勾起我的好奇心，有可能是业务比较有趣或者可以运用新技术。 学完这一课，虽然我不知道公司的战略是什么，但是我会从用户的角度来看，这个项目是否有价值或者意义，再去考虑自己的因素
2022-04-13 - leesir 👍（2） 💬（1）
关于轮子的思考： 在分布式环境下，任何一次系统调用都会增加复杂度。所以我相信，发明轮子的团队一定深刻考虑过引入新项目所带来的复杂度问题。一个好的轮子，一定会有多个应用场景，在全局的角度看，如果这个轮子能收拢同类功能，让大家一键接入，降本提效，整体效率一定是最优的。 思考过往，总结下自己经历过的好轮子变成废轮子的情况： 1、公司经营环境发生变化，团队职能发生调整。 比如一个中台团队，是为了更好满足于公司各业务线的基础需求而建立的。当因监管或其他因素导致公司业务大量萎缩，中台反而成为累赘，中台人力需要转变为业务人力。那这一大坨中台系统，在业务的视角来看，就会成为过度包装的轮子项目。 2、全局规划与局部紧迫性的不匹配。 轮子项目服务与众多业务线，一个轮子想要变得更好，需要沉淀足够的经验后不断演进。当某个别业务线因为自身的特殊性，总是急需一些定制化的功能又不能被满足时，业务团队不得不另谋出路。要么是fork一个分支，要么是重新做一个。从长期来看，必然是重复建设，但在短期内，在业务团队的视角来看，新的轮子各方面都优于老的轮子。 3、KPI导向。 公司从上到下，都不喜欢一件事情写5年。今年从0-1开发了新东西，反响热烈，第二年从1-10，新增了许多特性。第三年就没有了，取而代之的是另一个关注点有点不同的“一站式解决方案”。为了让绩效更好看，貌似大家都爱这么做。 对于控制不了的原因，只能默默接收。对于kpi以及技术先进性等原因，需要与郭老师一样，紧盯目标，甄别伪需求。目标感是学了2篇文章以来感受最深的一点。
2022-02-09 - 学习使我快乐 👍（1） 💬（1）
第一个问题 1、符不符合公司的战略目标 2、能不能为团队带来正向收益 3、需要各种资源大不大 4、个人是否能获得成长 依照这四个维度综合排序需求，不能成为被别人试错的工具人，做无意义的工作，只是苦劳而不是功劳
2022-01-19 - 孜孜 👍（1） 💬（1）
我感觉轮子出来的时候都有自己的优势满足了公司的某些需求，然后成为破轮子的原因，我感觉是做轮子的同学可能没有意识到，轮子之所以有人用不是因为技术先进，而是满足需求，只有服务更多的需求
2021-12-26 - ownraul 👍（1） 💬（1）
郭老师, 有个针对过度设计的问题想请教 在一个架构设计中, 考察了一个开源框架或者组件, 发现当下真正能匹配使用的仅仅在 10%-15%, 直接引入可能过重, 并且后续发展是否会用到其他的非常不确定 那当下是否可以还是自研, 但是架构设计上可以采用借鉴开源框架, 但是保留有后续更多扩展可能性 ? 或者说您还是觉得需要引入这个组件, 可能后续业务发展起来可以直接使用更多内容 ? 引入开源组件有一点绕不过去就是一旦需要有些定制化的需求改动, 开源组件始终是不如自研的容易掌控
2021-12-16 - 永久26 👍（1） 💬（1）
1、项目是交付类的 还是 产品类的？ 2、交付类的一般时间节点比较明确，业务目标也明确，大部分选择成熟的架构；个别业务需求需要进行新的增补； 3、产品类的就需要比较大的投入，无论是与业务的产品需求沟通，还是技术内部的调研验证，都需要投入相当的注意力；当然产品首要满足业务复用性，以节省交付成本为目标； 4、轮子嘛，我们首先判定是否没有可用的，确实没有能用的我们才会自己造；
2021-12-15 - 白彦彬 👍（1） 💬（2）
现任Data Scientist+兼职软件构架师，尝试回答学长的一个提问。 1. 关于重点项目优先级的思考，如果调研时间充分，考虑优先级安排对于公司、部门商业战略、战术的实现极为关键，优先级排序应给予极高的重视。 首先总结这些重点项目上马的驱动目标、交付时间、商业价值、决策层级等，按照驱动目标分类为战术、战略项目；按交付时间要求分类为短、中和长期项目；从商业价值角度计算投资回报率（ROE）；按照决策层级分类为CEO、BU、GeoU等给与决策层级权重。从最优化的理论的角度将这几个关键方面量化。 根据商业价值、企业商业文化（官僚、用户价值最大、技术先进、追求短平快等）、重点项目之间的关联度，确定最优化的目标，考虑每个项目的团队技术能力、可调用资源（人力、物力和时间）、项目复杂度，估算每个项目KPI，然后先根据KPI将项目排序，再根据项目之间的内在关联度，微调重点优先级；排序结果交由主要利益方组成的评审委员会审核确定重点项目排序。 关于思考力的分配，与战术、战略目标的明确，短、中、长期的评估，商业价值排序，最终的思考力分配同样需要尽可能地去契合公司商业文化、商业战略的大目标、系统设计的大目标和大方向。
2021-12-15