ARIS使用手册 第二章

2 集成信息系统体系结构(ARIS)
2.1 ARIS 体系的概念
集成信息系统体系结构的概念构思 (ARIS) 是在产生于对运营过程的整体分析的集成概念基础上形成的。在这种体系的创造过程中，第一步就要求对运营过程建立模型，这个模型要求包含企业运作过程中的所有基本特点。最后形成的模型是非常复杂的，所以要划分成若干互相独立的视图以降低其复杂性。由于这种划分，每个独立视图的内容都可以用某种方法来说明，这种方法适用于某个特定的视图，而且不用过多注意其与其他视图之间纷繁复杂的内外部关系。然后，视图之间的关系与模型结合，并且介入过程链的总体分析，而没有任何冗余。
降低模型复杂性的第二种方法就是对不同的说明层次进行分析。在生命周期模型概念之后产生的信息系统开发中的多种说明方法是由信息技术的接近性来区分的。这就保证了对与业务管理相关的问题与运营管理有关的问题直到对它们的技术执行的说明都能保持一致性。
因此，ARIS 体系构成了集成信息系统的开发与最优化的总体框架，同时也时期具体执行的系统说明。在这种情况下， 就应该强调产生于ARIS体系的，与主题相关的说明层次，这些说明层次是用于对业务管理相关的过程链进行创建，分析，和评估的。Scheer对集成信息系统体系结构做了更详尽的说明（参阅 Scheer,《 集成信息系统体系结构》 1992）。

2.2说明视图
本节开始于对业务过程的分析，如 图 2.2-1: 业务过程模型所示。
整个过程由从事件“已到达的顾客订单”开始。这一事件又影响到随后启动的事件“已接受订单” 的运行（或处理）。为了保证这个操作的执行，对相关环境的状态说明是相当必要的。在这个例子中，状态对顾客以及订单中指定的产品都产生了影响。在工作流处理过程中，环境数据的状态是可以被改变的，举例说明，当预定产品的数据更新时，货物库存的数据也随之更新。
这些功能由各部门所属的人员处理完成。部门使用特定的信息技术工具（如个人电脑，打印机等）来完成这些任务。
事件“已确认订单” 即是“已接受订单”的运行结果。事件“已接受订单”引起了其他的附加操作（订单跟踪，生产计划）。 反之，数量众多的，亦作为人力与技术资源的状态说明，在这些操作的运行过程中也是非常必要的。这些资源可以与其他过程的组成成分建立联系。因此，就可能会需要同样的状态说明或使用同样的资源。
图 2.2-1: 业务过程模型
在一个完整的业务过程中，所说明的组成部分以及它们之间的内部关系包括：过程，事件，状态，用户，组织单元，以及信息技术资源。如果考虑到每一事件的所有过程元素的可能产生的结果，很可能会使模型大大复杂化，并造成说明中的冗余。
为了降低这种复杂性，全文被分为若干视图（参见图2.2-2:过程模型视图），用以说明离散型建模 和设计方面的问题。(见Scheer, 《集成信息系统体系结构》 1992, p. 13 ff.) ，这些问题可以（基本上）彼此独立地寻求解决方法。用这种方法来划分视图，尽管独立视图之间的联系较为松散，但能使其组成部分之间紧密的联系起来。

类似于 “已收的客户订单” 或“已开发票” 之类的事件对信息目标（数据）的状态差别进行了定义。参考内容的状态，如“客户状态”或“产品状态”也可以以数据的形式来表示。像这样，状态和事件就构成了ARIS 体系的数据视图。
这些要被完成的功能（过程）以及它们的内部关系构成了另一个视图，即功能视图。这个视图包括对功能本身的定义，总体关系之下独立的子功能的列举，以及功能之间存在的地位关系。
组织视图表现的是客户与组织单元之间的结合，同时也表现了它们之间的关系以及与之相关的结构。
信息技术资源构成了第四个说明目标，即资源视图。而这一视图在为说明与业务更加直接相关的成分提供一般条件的范围内，对业务过程中的相关观点是至关重要的。由于这一原因，对其他视图的成分说明 （数据，功能，即组织结构）都是在它们与信息技术资源的接近基础上完成的。由此，这些资源是在其他视图的设计规范和实施描述说明层次进行处理的（见第二章第三小节）。因此，在对不同层次进行分析的基础上而定义的生命周期模型就可以取代作为独立说明对象的资源视图。
把最初的过程划分为若干各子块会降低其复杂性—纵然这要牺牲掉视图的过程成分之间的关系。由于这一原因，控制视图 的概念被作为一个额外的视图而引进于此。它的作用主要是说明视图之间的关系。在一个独立的视图中，这种关系的集成使它有系统的介入系统分析，而不存在冗余。
控制视图是ARIS 体系中的重要组成部分，也是ARIS 体系与其它所提及的体系不同之处的重要关键。（见Scheer, 《集成信息系统体系结构》 1992,p. 24 ff., 与其它体系之间的比较）。
这四个ARIS 视图所形成的过程如 图 2.2-1: 业务过程模型 所示。这一过程将在以后的章节里再作详细讨论。

