他只是坐在那里，嘴里说：“做这个！做那个！”当然，什么都不会发生，光说不做是没有用的。

  • 哈里·杜鲁门，关于总统的权力
    He'll sit here and he'll say, "Do this! Do that!" And nothing will happen.
  • HARRY S. TRUMAN, ON PRESIDENTIAL POWER

  假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员，那么他如何确保每个人听从、理解并实现结构师的决策？对于一个由 1000 人开发的系统，一个 10 个结构师的小组如何保持系统概念上的完整性？在 System/360 硬件设计工作中，我们摸索出来一套实现上述目标的方法，它们对于软件项目同样适用。

文档化的规格说明——手册

  手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。

  手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实现过程。

  System/360 Principles of Operation 的一致完整性来自仅有两名作者的事实：Gerry Blaauw 和 Andris Padegs。思路是大约十个人的想法，但如果想保持文字和产品之间的一致性，则必须由一个或两个人来完成将其结论转换成书面规格说明的工作。而且，将定义书写成文字，必须对很多原先并不是非常重要的问题进行判断，并得出结论。例如，System/360需要决定在每次操作后，如何设置返回的条件码。其实，对于在整个设计中，保证这些看似琐碎的问题处理原则上的一致性，决不是一件无关紧要的事情。

形式化定义

如一致性，完整性的数学基础定义

直接整合

会议和大会

  周例会的决策会给出迅捷的结论，允许工作继续进行。如果任何人对结果过于不高兴，可以立刻诉诸于项目经理，但是这种情况非常少见
这种会议的卓有成效是由于：

  1. 数月内，相同小组——结构师、用户和实现人员——每周交流一次。因此，大家对项目相关的内容比较了解，不需要安排额外时间对人员进行培训。
  2. 上述小组十分睿智和敏锐，深刻理解所面对的问题，并且与产品密切相关。没有人是“顾问”的角色，每个人都要承担义务。
  3. 当问题出现时，在界线的内部和外部同时寻求解决方案。
  4. 正式的书面建议集中了注意力，强制了决策的制订，避免了会议草稿纪要方式的不一致。
  5. 清晰地授予首席结构师决策的权力，避免了妥协和拖延。

多重实现

电话日志

  对于存有疑问的实现人员，应鼓励他们打电话询问相应的结构师，而不是一边自行猜测一边工作，这是一项很基本的措施。

  一种有用的机制是由结构师保存电话日志。日志中，他记录了每一个问题和相应的回答。每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。这种机制很不正式，但非常快捷和易于理解。

产品测试

在最后的分析中，用户是独立的监督人员。