各种观点

观点一 架构不需要目标

有人认为，架构设计是一个迭代的过程，我们要不断发现并且补偿现阶段软件设计的不完美，然后通过各种手段打补丁升级。因此，架构设计永远都是螺旋上升的，没有也不需要目标的指引。

观点二 目标不是架构师的责任

也有人认为定义目标并不是架构师的职责。毕竟目标是架构活动的一个输入，由需求发起方设定，不受架构师控制，所以架构师能做的就是想办法满足这个目标。

郭老师的观点

在每个架构规划启动之前，应该有且仅有一个正确的目标，这是架构设计的起点。目标不正确，你和你的团队再努力都没办法成功。目标的重要性，就在于它能够一直引导我们走在正确的方向上，同时帮助我们做取舍，在多个备选架构方案中作出最优的选择。

所有的架构规划必须有且只有一个正确的目标，而且它必须与公司的战略意图相匹配，这是你架构设计的起点。否则，系统就会变得复杂和无序，缺少结构性。

架构活动为什么需要目标

在工作中，我们可能会追新技术，然后把一个系统的开源实现换成了另一种开源的实现，例如将Active MQ换成了Rocket MQ。但是，在一个企业里，技术先进性很少会是一个架构活动的正确目标，所以很多人做架构升级都只是为了做而做。

如果在初期就有一个明确的目标，那么做到最后，子模块和初期目标就会是大致对齐的，同时也会最大化对目标的贡献。

目标缺失的原因

可以从技术和业务两个维度来寻找

技术上：目标缺少全局视角

从技术维度去思考目标缺失的根因，就在于缺少全局视角，主要有三方面的表现：技术同学对于先进技术的强烈好奇心，开发者的个人利益，以及信息沟通不畅。

对于先进技术的强烈好奇心

由于技术原因导致的目标缺失往往有个非常积极正面的出发点：那就是技术同学对于先进技术的强烈好奇心。

技术尝试跟业务和产品尝试一样，每一次尝试都是在耗费企业的机会成本。如果是一个正处于创新期和成长期的企业，那么每次尝试还会耗费相关同学的心力。心力是一个极其有限且宝贵的资源，一旦尝试失败，耗尽心力的同学很有可能会选择离开，加剧整个企业心力的损失。除此之外，每次尝试都会给原有系统注入新的复杂性，从而导致整个系统的复杂和无序，这就是墒增的过程。

开发者的个人利益

其实还有一个不太光彩的原因，那就是开发者的个人利益。举个极端的例子，这个团队曾经有个做大数据的负责人，匆忙引入了开源领域的一个新框架，并在会议上作了个演讲。但是讲完之后没多久就提了离职，留下个做了一半的烂尾项目。

信息沟通不畅

因为层级低的技术同学很少做跨团队跨部门沟通，一些小范围的架构改造也找不到一个官方版本可以借用，而且从头开始的时候，总觉得别人的设计太复杂，有过度设计的嫌疑，所以都是自己去新写一个版本。而一旦业务逐渐增长，小工具长成了大工具，就变成了一个新的变种。

做业务和做产品的同学要有正确的取舍，不能见什么功能就要什么功能。

我们做技术的同学也不要动不动就认为别人的东西过度设计了，认为我的场景简单，就应该定制自己的技术。往往你的场景简单，仅仅是因为你的业务还没做起来。等业务做大之后，会发现业务根本不是你想象得那么简单。我见到过太多所谓的“极简设计”了, 事实证明，大多数的极简设计，要么早早夭折，要么越做越复杂。到头来还是得用专业版设计进行替换。

业务上：目标太多、不明确

此文章为3月Day18学习笔记，内容来源于极客时间《02｜法则一：为什么有些架构活动会没有正确的目标？ (geekbang.com)》