集成信息系统体系结构

2集成信息系统体系结构(ARIS)

2.1ARIS体系的概念

集成信息系统体系结构的概念构思(ARIS)是在产生「对营运过程的整体分析的集成概念基

础上形成的。在这种体系的制造过程中，第一步就要求对营运过程建立模型，这个模型要求包含

企业运作过程中的全部基本特点。最终形成的模型是特别简单的，所以要划分成若干相互独立的

视图以降低其简单性。由于这种划分，每个独立视图的内容都可以用某种方法来说明，这种方法

适用于某个特定的视图，而且不用过多留意其与其他视图之间纷繁简单的内外部关系。然后，视

图之间的关系与模型结合，并且介入过程链的总体分析，而没有任何冗余。

降低模型简单性的其次种方法就是对不同的说明层次进行分析。在生命周期模型概念之后产

生的信息系统开发中的多种说明方法是由信息技术的接近性来区分的。这就保证了对与业务管理

相关的问题与营运管理有关的问题直到对它们的技术执行的说明都能保持全都性。

因此，ARIS结构构成了集成信息系统的开发与最优化的总体框架，同时也时期具体执行的

系统说明。在这种状况下，就应当强调产生于ARIS体系的，与主题相关的说明层次，这些说明

层次是用于对业务管理相关的过程链进行创建，分析，和评价的。Scheer对集成信息系统体系

结构做了更详尽的说明(参阅Scheer,《集成信息系统体系结构》1992)。

2.2说明视图

本节开头于对业务过程的分析，如图2.2-1:业务过程模型所示。

整个过程由从大事“已到达的顾客订单”升•头。这一大事又影响到随后启动的大事“已接受订

笆〃的运行（或处理）。为了保证这个操作的执行，对相关环境的状态说明是相当必要的。在这

个例子中，状态对顾客以及订单中指定的产品都产生了影响。在工作流处理过程中，环境数据的

状态是可以被转变的，举例说明，当预定产品的数据更新时，货物库存的数据也随之更新。

这些功能由各部门所属的人员处理完成。部门使用特定的信息技术工具（如个人电脑，打印机

等）来完成这些任务。

大事“已确认订单”取凫“已疫受力衣”的运行结果。大事“已疾受方甲〃引起了其他的附

加操作（订单跟踪,生产方案）。反之，数量众多的，亦作为人力与技术资源的状态说明，在这

些操作的运行过程中也是特别必要的。这些资源可以与其他过程的组成成分建立连系。因此，就

可能会需要同样的状态说明或使用同样的资源。

⑦。

生产计划

▲

图2.2-1:业务过程模型

在一个完整的业务过程中，所说明的组成部分以及它们之间的内部关系包括：过程，大事，

状态，用户，组织单元，以及信息技术资源。假如考虑到每一大事的全部过程元素的可能产生的

结果，很可能会使模型大大简单化，并造成说明中的冗余。

为了降低这种简单性，全文被分为若干视图（参见图2.2-2:过程模型视图），用以说明离散型建

模和设计方面的问题。（见Scheer,《集成信息系统体系结构》1992,p.13ff.）,这些问题可

以（基本上）彼此独立地寻求解决方法。用这种方法来划分视图，尽管独立视图之间的联系较为

松散，但能使其组成部分之间紧密的联系起来。

数据视图

功能视图

组织视图

资源视图

图2.2-2:过程模型视图

类似于“已收的客户订单”或“已开发票”之类的大事对信息目标（数据）的状态差别进

行了定义。参考内容的状态，如“客户状态”或“产品状态”也可以以数据的形式来表示。像这

样，状态和大事就构成了ARIS体系的数据视图。

这些要被完成的功能（过程）以及它们的内部关系构成了另一个视图，及功能视图。这个视

图包括对功能本身的定义，总体关系之下独立的子功能的列举，以及功能之间存在的地位关系。

组织视图表现的是客户与组织单元之间的结合，同时也表现了它们之间的关系以及与之相关

的结构。

信息技术资源构成■第四个说明目标，即资源视图。而这一视图在为说明与业务更加直接相关的

成分供应一般条件的范围内，对业务过程中的相关观点是至关重要的。由于这一缘由，对其他视

图的成分说明（数据，功能，即组织结构）都是在它们与信息技术资源的接近基础上完成的。由

此，这些资源是在其他视图的设计法律规范和实施描述说明层次进行处理的（见其次章第三小

