这个“架构v0.0.0.2”版本显然也是对现实中的办公环境的正确描述，但却与此前的“架构v0.0.0.1”迥然不同。那究竟是什么原因造就了这样的差异呢?这仅仅是图形的组合方式的不同，还是某些“架构师”的个人喜好的差异，亦或是现实系统在本质上就存在着这样的多样性?都是，但也都不是①。事实上当我们试图去表达现实系统的“一个映像”时，我①做第一种回答的人，是关注到了不同视角下的差异，因此会把系统变得更为复杂的。做第二种回答的人(亦如后文中的讨论),则试图进一步从差异中找到共性，从而简化对系统的讨论。

们总是存有特定的意图。这种“架构上的意图”决定了我们的观察视角，也决定了我们之后表达的结果①。

【“架构v0.0.0.2”中包含了此前版本中的全部“业务”,并且认为：】

□业务是一个未知规模的“业务集”中的一部分；□业务之间是否存在“公共业务”与“特定业务”等分别，是不确定的；□业务仅仅是功能性的系统模块，与特定的使用者(用户)是无关的。它还有一个“角色集”:□角色集包含了此前版本的“一般用户”与“特定用户”等；口角色集加入对系统持续观察后发现的一些新角色；口角色集的规模是未知的，它可能随着现实系统的进化而扩展，也可能在某个(阶段交付的)计算系统中被确定。

最后，它还加入了一个在此前系统中并不存在的“组织机构”:□组织机构是对现实系统的“组织”的重现，组织是一群有相互授权关系的人②;□组织机构只表达了“人与人”或“系统与人”之间的授权”关系，即“角色”;□没有确定“一个人”是否能“被授权”为多个角色。

尽管“架构v0.0.0.2”未能描述许多细节，例如是否交叉授权、组织本身是否有层级关系、业务之间是否有逻辑关系等，但是它准确地体现了架构者的一种意图：通过映射现实中的管理责权关系，而不是(如“架构v0.0.0.1”那样)通过区别功能模块的适用群体来规划系统。yipindushu.com

换言之，“架构v0.0.0.2”体现的架构方向应该被称为办公管理系统，而“架构v0.0.0.1”完成的则是办公(功能)系统。关键在于，前者体现了一种架构意图，而后者仅仅是对现实系统的一些事实的复制。然而一旦架构思想中出现了这一意图，我们就不得不提出如下的设问：□“管理”是现实系统的需求吗?口“组织机构”能够正确地映射现实系统的“管理行为”吗?三真实的情况通常是这样的：客户提出“办公系统”时，并没有打算开发这样一个①这并不一定决定我们的表达手法。的确存在这种可能：手法不同，但“表达的结果”中所呈现的意图却是相同的。②某些组织关系中，并非是单一的“授权”问题，因此这种表达方式也并非万能的。

寄予了管理期望的软件产品。从客户的角度上来说，这个软件的底线是帮他们减少一些手头的工作，并尽量让现行的工作更规范一些。换言之，客户在最低限度上需要的是一个现实的复制品与流水线。

通过现实系统的直接需求是推断不出“管理”这一概念的产生的。但是回溯我们此前列举的几点事实，其中：□这一系统总是某些办公室成员使用的是一个关键事实。这一事实模糊了“办公室成员”的类型。我们从两个方面重新考虑一下：如果这是某一个特定类型的办公室成员使用的系统，那么它适宜实现为一个工作系统，用来重现某种特定工作的规则与流程；如果这是一个混合的、由不同成员及其工作需求交织而成的系统，那么这个系统(的本身)必然需要某种东西来使自身规则化。

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

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

一旦我们确认这只是一个意图，并且这一意图的核心仅仅是“规则化”那些需求与需求的用户对象，我们就需要更深层次地设定“被规则化的”这个系统(本身)总结我对这一设定的考虑，它将会是：□与现实系统看起来类似的口具有同等的组织容量的□基本符合现实系统的运作逻辑的一个软件系统。

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

与上述的整个过程类似，我们可以：□在“与现实系统看起来类似”这一方向上，发现类似于“经营”、“营销”、“人力”等这样的一些角色，并进而形成“角色集”;①此图用于反映思考与决策的过程，阅读图解的基本方法是：当我们将“管理”作为“架构意图”,进而决定了“与现实系统的相似度”,例如：与现实系统看起来类似。