2.3 说明层次
如前所述，ARIS 资源视图的结构布局是根据信息系统的说明层次的生命周期概念而形成的。
生命周期模型的主要形式即层次或阶段概念，这种模型说明了一个信息系统的生命周期。然而，ARIS生命周期模型没有流程模型那样的重要性，流程模型是用于开发独立的说明对象的。它仅在它们与信息技术的近似性的基础上，对不同的说明层次进行了定义。
这种区别在ARIS 三级模型，图2.3-1：信息系统的说明层次 中有明确的表达。（见Scheer, 《集成信息系统体系结构》 1992, p. 16 f.）.
整个系统的开发过程始于对业务操作问题的分析。这种分析基本上包含了整个被说明的业务过程，这一过程在这里是以用户目标和用户所使用的语言为导向的。这一过程把信息技术技术选择进行合并，以用来支持业务流程与决策。因此，只有半正式的说明语言被用来描述业务问题。由于这种方法缺乏足够的细节，以及语言的高度专业化，所以在实施阶段不能被用作正式的说明方法。
需求定义必须要把业务程序用正式的说明语言进行说明，这样才能使这一步成为需求定义到信息技术的一致转换过程的出发点。这一过程也是建立（语义）模型的过程。需求定义与问题说明之间的联系是非常紧密的，这一点在图2.3-1: 信息系统的说明层次 中有着很好的表述。
当需求定义的概念环境完成了向IT导向的转变时，就达到了设计规范层。这里，模块（或是说用户事务）是用来执行被定义的功能的功能，而并不是功能本身。也可以认为这一层在信息技术说明的总体方法中，是另一种形式的需求定义。因此，需求定义和设计规范之间的联系是较为松懈的。这意味着设计规范可以在不影响需求定义的情况下做一些变动。然而，这并不意味着需求定义和设计规范可以在彼此分离的情况下被制定出来。在完成需求定义之后，把它的内容按照业务管理用这种方法来确定下来时非常重要的，这样外部面向IT的事项（比如信息系统执行）对主题的内容就不会造成太大的影响了。
在实施描述层，设计规范已经被转换成为具体的软硬件组件。由此，与信息技术之间的物理连接就完成了。
每个独立的说明层是以不同的更新周期来标识的。更新频度最高达到实施描述层，最低达到需求定义层。
实施描述层与信息技术的开发过程联系非常紧密，并且由于信息技术的创新周期较短，往往会用于进行修订。
需求定义层有着特殊的重要性，因为它既是长期业务应用的贮藏室，同时也是更进一步的开发实施描述的开始点。需求定义的生命周期是最长的，而且由于它与业务问题说明之间的密切关系，能够说明信息系统对企业的最大的好处。由于这一原因，需求定义（或是语义模型）的开发的优先级是最高的。语义模型使用户和他们的初始应用IT相关语言来说明业务问题的过程之间建立了联系。

视图和说明层次的创造，以及初始业务问题的解决，构成了整个ARIS体系。如图2.3-2 ARIS体系结构 所示，每一个说明视图都含有这三个层次，需求定义层，设计规范层，以及实施描述层。

随着ARIS 体系结构的发展，以说明性的视图及层次来定义的说明视图也随之而固定下来。 作为一切分析的开始点，它们包含有十三个组成部分，这在说明每一个体系块的过程中，对选择和描述适当的说明方法是非常必要的。

选择这些方法的标准： (见 Scheer, 《业务过程工程》1994, p. 18)
• 说明方法是否简单易懂，
• 特定的主题内容表达是否适当，
• 是否能对所有被说明应用软件均采用一致的说明方法，
• 对这种方法的使用是否熟悉，
• 说明方法与信息技术的发展过程之间是否具有独立性。
在说明视图中使用的各种方法将在以后章节中详加说明。