指南:业务系统
业务系统代表企业内的一种独立能力。本指南说明如何确定业务系统并对它们建模。
关系
相关元素
主要描述

简介

业务系统代表企业内的一种独立能力。它们用于将企业结构划分为可管理的多块并了解它们,这在很大程度上与通常将组织划分为互相依赖的部门的方式相同。但是,某一组织的不同部分的角色和用途并不总是为该组织的其他部分所清楚,这导致在执行业务流程时交互达不到最佳效果。

业务系统使划分与互相依赖的概念更前进一步。业务系统不仅绑定并包含角色和资源(可能还有其他业务系统),还明确定义了接口或者可要求它们提供的一组服务或职责。为正式指定和管理部门与外部协作者之间交互而定义服务级别协议的组织,有效地定义了业务系统。业务系统常常与不同抽象程度的业务模型结合使用(请参阅概念:对大型组织建模)。

术语“业务系统”不应与软件系统混淆。业务系统包含人、硬件和软件,因此抽象程度比软件系统更高。

业务系统支持动态结构

在 Chris Marshall 的著作 Enterprise Modeling with UML 中,他指出,相对静态的传统组织结构对于正在出现的急剧分散和动态的业务世界来说已不够了。我们不能再指望组织的某一部分在很长时间内保持不变。正如他在他的著作中所说的那样,“价值是通过价值链创造和实现的,价值链会随着时间而形成和解体。实际上,为单个事务形成这种价值链的日子不会太远了。”

组织是有机的。当它们感到业务环境的压力在不断增加时,它们就需要适应这种情况以保持竞争性。在极端的情况下,静态的组织结构可能会在快速变化并且极端残酷的业务环境中举步维艰,公司可能需要转为动态结构以求生存。

在传统的静态组织结构中,部门界限只是概念性的。尽管这可能是“开放”和“非正式”组织的标志,但结果是组织中每个部门中的每个人都与组织的其他人员相互关联。更改或管理组织的一部分,使它们完全独立于其他部分,这变得非常困难。业务系统通过禁止业务系统之间的交互(除了通过预定义的接口)而增强了分区和界限。这些接口(可能使服务级别协议正式化)成为支持该组织的枢纽。业务系统之间的这些接口的最大优势在于,组织的不同部分之间是相互脱节的。依赖性是根据职责而不是根据 如何履行这些职责来定义的。

将职责的指定与职责的实现分开,并且将业务系统的用户与在其边界指定的服务绑定(而不是与业务系统边界内的实现元素绑定),就会产生一个灵活的组织 - 一个能迅速更改其结构而不会降低其流程性能的组织。在这样一个组织内,可以修改、改进或外包其中的一项功能(由业务系统定义),而对组织其余部分的整体影响保持最小。只要更改后的服务质量保持不变,业务运营就会保持连续。同样的工作可以由一个软件系统、一个人、或一整个部门(现场或远程)执行。

使用业务事件对交互进行抽象可以进一步减少各个业务系统之间的直接依赖关系。由于业务事件使时间和空间变得直观,各个业务系统可以进行间接交互(请参阅指南:业务事件)。

注:关于封装的 UML 建模指导信息

用 UML 对业务系统建模时,我们在工作产品:业务系统中的描述中指出,如果封装被视为不重要,则业务系统边界就是概念性的(如上面所讨论的传统静态组织结构),并且,至少针对交互目的而言,业务操作的过程中不存在业务系统。您可以通过说明业务系统(它是一种 UML 组件)不能直接进行实例化(它只能通过实例化它所包含的部分来生成),用 UML 指出这一点。在下一节中,讨论业务系统提供的服务:在这种情况下,我们考虑封装,并且可以通过使业务系统可直接实例化来指出它有多个概念性的边界。这验证:在分析和设计时,预计业务系统的边界在操作中将在一定程度上变得真实。

业务系统具有明确定义的职责

业务系统明确定义了可要求它们履行的职责(也称为服务)。这样指定行为是必要的,因为这允许解除上一节中所述的依赖性。 不定义服务的业务系统是毫无意义的。其他业务系统除了从该系统的名称来推断外,无法知道该系统提供哪些服务。例如,我们可能会指望一个“资源”业务系统(在部门术语中,它会被称为“资源管理”)提供以下服务:请求资源、查询资源可用性并可能查询资源类型或概要信息。

职责(或服务)定义与业务系统交互的方式,并被指定为该业务系统的接口的操作。这些接口是相关服务的集合,并同样描述业务系统可在特定交互中扮演的角色。在下一段后面的示例中,我们会知道每个接口都是一系列逻辑相关服务的集合。这些接口(职责群集)分配给负责履行这些职责的业务系统。当从业务系统外部请求所提供的服务之一时,业务系统内会发生一个事件来启动所请求服务的实现。这个事件(在业务系统内部)可以明确定义为一个业务事件。然后业务系统内的角色和资源(业务工作者和业务实体)就相互协作(在内部)来实现所请求的服务。如我们所看到的那样,这在很大程度上与企业为其客户服务的方式相同。实际上,我们甚至可以将业务系统建模为“企业”,在这种情况下,服务的请求者将是业务系统的业务参与者。

下面的示例显示了一个普通金融服务机构的业务系统。为了提高可理解性,只显示业务系统和接口之间的某些依赖性。根据该图,很明显可以重新分配职责,方式是将一个接口分配给另一个业务系统。从概念上说,这样重新分配职责对使用这些服务的业务系统不会有任何影响。