节）。因此，在对不同层次进行分析的基础上而定义的生命周期模型就可以取代作为独立说明对

象的资源视图。

把最初的过程划分为若干各子块会降低其简单性一纵然这要牺牲掉视图的过程成分之间的关

系。由于这一缘由，掌握视图的概念被作为一个额外的视图而引进于此。它的作用主要是说明视

图之间的关系。在一个独立的视图中，这种关系的集成使它有系统的介入系统分析，而不存在冗

余。

掌握视图是ARIS体系中的重要组成部分，也是ARIS体系与其它所提及的体系不同之处的

重要关键。（见Scheer,《集成信息系统体系结构》1992P24也，与其它体系之间的比

的。

这四个ARIS视图所形成的过程如图2.2-1:业务过程模型所示。这一过程将在以后的章节

里再作具体争论。

组织视图

数据视图■控制视图■功能视图

图2.2-3:过程模型的ARIS视图

2.3说明层次

如前所述，ARIS资源视图的结构布局是依据信息系统的说明层次的生命周期概念而形成

的。

生命周期模型的主要形式即层次或阶段概念，这种模型说明白一个信息系统的生命周期。然

而，ARIS生命周期模型没有流程模型那样的重要性，流程模型是用于开发独立的说明对象的。

它仅在它们与信息技术的近似性的基础上，对不同的说明层次进行了定义。

这种区分在ARIS三级模型，图2.3-1：信息系统的说明层次中有睨确的表达。（JiLScheer,

《集成信息系统体系结构》1992,p.16f.）.

整个系统的开发过程始于对业务操作问题的分析。这种分析基本上包含了整个被说明的业务

过程，这一过程在这里是以用户目标和用户所使用的语言为导向的。这一过程把信息技术技术选

择进行合并，以用来支持业务流程与决策。因此，只有半正式的说明语言被用来描述业务问题。

由于这种方法缺乏足够的细节，以及语言的高度专业化，所以在实施阶段不能被用作正式的说明

方法。

需求定义必需要把业务程序用正式的说明语言进行说明，这样才能使这一步成为需求定义到

信息技术的全都转换过程的动身点。这一过程也是建立（语义〕模型的过程。需求定义与问题说

明之间的联系是特别紧密的，这一点在图23-7:危息系统的说的层次中有着很好的表述。

当需求定义的概念环境完成了向IT导向的转变时，就达到了设计法律规范层。这里，模块

（或是说用户事务）是用来执行被定义功能功能的，而并不是功能本身。也可以认为这一层在信

息技术说明的总体方法中，是另一种形式的需求定义。因此，需求定义和设计法律规范之间的联

系是较为松懈的。这意味着设计法律规范可以在不影响需求定义的状况下做一些变动。然而，这

并不意味着需求定义和设计法律规范可以在彼此分别的状况下被制定出来。在完成需求定义之

后，把它的内容依据业务管理用这种方法来确定下来时特别重要的，这样外部面对IT的事项（比

如信息系统执行）对主题的内容就不会造成太大的影响了。

在实施描述层，设计法律规范已经被转换成为具体的软硬件组件。由此，与信息技术之间的

物理连接就完成了。

每个独立的说明层是以不同的更新周期来标识的。更新频度最高达到实施描述层，最低达到

需求定义层。

实施描述层与信息技术的开发过程联系特别紧密，并且由于信息技术的创新周期较短，往往

会用于进行修订。

需求定义层有着特别的重要性，由于它既是长期业务应用的贮藏室，同时也是更进•步的开

发实施描述的开头点。需求定义的生命周期是最长的，而且山于它与业务问题说明之间的亲密关

系，能够说明信息系统对企业的最大的好处。由于这一缘由，需求定义（或是语义模型）的开发

t的优先级是最高的。语义模型使用户和他们的初始应用IT相关语言来说明业务问题的过程之间

建立了联系。

需求定义

设计详述（面向门,的说明）

实施描述（在IT层）

图2.3-1:信息系统的说明层次

视图和说明层次的制造，以及初始业务问题的解决，构成了整个ARIS体系。如图2.3-2

ARIS体系结构所示，每一个说明视图都含有这三个层次，需求定义层，设计法律规范层，以及

实施描述层。

操作性的业务问题

图2.3-2:ARIS体系结构

随着ARIS体系结构的进展，以说明性的视图及层次来定义的说明视图也随之而固定下来。