Question

真实的情况通常是这样的：客户提出“办公系统”时，并没有打算开发寄予了管理期望的一个软件产品。从客户的角度上来说，这个软件的底线是帮他们减少一些手头的工作，并尽量让现行的工作更规范一些。换言之，客户在最低限度上需要的是一个现实的复制品与流水线。

通过现实系统的直接需求是推断不出“管理”这一概念的产生的。但是回溯我们此前列举的几点事实，其中：

• 这一系统总是某些办公室成员使用的

是一个关键事实。这一事实模糊了“办公室成员”的类型。我们从两个方面重新考虑一下：如果这是某一个特定类型的办公室成员使用的系统，那么它适宜实现为一个工作系统，用来重现某种特定工作的规则与流程；如果这是一个混合的、由不同成员及其工作需求交织而成的系统，那么这个系统（的本身）必然需要某种东西来使自身规则化。

也就是说，“管理”不是现实系统的意图，而是映射这一系统到计算环境时的一个需求。我们必须确定：如果这一需求来自于现实系统，那么它是原始需求；如果它来自于上述的这个软件系统本身，那么它首先是设计者的意图，其次才是对现实系统的反映。

这是一个典型的因果问题：究竟是现实产生了意图，还是先有了意图再去参考现实。我们强调这一细节的原因于：如果是前者，那么控制这一意图（以这里的例子来说，是指“管理”这一行为）的意义在于“控制原始需求”；如果是后者，那么控制它的意义在于“控制设计欲望”。

一旦我们确认这只是一个意图，并且这一意图的核心仅仅是“规则化”那些需求与需求的用户对象，我们就需要更深层次地设定“被规则化的”这个系统（本身）。总结我对这一设定的考虑，它将会是：

• 与现实系统看起来类似的
• 具有同等的组织容量的
• 基本符合现实系统的运作逻辑的

一个软件系统。

这三项设定仍然都是架构意图。确切地说，这三项意图都是为了控制“管理”这一意图的规模的。从思考行为（的模式）方面来看，上述概念或观点的层进关系如图 8 所示 4 。

图 8　基于对思考行为（的模式）的观察：上述概念或观点的层进关系

与上述的整个过程类似，我们可以：

• 在“与现实系统看起来类似”这一方向上，发现类似于“经营”、“营销”、“人力”等这样的一些角色，并进而形成“角色集”；
• 在与“基本符合现实系统的运作逻辑”这一方向上，发现“经营”角色管理“营销”角色的市场方向，“人力”角色提供“营销”角色所需的资源，但并不管理之，等等逻辑；
• 在“具有同等的组织容量”这一方向上，发现这是一个具有“规模不会超过 200 人的”、“不需要跨国管理”等限定条件的系统。

通过对种种方向的探索、思考与推演，我们会得到更多的、类似上述的这些设定——设计原则或系统原则。需要留意的是，现实系统中，并没有任何需求方来提出这些设定，例如经营角色会说“我们需要一个饼状图”，营销角色会说“我们每周至少发布一次营销活动”，但是他们都不会说“你的系统中需要这样有着管理层次关系的两个角色”。

回溯上述过程：管理、角色集、组织机构这三个概念的提出，都是架构师的架构意图，以及基于这些意图进行推演的结果。