本图显示一个普通金融服务机构的业务系统。

注:关于服务的 UML 建模指导信息

上面已提到将业务系统建模为可直接实例化的组件,这就明确指出并不希望业务系统边界仅仅是概念性的。可以通过对业务系统的职责建模来继续此主题,此建模工作同样是通过应用 UML 2.0 Profile for Software Services 而进行的。尽管该概要文件是针对软件服务的,但其中的基本概念同样也适用于业务系统。使用 UML 2.0 端口对服务建模通过定义用户和用户系统之间清晰的交互点和明确定义的接口,进一步验证业务系统边界。这些交互点将业务系统职责的实施过程和将它们交付给业务系统外的消费者的过程完全分开。此方法还使业务流程分析人员以及业务设计人员能够灵活地将服务的组织和编排建模(以在业务系统边界提供增值服务)。

业务系统包含角色和资源

业务系统是对协作履行业务系统职责的人、硬件和软件的集合的抽象。因为我们不是按照人、机器和软件,而是按照角色和资源来描述业务系统内部的协作,所以使用词语“抽象”。 业务系统包含业务工作者和业务实体。如同我们在词汇表中所定义的,业务工作者是一个代表系统的角色。就业务建模工作而言,它是一个“叶”系统,即,它在业务建模工作中不能进一步分解。我们可以在业务建模研究中决定:

  • 一个人(或多个人)可以与特定业务工作者角色绑定,在这种情况下,可以将它构造为 <<worker>>
  • 该角色可以由软件(以及相关的可计算的硬件)来扮演,在这种情况下,可以将它构造为 <<IT system>>
  • 该角色可以由更复杂的系统扮演,该系统本身可以使用人、硬件和软件资源,但因为某些原因不能将它视为业务系统。例如,在下面的机场示例中,可以将业务系统“航班”建模为包含运送乘客的业务工作者,即飞机。飞机是独立的复杂系统,但分解它们及它们的行为和设计则需要业务思考模式上的重要转变。因此,在这种环境中,可以将它们保留为抽象概念(尽管我们肯定会关注于指定它们的某些特征,例如负载能力、范围和耗油量等等)并将它们构造为 <<system>>

业务实体是由业务工作者创建或操纵的一段信息。最终,可将这些业务工作者映射到人力资源,或映射到特定的硬件或软件系统。这种抽象能帮助我们专注于业务工作者的角色和接口并确定必要职责,而不用考虑特定人员或系统的实际情况(通常是有缺陷的)。

请注意,业务系统拥有的某些资源可能是虚拟的,例如,某个业务系统可以与其他业务系统共享一台大型机,但就这些业务系统而言,它们拥有一台虚拟机。虚拟资源的映射可以在拥有实际资源的级别上显示,在很多情况下,这将是企业级别(整个企业)。

业务用例超越业务系统

不得将业务用例仅分配到一个业务系统。业务用例是面向客户的流程,要求许多业务系统、合作伙伴和供应商协作。这称为价值链。业务系统协作执行业务用例,如下图所示。

本图显示客户、合作伙伴、监管机构和供应商之间的协作。

有一种例外情况:以不同的抽象程度创建业务模型时(请参阅概念:对大型组织建模),可以将业务用例分配到一个业务系统。例如,您可能想要将企业作为整体进行建模,以及对该企业的其中一个业务系统建模。在这种情况下,整个企业将有一个业务用例模型,其中整体业务用例将超越业务系统(如上所示)。在较低级别,从特定业务系统请求的服务可在业务系统的业务用例模型中捕获为业务用例。声明业务用例不应分配给一个业务系统的指示信息实际上说的是:“特定级别的业务用例不应完全只分配给一个较低级别的业务系统。”

业务用例的这种跨职能性质是组织们有兴趣进行业务建模和重新设计以及进行业务流程成本和绩效分析的原因之一(请参阅概念:基于活动的成本计算)。了解整个业务用例的成本与向客户提供的附加值如何相关,要比了解一个部门的年度预算与公司整体预算如何相关更有价值。

示例

家具商店

该图显示了在指南:业务目标指南:业务用例模型中用作示例的家具店的业务系统。该商店在陈列室自带的仓库中有着大量的库存。这使客户可以浏览陈列室中显示的产品并从仓库中取用他们已购买的产品。客户可以安排大宗商品的交货。

本图显示一家家具商店的业务系统。

此企业已分为三个互相依赖的业务系统。每个业务系统的用途都很清楚,并提供明确定义的服务(该图中不可见)。明确定义这些互相依赖性和交互性,有助于优化企业。

机场

机场向航空公司提供服务,并代表航空公司向乘客和游客提供服务。因为机场对于建模来说是一个非常大而复杂的企业,将其分为多个独立业务系统比较有意义。然后,每个业务系统可以独立建模为一个有自主权的企业,如下所示。

本图显示一家机场的业务系统。

在上面的示例中,我们看到航空公司将不得不参与“乘客”和“班机”系统。空中交通将按照法律法规受“空中交通管制”的控制。“机库设施”将向航空公司的地面员工提供服务。“乘客”和“班机”将分别使用“行李处理”提供的出发和抵达服务。娱乐业务系统也可以称为“机场设施”,将包括诸如商店、候机区、停车场和货运等设施。