通用的人员和组织结构模型

感谢 Martin Fowler，很多想法来自他的《分析模式》（Analysis Patterns）

目的

企业架构的出发点是业务，业务实现的关键是人，业务关系的理顺靠组织架构。

在企业IT整合的过程中，对于人员和组织机构信息的整合是一个重点。但是目前的解决方案中往往偏重于“系统用户”的整合，而对组织架构没有考虑或者考虑得很少，同时对于包含客户、合作伙伴等在内的虚拟组织往往支持不够。组织架构、岗位的设定等信息往往牵扯到权限，因此有必要探讨一种统一的人员和组织机构模型，既可以作为此类数据的统一数据源，也可以为之后的统一权限管理打下基础。

 

领域模型

• 主体

企业的基本组成单位是人(Person)，包括员工、合作伙伴、经纪人/代理人、外包人员、客户等；为了人们之间更好的协作还会设立一些组织单元(Unit)，如部门、分公司、子公司、营业部、委员会、工作组、项目组等；在部门之中还会设定一些岗位(Position)。

这些对象都是业务行为的主体(Subject)。所谓主体，可以被托付给相应的责任，而责任体现了他们之间一种具有共性的关系。

 

• 责任

这种共性的关系就是一种责任(Accountbility)关系：委托者将责任托付给受托者。具体表现为很多形式，比如部门之间的上下级关系，人员和部门的从属关系，企业和客户的业务关系，企业和合作伙伴的协作关系等等。这种责任关系通常会有一个期限（Period），记录期限信息可以帮助我们记录责任关系（如组织结构、人员历任职务）的变化。

 

• 知识级：业务规则的体现

上述的责任关系太泛化了，而且缺少必要的约束。比如，组织的层级结构约束，所以需要引入知识级的模型对象。知识级体现定义和规则，操作级记录实际发生的事情。

知识级的作用:

1. 管理复杂性，将复杂的业务规则放到知识级

2. 动静分离:知识级处理相对固定的部分，操作级处理变化频繁(相对知识级来说)的部分，即具体的配置。

3. 知识级约束操作级的行为。

 

在知识级引入主体类型SubjectType，就可以通过类型来约束主体（Subject)的行为。其中最重要的约束就是委托关系（Commission）的定义。委托关系约束了责任（Accountbility）的规则，比如，有一类责任来自产品的层级关系，而另一类责任来自销售的层级关系，就可以定义“产品层级”和“销售层级”这两个Commission，来将Accountbility区分成不同的类型。

显然，委托关系是主体类型之间的many-to-many关系，因为还需要在委托关系上进一步进行定义，所以定义一个关联类：Commission，关联到主体类型之间的many-to-many关系上。

每一个责任关系都应该由唯一的委托关系来定义，即委托关系是责任关系的类型。

 

引入知识级带来的一个工作就是：在设计阶段就要考虑知识级的初始化。因为知识级的实例中隐藏了设计（知识）。

 

• 主体类型泛化

在初始化知识级对象的时候，我们很容易想到：组织单元（Unit）是一种主体类型，其委托关系包括：下级组织单元（默认）。

但是如果再细分下去，可能会定义总公司，分公司，营业部，而对这些组织单元还需要定义其下级组织单元（默认）的委托关系。、下级组织单元（产品层级）、下级组织单元（销售层级）

这样做很容易引起模型的膨胀，使得初始化知识级变得非常痛苦。所以，引入主体类型之间的泛化关系（Minxin）就显得很有必要。允许主体类型之间的一种“多重继承”，可以避免这样的麻烦。

 

另外一种情况是兼职。随着现代企业的发展，人员在企业中的定位可能是多面性的，兼职的情况越来越经常出现，但是大家都视为特殊情况而很少进行有效的处理。比如这样一种情况：信息中心总经理兼任CIO兼任创新委员会成员。在不考虑兼职的时候，我们会创建信息中心总经理的岗位，CIO的岗位，创新委员会的组织单元。并使具体的人（Person）与这些主体之间具有任命或小组成员这样的关联。一旦出现了兼职，就需要创建一个复合的、继承上述三者主体类型的一种“新”类型。这显然很丑陋。

解决的办法就是允许主体具有多种类型。考虑到大多数情况是没有兼职的，所以在主体和主体类型之间建立两个关联：主要类型，所有类型。

 

 

• 层级型委托关系

责任模式在灵活性的同时缺少了约束规则。比如，对一个严格的销售关系层级序列：总公司-分公司-区域子公司-部门-销售办事处。这种层级序列实际上是对委托关系的约束。要表达这种约束，可能每个层级的组织机构都要定义两种委托关系：上级-->自身，自身-->下级。这样的实现比较笨拙。

为了简化对层级关系的处理，可以定义一个层级的委托关系（LeveledCommission），该委托关系维护一个主体类型的列表，并规定级别列表中上级类别的主体只能向下级类别的主体负责。

思考：在实际设计时，可能会根据需要构建委托关系的多个子类，处理各种约束规则，以便于模型的使用。

 

• 操作和岗位

责任和权利总是对应的。通常，责任对应一系列的操作（Operation）。对Operation的细化(如对应的系统、地点、动作、资源等)通常在权限管理的相关模型中进行。但是在通用组织机构模型中，需要专门提到的是岗位（Position）。

如前所述，岗位Position也是一种主体，人和岗位之间存在一种任命/聘用关系，岗位由组织单元（Unit）设定。但同时，岗位也体现了对操作的聚合。通过将责任关联到岗位而不是具体的人，就可以间接地把操作聚合到岗位。

在RBAC（基于角色的访问控制）模型中，角色的很重要的一个来源就是岗位。

 

 

小结

模型的全貌：

 

特别要注意的是，这里只是一个逻辑模型，要实现该模型还需要具体的设计。