你好，我是郭东白。今天这节课，我们就正式开始架构师生存法则的学习。
你肯定看到过这样的观点：架构设计就是一个迭代的过程，我们要不断发现并且补偿现阶段软件设计的不完美，然后通过各种手段打补丁升级。因此，架构设计永远都是螺旋上升的，没有也不需要目标的指引。
也有人认为定义目标并不是架构师的职责。毕竟目标是架构活动的一个输入，由需求发起方设定，不受架构师控制，所以架构师能做的就是想办法满足这个目标。
然而我要强调的是，在每个架构规划启动之前，应该有且仅有一个正确的目标，这是架构设计的起点。目标不正确，你和你的团队再努力都没办法成功。目标的重要性，就在于它能够一直引导我们走在正确的方向上，同时帮助我们做取舍，在多个备选架构方案中作出最优的选择。
这正是我要讲的架构师的第一条生存法则：所有的架构规划必须有且只有一个正确的目标，而且它必须与公司的战略意图相匹配，这是你架构设计的起点。否则，系统就会变得复杂和无序，缺少结构性。
你可能不太相信为什么架构活动会没有一个正确的目标。这样的案例在现实中有很多，我来分享其中一个。
我们公司目前大多使用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试一试？不论是业务产品还是技术尝试，除了耗费大家的心力，还会给原有系统注入新的复杂性，导致整个系统的无序。因此我们需要做架构治理，剔除无序的元素，让系统重新回到结构化的状态。
这也是为什么我一再强调，架构规划必须始于唯一且正确的目标，并且这个目标还应该和公司的战略意图相匹配。
在每节课的思考题环节，我都会留三道题。建议你任选其中一道作答，目的不是做得全，而是思考得深，让你自己有所得。
欢迎你把自己的思考分享在留言区，我会和你交流。