做人、做事，做架构师——架构师能力模型解析架构是一个从全局到局部的过程，而实施正好反过来，是从局部到全局。这也正是“设计做大，实施做小”的另一个层面的含义。 “设计大”才可以见到全局，才知道此全局对彼全局的影响； “实施小”才可能关注细节，才谈得上品质与控制。

事实上，大多数情况下架构是在为“当前项目之外”去考虑，这可以看成全局关注的一个组成部分。因此我们需要界定所谓“全局”的范围：若超出公司或整个产品系列、产品线或产品规划的范围，则是多余的。所以当架构决策谈及“全局”时，其目标并不见得是“保障当前项目”,而又必须由当前项目去完成。②一个经常被用到的例子是；如果仅为当前项目考虑，那么只需要做成DLL模块；如果为产品线考虑，可能会是“管道+插件”的结构形式。而“管道+插件”的形式显然比做成DLL模块更费时，这个时间成本(以及其他成本)就变成了当前项目的无谓开销。

这种全局策略对局部计划的影响是大多数公司不能忍受的，也被很多团队所垢病。然而这却是架构师角色对体系的“近乎必然”的影响——如果你试图在体系中引入架构师这个角色的话。一些情况下，体系能够容纳这种影响，例如“技术架构师”试图推动某种插件框架，而正好开发人员对这项技术感兴趣，那就顺其自然地花点工夫去实现了。但如果实施者或实施团队看不到“多余的部分”对他们的价值，来自局部的抵触就产生了。

①节选自《程序员》杂志2008年第4期同名文章。

②通常这是指系统架构的一部分工作，但一些技术架构可能也需要这样的全局眼光才能正确决策。

这种情况下，平衡这些抵触就成了架构推行的实务之一。在我看来，“平衡”是全局的艺术和局部的技术。也就是说，一方面架构师要学会游说，另一方面也要寻求更为简洁的、成本更小的实现技术。只有当整个体系都意识到(你所推行的)架构的重要性，而且实施成本在他们可以接受的范围之内时，他们才会积极行动起来。yipindushu.com

所以所谓平衡，其实也是折中的过程。构架师只有眼中见大，才知道哪些折中可以做，而哪些不能。所谓设计评估(模型图○中的实现能力→设计能力→设计评估分支)并不是去分析一个设计结果好或不好，而是从中看到原始的需求，看到体系全局的意图，然后知道在将设计变得更为“适当”时可以做哪些折中。同样的原因，架构师也必须知道自己的决策会产生的影响，才能控制它们，以防它们变成团队的灾难。有些时候，架构师甚至需要抛弃一些特性，以使得项目能够持续下去，因为产品的阶段性产出只是整个战略中的一个环节，而不是全部。

附录一做人、做事做架构师——架构师能力模型解析①这里的模型图是指与本篇文章同时发表的一个“架构师能力模型”,并非本书中所论的模型。该模型可参阅《程序员》杂志中的原文或我的个人博客。