架构师的十八般武艺：架构目标

架构目标是架构设计的基础，为架构设计的预期目的，未架构设计指明方向。没有在前期明确目标或者目标偏差，这个是架构设计失败的主因。虽然在架构方法论中有需求变更的环节，但那是应对架构目标跟随业务目标微调用的，如果架构目标一开始就不对，那架构方案的结果只有一个：失败。

设定架构目标需要考虑的因素，我们可以用四个 W 来概括：Who、When、Where、What。

首先是 Who。这个往往也是大部分架构师容易忽略的点。我们的架构升级或者架构方案是要解决谁的问题。这个主体不一样，也许我们的架构目标会有很大的差别。比如同样的一个来账能力的升级，如果从财务视角出发，也许重点要解决的是对账和资金安全的问题；如果从销售视角出发，也许重点要解决的是入账失效的问题；如果从管理层视角出发，也许重点要解决的是数据洞察的问题。这个 Who，对于咨询行业来说比较容易理解，就是给你钱的主。对于一些互联网自建的架构来说，有时候往往会 miss 掉这个，或者经常会只看到给你布置架构升级任务的上级——CTO/CIO。但是，这里的 Who，要跳开这一层级，去看我们的额系统最终的使用方是谁，是要解决谁的问题。

其次是 When。我们要明确我们的架构要解决问题的时限。如果我们要解决短期急迫的问题，和我们要做一个长期规划，解决未来可能的问题，这个架构方案会完全不一样。

第三是 Where。这个问题是在我们内部就能解决，还是需要有一些外部的配合。如果是内部就能解决的，又要看一下是否有什么协同部门需要考虑。如果是要在外部解决的，那就更要分析外部在系统、合规、协作等方面的约束点。只有这些都清楚了，设计出来的架构才会更可靠。

最后才是 What。分析完 Who、When、Where 之后，我们基本就可以确定一些要求、限制、策略，下面就是要真正定义架构目标了。架构目标具体怎么定，是脑爆还是基于方法论，这里不做讨论。对于架构目标，我们只针对目标的质量进行评判。

首先，架构目标要符合 SMART 原则：

• Specific：架构目标需要具体，需要最终能落地到硬件、软件、资源上。

• Measurable：架构目标需要可衡量。对于功能性设计，需要有业务增长、提效、降本的数字；对于非功能性设计，需要有技术指标。

• Attainable：目标现实一点。不要搞什么世界领先、业界第一的口号。

• Relevant：目标和 stakerholder 诉求一定要能关联起来。在架构设计完成后，需要和业务进行再次对焦，两边对架构能达到的目标进行推荐和确定。

• Time-bound：架构方案需要有时间期间，三年长期的、一年短期的分别是什么。具体到每个 Q 又需要完成和关注什么。只有这样，才能跟踪和衡量。