CN102982398A - 用于识别基于服务识别指示符的候选服务的系统和/或方法及相关算法 - Google Patents

Abstract

特定的示例实施方式涉及从业务流程功能之间识别候选服务的算法和/或编程方法。在特定的示例实施方式，提供分析在面向服务的业务流程系统(SO-BPS)中可能展现为服务能力的业务流程模型的功能的方法。接收由多个对象定义的业务流程模型，每一所述的对象具有与此相关的元数据模型。在设计时间获得对于每个所述对象的业务流程分析智能。在运行时间获得对于每个所述对象的业务性能智能。对应于设计时间和运行时间聚集智能的指示符与用于相应的对象的元数据属性一起存储。通过SO-BPS的至少一个处理器，一个总体候选服务算法被应用于存储指示符以达到模型内的每个流程功能的总服务合格数值。

Description

用于识别基于服务识别指示符的候选服务的系统和/或方法及相关算法

技术领域

此处描述的特定的示例实施方式涉及从业务流程功能之间识别候选服务的算法和/或编程方法。在特定的示例实施方式中，提供用于聚集基于设计时间业务流程分析智能和运行时间业务性能智能的指示符，和用于每个模型对象的元数据属性存储这样的指示符，执行候选服务分析，和/或响应服务请求。

背景技术

业务流程是一系列企业任务，为生成有价值的输出给内部的或外部的客户的目的经常被承担。比如，业务流程可提供遍及时间、地方和功能的组织行为结构。业务流程已经成为描述、分析、执行和/或控制遍及部门、业务单元，和甚至业务伙伴的操作结构的选择方法。

业务流程管理（BPM）目的在于为了整个业务成功它们的改进。在其他的之中，软件激活业务流程自动化是提高执行流程的效率和有效性的手段。已经建立业务流程模型以指定遍及BMP项目的流程。为了自动化的目的，例如，他们在转化为可执行的（基于代码的）规范之前记录和构造流程信息。建模和转化通常是健全的自动化的先决条件。

业务流程模型帮助将业务流程的逻辑时间流程描述为图。它们可能帮助将流程活动形象化为图形符号，并可能将它们连接为线性次序或其他次序。逻辑运算符可以指示当流程分为选择的或平行的路径时，当它们再次汇合成一个路径时等。这种所谓的控制流程是业务流程模型的一部分。控制流程可以通过根据前景（perspective）不同的附加模型元素补充。例如，概念上组织的perspective把组织流程上下文作为目标，包括组织内的和组织之间的劳动分工、人工行为的相互作用、它们的技术支持、产品成果等。

建模语言EPC（事件驱动流程链）已经普遍作为用于该概念上的业务流程的事实上的标准。其由可靠的组织资源、需求的输入和产生的输出等补充流程活动，支持软件应用系统、组织目标、风险等。在逻辑流程上其也包含重要的信息，使它成为技术执行流程基础上的半正式要求，虽然即使通过非技术流程分析也相当容易使用。当将概念上的转化为技术上的业务流程模型，业务流程建模将组织设计的perspective转变为技术工程的perspective。

模型驱动流程自动化将在概念业务流程中描述的控制流程传送给技术业务流程模型。这里，可能通过技术信息进行补充，例如，执行期间用于存储流程信息的流程变量，用于用户相互作用的在线格式，异常事件及对应的处理，通信的方式（异步/同步），一致的数据交换，等等。为了使流程可执行，流程活动典型地被分配给自动软件功能或半自动用户界面。根据选择的建模语言和目标调度系统，这种转化会引起一个第二图示的图表（例如，以BPMN 2.0），直接进入一个基于代码的脚本（例如，XPDL,BPEL，或类似的）等。

产生的技术流程模型将被调度进入业务流程管理系统（BPMS）或工作流程管理系统（WFMS）的流程引擎，其考虑到有效地开始、执行并跟踪流程中的实例（instances）。

使用业务流程作为用于交叉应用软件系统的模型的想法与工作流程管理系统（WFMS）和企业应用集成(EAI)的概念一样陈旧。然而，使业务流程自动化成为真正的技术挑战的一个因素是，过剩杂散和沿着给定的流程流被集成和连接的逐渐分布的软件系统。

最近，面向服务的架构（SOAs）尝试满足这种集成挑战，通过定义完善的软件服务界面而陈列和集成远程软件功能。早期的拥护者，基于服务提供者和客户之间的所谓的“find-bind-execute”关系，将SOA看作为分布式的软件架构的一种特定设计。较新的观点提出对于为业务流程自动化提供的潜在的SOA的集成观念。它们有助于将流程自动化置于SOA讨论的中心。根据动态的业务要求，宽松地构成服务的性能为灵活地实施业务流程创建新途径。根据演变的业务要求，标准化服务界面的采用，允许在不同的业务流程中重用服务，以及灵活代替服务。在这种情况下，SOA被认为是一种范例，用于组织和利用可能被不同所有制领域控制下的分布式性能。

网络服务表现最近的面向服务软件技术的典型。与先前的服务技术不同，网络服务影响并促进协议和数据标准。

面向服务架构的科学论述和最好实践提供大量的面向服务的设计原理。当SOA方式加强得到确认的，面向界面的软件架构的一般原理、互操作性、自主性和模块性，还增加额外的面向流程的主题。

这样，面向服务的设计试图通过分开流程机构（例如流程流）和流程制度化（例如，执行流程活动的服务能力的选择）提高业务流程的灵活性。业务流程系统在多个方面得益于面向服务。第一，再访问流程结构为定义完全的，全面的功能界面做准备，允许即插即用（plug-and-play）服务以形成新的业务流程。第二，通过考虑流程制度化替代选择访问IT支持和技术基础设施，以及人员调配。它们影响成本效益和负载平衡及性能指标。第三，数据冗余和数据集成的方面对面向服务业务流程系统(SO-BPS)有兴趣，因为跨组织的服务规定提高数据冗余和数据控制的风险。

服务识别，其包括显得值得被展现为服务的定位流程活动，被认为是面向服务系统设计的一部分并且在概念和技术业务流程模型之间选择。另外，服务识别典型地是在SO-BPS工程中执行的第一概念活动的其中之一。识别候选服务的质量很大程度帮助确定总体系统的质量。该活动中的缺陷可能传播到所有后面的活动，可能引起加强成本的迭代。由于服务识别的潜在的高度影响，需要系统的和周密的技术。在不同的上下文中可以寻找潜在的服务功能。然而业务上下文设定结构和行为服务要求，IT上下文表现存在的软件系统如可能的服务提供者。但是，由于后者指IT库存分析，有忽略真正的业务需求的风险。因此，在这种情况下服务识别被任务将业务流程要求转化为定义完善的服务要求。

注意到多数现在的面向服务发展模型考虑业务流程模型。然而，本申请的发明人相信这些现在的方法没有一个指定哪些先决条件必须被业务流程模型满足以成为用于面向服务系统设计的合适的基础。实际上，它们必须满足一些最低的设计标准成为用于服务识别的可用的模型，作为用于服务构成和服务自动化的先决条件。

因此，服务识别保留纯粹的人工咨询服务，缺少任何系统的和定量的支持。服务识别已经被论述为多个学术上的面向服务发展模型的主要活动，但它几乎不被SOA管理软件所具有。即使这样，它们通常是模糊的指导，明显缺乏任何数量上评估候选服务的度量标准。一些服务识别方法没有考虑流程或业务结构，仅通过技术上分析用于服务展现的软件领域。现存很少的识别企业模型中的流程功能的服务合格性的方法被限制为一个服务设计原则（比如，数据凝聚）并且不影响存储在大量的业务流程架构模型中的上下文信息。这样，本申请的发明人相信没有一个现存的可用的工具和方法提供在业务流程功能之间识别候选服务的自动机制（比如，一种算法）。

发明内容

这样，本领域技术人员将理解到本领域中需要提供一种从业务流程功能之间识别候选服务的算法和/或编程方法的技术。

本发明的特定的示例实施方式的一方面涉及使用概念业务流程模型作为用于服务识别的全面和有用的信息基础。

本发明的特定的示例实施方式的一方面涉及一种从业务流程功能之间识别候选服务的算法和/或编程方法。

特定的示例实施方式的另一方面涉及将流程步骤评价为候选服务。

特定的示例实施方式的另一方面涉及提供用于服务计划管理流程的管理支持，然而也链接到业务流程模型并合并面向业务建模。

特定的示例实施方式的另一方面涉及支持用于服务识别的域构成（其描述来自业务流程的服务请求）的分析特征。

特定的示例实施方式的另一方面涉及用于业务驱动流程服务识别的一种算法和/或编程工具。

特定的示例实施方式还有另一方面涉及为可重用性指示符的标记。

特定的示例实施方式还有另一方面涉及识别具有由事件驱动流程链提供的丰富的业务语义的候选服务。

特定的示例实施方式又有另一方面涉及作为补充自顶向下流程分解和自底向上资产分析的第二活动的目标服务建模(GSM)。

特定的示例实施方式又有另一方面涉及确定或计算指示符，包括比如，流程指示符、数据指示符、管理指示符，及目标与事件指示符。

特定的示例实施方式又有另一方面涉及表示在服务识别和评价矩阵（SIEM）中确定的或计算的指示符。

特定的示例实施方式又有另一方面涉及应用一个公式测量确定的或计算的指示符以达到说明总体服务合格的分数。

特定的示例实施方式又有另一方面涉及将总体服务合格分数与一个阈值比较，例如，过滤掉不合适作为服务合格的候选的功能。

在特定的示例实施方式中，提供分析可能在面向服务的业务流程系统中展现为服务能力的业务流程模型的功能的方法。接收由多个对象定义的业务流程模型，每一所述的对象具有与其相关的元数据属性。在设计时间获得用于每个所述对象的业务流程分析智能（intelligence）。在运行时间获得用于每个所述对象的业务性能智能（intelligence）。存储对应于设计时间和运行时间聚集的智能的指示符连同用于相应对象的元数据属性。通过面向服务业务流程系统的至少一个处理器，总体的候选服务算法被应用于存储指示符以达到对于模型中每一流程功能的总的服务合格数值。

根据特定的示例实施方式,通过推荐至少一个具有足够高的总服务合格数值的流程功能，可能响应一个候选服务请求。

根据特定的示例实施方式,所述指示符包括或由流程指示符、数据指示符、组织指示符，以及目标与事件指示符构成。根据特定另外的示例实施方式,所述指示符包括或由至少一个用于模型中功能的可重用性指示符、至少一个用于模型中功能的数据耦合指示符、至少一个用于模型中功能的数据凝聚指示符、至少一个用于模型中功能的利益相关者集成指示符、至少一个用于模型中功能的组织参与指示符、至少一个用于服务合格性的面向目标的指示符、和/或至少一个用于服务关联的面向事件的指示符组成。根据特定的示例实施方式,总服务合格数值可能是加权的指示符的组合，并且权值可能对应于一个或更多通过生成的面向服务的业务流程系统达到的目标。如一个例子，所述总体候选服务算法包括，对于每个所述功能，将在预定的时间段内所述功能的预期可重用性、所述功能的数据凝聚、分别表明可以任务外包给利益相关者并对利益相关者可见的所述功能的执行范围的任务外包和可见性变量相加获得第一值。通过从第一值减去用于功能的数据耦合度（degree）、包含在功能中的组织单位的最大数，和包含在功能中的应用系统的最大数获得第二值，并且将第二值乘以用于功能的业务关联指示符以获得用于功能的总服务合格数值。根据特定的示例实施方式,如果用于功能的总服务合格数值超过预定的阈值，功能可能被展现为服务能力。

根据特定的示例实施方式,所述设计时间智能可能由可执行程序逻辑聚集比如，编写脚本的宏命令或报告，和/或所述运行时间智能可能通过到流程监控工具的界面或其他可执行程序逻辑聚集。

根据特定的示例实施方式,用于流程功能的总服务合格数值可能被排名。比如，排名的总服务合格数值可能基于排名被组织为和/或表现为组。在特定情况下，所述组可能被形成为近似正态分布。

在特定的示例实施方式中，提供定义或改善业务流程模型的方法。业务流程模型的至少一部分的表征被图解地显示在计算机系统的显示器上，这部分包括多个对象。用户能够通过用户界面选择模型的对象。通过用户界面响应接收的用户请求，已选的对象的元数据属性显示在计算机系统的显示器上。对应于聚集的业务流程分析智能和/或聚集的业务性能智能的指示符与元数据属性一起以矩阵格式显示。通过至少一个用于模型中每一流程功能的处理器基于指示符的加权总和计算总服务合格数值。在设计时间通过编写脚本的宏命令或报告聚集对应于业务流程分析智能的指示符并且在运行时间通过到流程监控工具的一个界面聚集对应于业务性能智能的指示符。

根据特定的示例实施方式,可能从用户接收到服务的请求，和/或显示给用户至少一个候选服务作为请求的结果。在特定例子中，这可能包括显示多个候选服务。比如，所述候选服务可能基于它们各自的总服务合格数值被排序。在某些情况下，只要超过预定的阈值，每一所述的候选服务被显示。在其他示例例子中，一个候选服务被精确地显示，该显示的候选服务对应于具有最高总服务合格数值的功能。

特定的示例实施方式也提供用于执行上述的和/或其他的方法的永久计算机可读存储介质无形存储的指令。

特定的示例实施方式也提供类似的系统。比如，特定的示例实施方式涉及分析可能用于展现为服务能力的业务流程模型的功能的面向服务的业务流程系统。永久计算机可读存储介质包括业务流程模型的表征，该业务流程模型由多个对象定义。每一个所述对象具有与此相关的元数据属性，并且元数据属性也存储在计算机可读存储介质中。第一计算机可执行智能聚集模块被配置为在设计时间获得对于每个所述对象的业务流程分析智能。第二计算机可执行智能聚集模块被配置为在运行时间获得对于每个所述对象的流程性能智能。计算机可执行分析模块被配置为(a)接收对应于设计时间和运行时间聚集智能的指示符，和(b)在一些或所有指示符上应用候选服务算法以达到用于模型中每一流程功能的总服务合格数值。所述模块可通过系统的至少一个处理器执行。

这些方面和示例实施方式可以分别以多种结合使用和/或应用以实现本发明的更进一步的实施例。

附图说明

通过参考以下示例说明的实施例的详细描述并结合附图可以更好并且更完全地理解这些或其他特征及优点，其为：

图1是根据特定的示例实施方式说明的服务识别和评价矩阵；

图2以三层详图说明示例的学习管理流程层级；

图3说明对图2例子的能力计划和发展的示例流程；

图4A-4D说明从端对端学习管理流程的示例并在两个示例叶子层EPC图表上提供详细的观点。

图5显示示例的服务合格分析的结果，包括总体分布和平均值；

图6是特定的示例实施方式的技术结构的高层概观；

图7是根据特定的示例实施方式显示聚集的服务指示符怎样保持在元数据属性中的示例屏幕截图；

图8是根据特定的示例实施方式显示怎样开始新的服务请求的示例屏幕截图；且

图9是说明在设计时间和运行时间两者特定的示例实施方式的技术方法的更详细的图表。

具体实施方式

特定的示例实施方式包括多角度的合格指示符，功能粒度识别，面向流程可重用性识别，面向数据自主识别，面向组织/利益相关者识别，业务关联的面向目标识别，业务服务的面向事件驱动识别，服务合格性，和/或业务服务标准的合并。

在特定的示例实施方式中，可能需要分析多角度合格指示符。比如，承认服务设计的面向业务的值，SO-BPS方法可能基于业务流程层级的最低层从自顶向下业务服务识别开始，提供业务流程模型。

因为流程改进（例如，减少现存的流程低效率）是采用面向服务的驱动，许多SO-BPS工程将是业务流程优化的工程。但是，不需要总是尽所有努力配置全部范围的传统业务流程优化技术。因此，在特定的示例实施方式中，通过清楚推荐使用业务流程层级的规定，其足够详细地记载当前操作的当前状态（如，符合建模常规），忽视了“就是（as-is）”相对“成为（to-be）”模型的问题，虽然假设业务流程在结构上有效率（例如，没有瓶颈，连续的而不是并行处理，等）。因此，业务服务识别的基础可能被看作以高质量操作为特征的就是（as-is）业务流程模型。

高质量服务设计的一个标准表明（基本的）服务包括组织单元、法律约束、来自更新的数据、产品和市场的主数据，以及不同的垂直整合层级。这种观点认为有利于业务流程模型的多角度分析以获得优越的（或至少改进的）候选服务。相应地，指导可能随SO-BPS观点被结构化，例如，如下文的介绍和详细说明。

这样，在特定的示例实施方式中，可能需要实施功能粒度识别。作为一个SOA设计原则，抽象和业务流程定向经常被转化为粗的符合多个要求的面向业务粒度。然而，过分粗的粒度阻碍服务的一般可复用性，其是另一个至关重要的设计目标。细粒度和粗粒度服务之间的权衡已经被许多处理但还没有解决。小的服务的优点是它们的可变性和可重用性而促进更多适合的系统。但是，该灵活性伴随以由大量难以管理的服务引起的复杂性的形式的代价。

但是，粗粒度的服务只允许一些只在特定情况下适合的目的构建使用例子。一旦初始的情况改变，可能需要实施新的服务，经常提供多余的功能。总的来说，在SO-BPS设计中识别正确的粒度的程度是一项复杂的任务，并且不一定具有用于所有服务的单一的正确的大小。业务流程分解已经产生最细的粒度，还有业务相关功能。这样，向要求定向（例如，抽象和业务流程定向）提供的设计准则两者已经被处理。在最终定制候选服务完成的功能之前，将需要处理流程自主性和模块性的原则。向自主性原则提供高凝聚和松耦合，从社会网络分析或基于构件的软件设计得知的聚集技术可能被用于业务流程模型。可能通过删除具有最高“中间性（betweenness）”的边缘来聚集业务流程功能，或在离开它的一对顶点（业务活动，IT系统等）之间的最短路径的数目。产生的群集可能包括形成服务的好的服务操作候选。

在特定的例子中，需要考虑面向流程的可重用性，例如，当一个SO-BPS内的服务识别涉及许多或所有业务流程时。为了识别各自的服务能力功能的可重用性，可能分析遍及给定的多个流程模型集的功能的流程相互依赖性。多个业务流程上相同功能出现的数目可以帮助指示在不同业务上下文中它的可重用性。这个分析的一个先决条件可能是同样的功能具有同样的名称以使语义上相等的功能可能通过比较它们的标签识别。两个相同的功能共享同样的输入和输出数据。只要相同的数据对象具有相同的名称，比较输入输出数据是检查相同功能的另一种方法。流程建模环境，比如ARIS业务架构支持相同功能对象的多个出现。这样，同样的活动可能不需要人工定位和计算。

功能的可重用性可能接近于随时间的过程（如，在运行时间期间）功能的频率的进一步评定。因此，可能需要流程实例的函数关系（history）。用任何类型的软件支持记录流程性能并分析流程实例是最可行的。但是，不大可能一致地监控以人工活动和自我组织为特征的知识密集型的业务流程。面试知识工作者引起他们典型的工作行为可能提供需要的数据。不同事件的数目引起遍及所有发生的功能给评定带来另一种质量，因为不同的引起的事件表明功能的甚至更高的可重用性。同样地，一个功能被不同组织的或应用资源的多种使用也证明其可复用性。以下示例语句定义功能可复用性的示例的指示符并将它们概括为总的可复用性指示符：

Occ(F_i)=遍及所有流程模型的功能i的发生数目

OrgRe(F_i)=提供遍及所有发生的功能i的不同组织单元的数目

AppRe(F_i)=支持遍及所有发生的功能i的不同应用系统的数目

Invoc(F_i，t)=功能i随时间t过程的调用的数目

Reuse(F_i,t)=Occ(F_i)+Invoc(F_i，t)+OrgRe(F_i)+AppRe(F_i)

F_i:功能i

Reuse(F_i,t):功能i随时间t过程的期望的可复用性

凝聚和耦合的服务准则不仅涉及功能方面，还涉及数据交换的方面和交换的数据对象的复杂性。一种方法可能通过评估它的数据交换行为测量功能的耦合度。较少的功能使用同样的数据对象并且较不复杂的共享数据对象是倾向于更松的功能的耦合。共享数据对象的复杂性可能由在数据模型内建模时的相互关系的数据确定。当要求提高的总体性能时，作为一个副作用，输入输出数据的低复杂性涉及较低的数据量。以下示例语句定义功能数据耦合的示例指示符：

DataCoupling(F_i)=|S_ia|+∑C(S_ij)

S_ij=D_i ∩D_j

$S_i=\underset{j}{\∪}{S}_{\mathrm{ij}}$

Fi:功能i

Di:功能i使用的数据对象集

Da:使用中的所有数据对象集

C(S_ij)∈N:数据复杂性的程度，或集S_ij的数据对象之间的关系的数目DataCoupling(Fi)∈N:功能i的数据耦合度

关于功能的自主性的进一步指示由功能使用的数据对象的凝聚给定。可以基于数据对象之间的相互关系的数量导出凝聚的数值。潜在的假设是一个功能可以被认为是凝聚的，如果它的数据对象相互之间具有很少的关系。通过从数据对象的数目的减法使关系的数目正常化得出指示凝聚度的值。以下示例语句定义功能数据耦合的指示符：

DataCohesion(F_i)=N_i-K_i

K_i=C(D_i)

N_i=|D_i|

D_i=ID_i∪OD_i:

|D_i|∈N:功能i使用的数据对象的数目

ID_i:功能i的输入数据的集

OD_i:功能i的输出数据的集

D_i：功能i使用的数据对象的集

DataCohesion(F_i):功能i的数据凝聚

一个功能在其上操作的数据对象的数目可能是用于服务合格性的附加的指示符。在特定情况下，它可能仅仅是一个输入和一个输出数据对象。该约束对应于服务粒度足够细以描述业务对象上的所有流程步骤的准则。除此之外，主数据对象和库存（inventory）数据对象可能由不同的服务处理。面向界面进一步要求对输入和输出参数的清楚定义。这样，一般情况下，数据对象可以由潜在的数据模型指定。

除了其他方面，面向服务系统的分布涉及提供、代理或消费服务的不同的组织和技术资源。组织单元假设这三个任务中的一个可以被认为是利益相关者。然而存在的面向服务流程模型趋向于忽略不同利益相关者的角度，一个组织服务识别方法集中在一个利益相关者的角度。利用对客户集成的服务市场研究，可能应用“相互作用的行（line of interaction）”和“可见性的行（line of visibility）”作为为服务识别提出的标准的理论基础。接着这个论证，用于功能的服务合格性的标准是它要么能够被利益相关者接收（将向利益相关者的相互关系的行移位）或要么（部分的）它能够或必须对利益相关者可见。这样，“任务外包”和“可见性”标准评定可向利益相关者任务外包的功能的执行程度或至少对它们可见。然而技术服务设计标准典型地仅最低限度地考虑，在此描述的示例方法可能考虑可能的服务脚本和它们期望的业务值。服务用户的集成涉及介入服务执行的外部因素，如广泛保持在服务市场规律中的概念。从测量的观点，任务外包的合格性或将功能开放给服务利益相关者难于以数值表示。以下示例语句将任务外包和可见性定义为二进制变量：

Outtasking(F_i)∈{0,1}

Visibility(F_i)∈{0,1}

在可能的利益相关者集成的评定之外，组织单位的数量也表示潜在相关的指示符。没有涉及的组织单位意味着完全自动化。如果只附上一个组织单位（并且没有应用系统），可以任务功能是人工任务。半自动功能可能具有分配的组织单位和应用系统两者。超过一个组织单位的参与可以表明团队合作。功能可能被分配给一个组织单位、一个应用系统类型，或两者的结合。多个组织单位或应用系统类型有时可能被认为是分解的原因。以下示例语句定义用于组织和应用资源的变量包括：

OrgOcc(F_i,P_i)∈N:包含在程序j中发生的功能i中的组织单位的数目

AppOcc(F_i,P_i)∈N:包含在程序j中发生的功能i中的应用系统的数目

然而附属于多个应用系统类型的功能可能是可分解的，团队功能（例如，多个组织单位）可能意味着合作的工作，有时难以进一步分开。这样的任务可能被展示为人工团体服务或通过使用减少参与的人数（例如，流程制度化的更新）的软件检查（半）自动化。人工活动（例如，人工服务）能通过细粒度软件服务进一步支持。

在判断SO-BPS的预算和发展中，经常需要满足业务目标和目的。就像任何其他投资，逐渐希望SO-BPS在不间断的基础上显示它们的价值给企业。为了弥合业务主题和服务实现之间的差别并为商业驱动提供服务的可追踪性，特定的示例实施方式涉及目标－服务模型（GSM）作为第二活动补充自顶向下流程分解和自底向上的资产分析。

示例的GSM技术随着业务流程模型有效工作。在某些情况下，每个流程步骤支持至少一个业务目标并且每个业务目标由至少一个功能支持。通过服务能力和流程功能之间的关系补充允许越过功能传递地分配业务对象给服务的依赖性。比如，ARIS方法包括目标建模并提出目标层级，其将一个次要的目标与多个主要的目标连接的并将目标分配给提供足够支持的功能。可靠的业务流程分析程序可能以说明组织的目的开始。因为高层的团体目标经常以对于服务识别太高级的方式规定，可取的是将这些目标分解为子目标并保持分解指导子目标是可执行的。可执行的子目标能够在，例如，能识别的支持该可执行的子目标的功能上执行。

功能链接到业务目标然后将具有为服务实现被优先化的较高概率并且为后来的设计和执行储备。这允许使用GSM作为范围界定机制，通过检测在商业方面提供最高影响的功能区域降低SO-BPS问题域的复杂性。以下示例语句将业务目标关联定义为用于服务合格性的指示符：

BOR(F_i)∈{1,2,3}

BOR(F_i):功能i的业务目的关联

面向事件的流程建模和事件处理暗示业务事件的特殊考虑。至少有两种考虑业务事件的服务识别的方法。一种可以通过聚集在相同时间处理的数据属性（由相同的业务事件引起）识别数据服务操作。对于每个聚集的数据属性的集，创建数据服务操作。此外，这个概念提出用于定义离散业务服务的自顶向下事件驱动方法。识别非平凡的，重大的业务事件包括足够的业务响应（例如，由事件引起的功能）。那些事件响应定义界面设计（例如，服务能力）的请求。

在事件的基础上开始服务识别提供用于服务的另外的途径，在向可能完全的，充足的请求的路径的基础上。因此，业务事件被识别并检查响应功能。与业务事件相关的功能商业价值提高并且因此合格性优先化。不像其他的面向事件值，这里没有指出功能的潜在的可复用性而指出它的业务关联。它加入由业务目的驱动的业务关联。以下示例语句定义功能的业务事件关联：

BER(F_i)∈N

BER(F_i):业务事件功能i响应的数目

Bu siness Relevance(F_i)=BER(F_i)+BOR(F_i)

假如混合的概观在所有服务合格性的视角上，每一个指示符可能被记录在服务识别矩阵中。服务识别和评估矩阵（SIEM）可能采用先前分析的离散指示符的值并执行计算，例如，将它们转换为大小上合格的值。因此，在特定的示例实施方式中，提出具有配置参数的加法公式。可能为服务合格性评估最低层级的层（并且它们不是发生在流程的上下文中）的功能类型。这个方法背后的基本原理是不是一个特定流程内的单一的发生，而是在多个流程内的该功能的全部使用应该决定服务合格性。基于指示符的方法开始强调标准的重要性的服务检验的观点，允许候选服务的优先化并且在当前的程序范围取消记录证实（documented justification），但在另一未来的范围内相关。

图1是根据特定的示例实施方式说明的服务识别和评价矩阵。图1中的行对应于功能，而方块被分成流程指示符、数据指示符、组织指示符及目标与事件指示符。如上所指，这些类别中的值叠加地结合计算表明总服务合格的数量。

求和的合格公式的设计取决于，比如各个程序对象的因素。在执行公式设计之前，需要考虑特定的SO-BPS环境、目标和其他相关和特定的因素。如果B2B脚本对SO-BPS程序是重要的，比如，任务外包和可用性的值可能被大程度地加权而高于在纯合并程序中，目的在于移除冗余。在该分析中，下面提出的示例的总体服务合格公式是基于业务校准是全部目的的假设。这意味着候选服务必须是校准的业务（例如，可向后追踪至业务目标）。该业务目标的优先级越高，服务的合格值越高。

ServiceEligibility(F_i)=

BusinessRelevance(F_i)[Reuse(F_i，t)-DataCoupling(F_i)+DataCohesion(F_i)+

Outtasking(F_i)+Visibility(F_i)-maxOrgOcc(F_i)-maxAppOcc(F_i)]

用于每个功能的该示例公式的结果决定表现为服务能力的每个功能的合格性。已经确定一个临界值k，可以通过过滤掉那些具有高于k的合格值的功能导出一列合格服务能力。

由于已经确定一列服务合格功能，就规定了相应的服务能力类型。服务能力类型可能表示还没有被执行或选择的请求的服务类型的服务功能。多个服务能力类型可能构成一个充当容器的服务类型。这符合为业务流程设计选择的类型级别建模方法。每个服务能力类型可能用详细请求可能的服务实现来补充。

示例

基于上述服务指示符的概念，现在将提供它们怎样用于共同的学习管理程序的域中的说明，作为示例的实现。当然，将注意到其他的服务指示符和/或累加的技术可能被使用于与示例实现相关。此外，将注意到相同或不同的服务指示符和/或累加技术可能应用于不同的实现。

该例子开始于设置用于学习管理的面向服务流程架构。这个尝试以多个步骤完成，包括以基于指示符的服务识别和评价矩阵(SIEM)识别请求的服务能力作为关键任务。图2以三层详图说明示例的学习管理流程层级。第二层的子程序是面向流程从属于顶层阶段并且可能出故障甚至进一步进入第三层子程序。色彩较暗的元素代表形成端对端流程的例子，指在该分段的余数中作为计划流程的能力。如小的分配图标指出的，第三层级通过分配给相应的子流程元素的事件驱动流程链被进一步细化。由于这也是叶子层，它们在后来的分段中被描述和设计。

·能力需求分析识别基于战略业务目的的能力情求。将业务目的映射为业务操作，业务流程为收集能力需求提供可靠的基础。工作说明和作用定义也可能有助于引出尽可能多的各个员工的职业目标的流程。一旦识别，根据预先定义的结构指定能力请求。为允许专用的性能提高，根据对业务目标的影响优先化能力。能力优先化的其他方面可能是培训成本，培训有效性，或时间限制。

·能力管理以请求的能力匹配可用的能力以识别能力差别。作为一个先决条件，就是（as-is）能力已经被评估。关于能力差别的识别支持对员工安之和作用分配的知情决策多达在个人的和组织层面上的进一步能力目标的定义。

·能力目标汇入课程计划活动，通过需求驱动学习设计设法克服能力差距。教育和沟通概念结合能力目标。目前的学习设计为能力发展（例如，学习机会利用）开发。

·学习单元成果产生用于计划课程的学习内容或再利用与学习设计的能力目标匹配的现存的内容。为单独的学习设计因素设定学习内容产生将准备执行的学习单元。

·学习课程操作为各个员工提供学习单元，由管理和技术支持促进。学习评价活动确定学习者的进步并帮助使学习课程适应于各个需要。

·评价测量学习对个人和组织两个层面的性能的影响。层面确定信息检索和分析的方法。一方面，调查允许评价个人的学习性能。另一方面，在流程层面上，流程监控传递性能数据。评价结果表明重新设计活动的需要和类型。

在图3中，遍及所有六个子流程的所有说明的端对端流程已经被指出和标记为色彩较暗的子流程元素。它表示集中于能力计划和发展的学习管理的特定的使用例子。它以完全的能力需求分析开始引起能力需求（例如，从业务流程）（流程驱动能力分析）并根据它们在流程性能（能力模拟）上的影响将它们排列顺序。基于员工能力配置文件（能力评估）第三子流程将能力需求与能力可用性合并并且匹配它们的作用的就是（as-is）能力和成为（to-be）能力（能力差距分析）。产生的能力差距设置理想的能力目标，其可能通过面向能力流程模拟改善。每个作用的能力目标记录在送入课程计划的能力计划中。这里，以能力注解（annotation）为基础，对可重用的学习设计（如，教学模板）进行检查（学习设计检查）。它们被加入能力计划并由新的学习设计补充（学习设计创建）。在成为可开展之前，这些学习设计通过学习内容丰富，其总是可用的或特别地产生（创建学习内容）。集成学习内容为学习设计引起新的补充能力计划的学习单元。

接着所述能力计划流程，能力计划被传送给学习课程操作阶段，其中学习单元经过员工具体化为学习课程。在执行包括评估的学习课程后，学习性能和流程性能相对于业务目标评估。性能结果送入总体业务性能评估。来自业务和最佳化目标的偏差使人想到对流程和学习设计再次进行改进措施。

图4A-4D说明从端对端学习管理流程的示例并在两个示例叶子层EPC图表上提供详细的观点。每个流程功能的流程内容规定在分配的功能分配表(FAD)中。它们给出执行功能的组织单元的信息，应用系统支持功能，及功能的数据输入和输出，而且业务目标由功能和涉及执行功能的能力支持。人员类型（组织单元）和应用系统也出现在EPC图表中，提供当前流程制度化的直接的信息。自动化的程度通过分配的不同资源类型加重。人工功能仅具有分配的组织单元，自动功能仅具有分配的应用系统，且半自动功能具有两种分配的资源类型。此外，数据元素被集成为总的企业资源管理（ERM）数据模型。

对于这个例子，已经制定学习管理流程，下一个任务是识别流程结构请求的服务能力。根据上述示例的SO-BPS方法提出的指示符和公式，遍及所有流程模型计算并分析每一个流程功能的服务合格数值。

产生的服务合格的值概略地呈现正态分布，允许将流程功能分类为四种类别，如图5所示。81个流程功能以外，五个以上归类于达到6的值的类别A。流程功能“确定流程差距”甚至达到11的服务合格数值。A功能的集较优因为它们的高可复用性、服务外包和高可用性值。63功能中的大多数传递高于2低于6的值。它们被分为两个类别。B功能的特征是4和5的服务合格。C功能的特征是3和2的服务合格。这两个中间类别显示平均的可重用性和不同的可见性/服务外包值。少数14功能测量小于1服务合格点并被归类为D功能。它们较低的值一方面起因于较低的可重用性并且另一方面起因于0可见性和服务外包值。

图5示例分析表明与该例子研究的特定的域相联的一些总的结论。可重用性值，尤其是发生，表现的相当低。原因可能是在该例子研究中的选择的端对端流程的限制的范围。假设学习管理架构的相邻的子流程的包含（如，HR流程，事件管理流程，业务战略流程）是合理的，就会如有效效应理论建议，提高流程功能的预期的可重用性。

并且，数据耦合值随着大多数流程功能是相当恒定的，达到1或2的值。这通过一个功能的大多数输入和输出被至少一个其他的功能使用的事实来解释。而且，随着大多数流程功能具有一个输入目标和一个输出目标，这个重叠也均等在2。然而，数据凝聚值是非常低的，因为在基本的数据模型中大多数输入和输出对象不是直接相关的。

相当低的任务外包值起因于流程的知识强度。一个组织发展符合业务目标的员工能力的能力相对于竞争者是明显不同的。并且，学习管理流程通常适合灵敏的员工数据。还有，知识密集的任务通常非常专业并难以由其他进行。由于这个原因，组织不愿外包这些任务，导致低平均值的任务外包可能。

另一方面，可见性达到相当高的值。这可能在员工参与的上下文中理解，并且通常通过学习管理的合作特征理解。前者引起员工的通知，关于新的学习机会，关于他们的能力大致状况，关于他们在学习课程中的参与等。与学习供应商的合作要求一致的信息交换，其通过通知服务能力可行。

参加的组织单元的组织指示符和应用系统阐明进一步的服务设计决定。全部的高值提示进一步的功能分解能力。三个或更多的应用系统的参与说明（技术）服务构成，其可能由附加的子流程准备。然而，两个应用系统的发生参加一个流程功能通常表明数据交换。在这种情况下，技术设计可能决定服务任务，例如，系统提供的和消耗服务的任务。但是，一组人员参与者表明高度的合作，可能没有通过约定的流程逻辑解决。反而，这个流程功能可能标记为人工服务的很有可能的候选。

一旦流程功能已经对它们的合格性分析，它们可能被分类为数据服务、任务服务和人工服务。以下表1提供被识别的功能的概观，包括它们的等级和分类。即，评估类别提供在下面的括号内。数据服务能力由附加的目前在流程模型中缺少的数据操作功能补充。它们可能帮助促进学习管理流程的未来的变化。

表1：软件服务能力合格的流程功能－分类和评估

特定的示例实施方式可能被认为包括图6中显示的技术结构。换句话说，特定的示例实施方式与BPM系统相关通过第一检查业务流程分析智能（从设计时间）和业务性能智能（从运行时间）来操作。更新每个模型对象的元数据属性以便包括对应于设计时间和/或运行时间聚集智能的指示符。使用存储元数据属性的指示符执行候选服务分析。然后产生服务请求报告。

在特定的示例实施方式中，注意到可能提供基于知识库的模型工具（比如ARIS平台）允许分析模型产品和流程模型之间的依赖性。同样地，在特定的示例实施方式中，可能提供允许流程实例监控和性能管理的流程监控软件系统（例如，ARIS PPM）。

由于基于总体模型网络的分析计算一些变量，可能编写宏命令或报告以提供所需的设计时间数据。比如，脚本可能为功能的可变的Occ()提供遍及所有流程模型的该功能的发生数目。这样，可能提供业务流程分析智能。

由于一些变量依靠运行时间流程数据，可能发展流程监控工具（比如ARISPPM）的界面。比如，然后它可能提供随时间t的过程调用功能i的数目到EPC功能的可变的Invoc()。这样，可以提供流程性能分析智能。

涉及计算服务指示符（如上述的）的变量可能被保持在每个模型产品的元数据属性集中。因此，它们可能被人工地或通过使用智能工具自动地保持。在特定的示例实施方式中,变量如服务外包outtasking()或可见性visibility()可能被人工地保持，然而其他的可能从运行时间数据或模型网络分析恢复。这样，可以提供元数据属性。例如，图7是根据特定的示例实施方式显示聚集的服务指示符怎样保持在元数据属性中的示例屏幕截图。在图7中，用于说明的“开始提供”服务的元数据参数被保持并且包括上文识别的示例指示符。

总体合格性算法可能作为脚本执行，在EPC功能集上运行，并且将它们的变量作为输入。它可以计算每个功能的单个的服务合格数值并相应地将它们排序。可能根据总体服务合格性公式用加权值做出这个计算。比如，该权值可能取决于用生成的面向服务流程系统达到的目标。取决于总体服务合格数值，流程功能可能有资格作为可持续的候选服务并且相应地期望在下一步骤的服务发展。

为了请求顶层候选服务的发展，报告可能收集在相应的EPC功能的上下文中建模的所有信息并且将它们作为要求说明文件提供。例如，图8是根据特定的示例实施方式显示怎样开始新的服务请求的示例屏幕截图。

图9是说明在设计时间和运行时间两者特定的示例实施方式的技术方法的更详细的图表。如图9所示，一个流程在运行时间，在企业服务总线（ESB）上执行。但是，在设计时间，定义了业务流程。图9示例包括三个流程，每一个包含多个功能和服务。可能在定义的流程上执行业务流程分析，例如，在设计时间。同样地，可能在定义的流程上执行业务性能分析，例如，在运行时间。可能聚集指示符以形成SIEM，其可能与选择的功能、服务或其他来自一个或更多定义的流程内的结构的元数据属性一起存储。可能将一个公式应用于指示符以创建总的服务合格数值，例如，作为候选服务分析的一部分。这个计算可能帮助相应服务请求，例如，通过查找匹配的候选服务，然后可能在运行时间通过ESN上的流程实施或执行。

将理解到如此处使用的术语系统、子系统、服务、编程逻辑电路，和诸如此类的可能作为软件、硬件、固件和/或诸如此类的任何适当的结合被实施。也将理解到此处的存储位置可能是磁盘驱动设备、内存位置、固态驱动器、CD-ROM、DVD、磁带备份、存储区域网（SAN）系统和/或任何其他的适当的有形计算机可读存储介质的任何适当的组合。也将理解到此处描述的技术通过使处理器执行可能无形地存储在计算机可读存储介质上的指令来实现。

尽管本发明已经被描述为关于目前被认为是最实用的和较优的实施例，要理解本发明不限于公开的实施例，而相反意在覆盖包含在附加的权利要求的精神实质和范围内的多种修改和相等的设置。

Claims (30)

1.一种在面向服务业务流程系统中分析可能展现为服务能力的业务流程模型的功能的方法，所述方法包括：

接收由多个对象定义的业务流程模型，每个所述的对象具有与其相关的元数据属性；

在设计时间获得用于每个所述对象的业务流程分析智能；

在运行时间获得用于每个所述对象的业务性能智能；

存储对应于所述设计时间和运行时间聚集智能的指示符连同用于相应对象的元数据属性；以及

通过面向服务业务流程系统的至少一个处理器，将一个总体的候选服务算法应用于存储指示符以达到对于所述模型中每一流程功能的总的服务合格数值。

2.根据权利要求1所述的方法，进一步包括通过推荐至少一个具有足够高的总服务合格数值的流程功能来响应一个候选服务请求。

3.根据权利要求1所述的方法，其中所述指示符包括流程指示符、数据指示符、组织指示符，以及目标与事件指示符。

4.根据权利要求3所述的方法，其中每一总服务合格数值是相关指示符的加权组合。

5.根据权利要求4所述的方法，其中所述权值对应于一个或更多通过生成的面向服务的业务流程系统达到的目标。

6.根据权利要求1所述的方法，其中所述指示符包括至少一个用于所述模型中的功能的可重用性指示符、至少一个用于所述模型中的功能的数据耦合指示符、至少一个用于所述模型中的功能的数据凝聚指示符、至少一个用于所述模型中的功能的利益相关者集成指示符、至少一个用于所述模型中的功能的组织参与指示符、至少一个用于服务合格性的面向目标的指示符、和/或至少一个用于服务关联的面向事件的指示符。

7.根据权利要求6所述的方法，其中所述总服务合格数值是所述指示符的加权组合。

8.根据权利要求7所述的方法，其中所述权值对应于一个或更多通过生成的面向服务的业务流程系统达到的目标。

9.根据权利要求1所述的方法，进一步包括：

通过编写脚本的宏命令或报告聚集设计时间智能；以及

通过到流程监控工具的界面聚集运行时间智能。

10.根据权利要求1所述的方法，进一步包括排列用于流程功能的所述总服务合格数值。

11.根据权利要求10所述的方法，进一步包括将排列的总服务合格数值组织为基于排名的组。

12.根据权利要求11所述的方法，其中所述组被形成为近似正态分布。

13.根据权利要求11所述的方法，进一步包括显示所述组给面向服务的业务流程系统的用户。

14.根据权利要求1所述的方法，其中所述总体候选服务算法包括，对于每个所述功能：

将在预定的时间段内所述功能的预期可重用性、所述功能的数据凝聚、分别表明可以任务外包给利益相关者并对利益相关者可见的所述功能的执行范围的任务外包和可见性变量相加获得第一值；

通过从所述第一值减去用于所述功能的数据耦合度、包含在所述功能中的组织单元的最大数、和包含在所述功能中的应用系统的最大数来获得第二值，以及

将所述第二值乘以用于所述功能的业务关联指示符以获得用于所述功能的总服务合格数值。

15.根据权利要求1所述的方法，进一步包括如果用于所述功能的总服务合格数值超过预定的阈值，将功能展现为服务能力。

16.一种定义或改善业务流程模型的方法，所述方法包括：

在计算机系统的显示器上图示业务流程模型的至少一部分的表征，该部分包括多个对象；

使用户能够通过用户界面选择所述模型的对象；

通过所述用户界面响应接收的用户请求，在计算机系统的显示器上图示所述已选对象的元数据属性，其中对应于聚集的业务流程分析智能和/或聚集的业务性能智能的指示符与元数据属性一起以矩阵格式显示；以及

通过至少一个处理器基于指示符的加权总和计算用于模型中每一流程功能的总服务合格数值，

其中对应于业务流程分析智能的指示符在设计时间通过编写脚本的宏命令或报告被聚集，并且对应于业务性能智能的指示符在运行时间通过到流程监控工具的界面被聚集。

17.根据权利要求16所述的方法，进一步包括：

接收来自所述用户的服务请求；以及

显示至少一个候选服务作为所述请求的结果。

18.根据权利要求17所述的方法，其中多个候选服务被显示。

19.根据权利要求18所述的方法，其中所述候选服务基于它们各自的总服务合格数值被排序。

20.根据权利要求17所述的方法，其中只要超过预定的阈值，每一所述的候选服务被显示。

21.根据权利要求17所述的方法，其中一个候选服务被精确地显示，所述候选服务对应于具有最高总服务合格数值的功能。

22.一种永久计算机可读存储介质，包括当由计算机系统的处理器执行时实施权利要求1所述方法的指令。

23.一种永久计算机可读存储介质，包括当由计算机系统的处理器执行时实施权利要求16所述方法的指令。

24.一种用于分析可能展现为服务能力的业务流程模型的功能的服务导向业务流程系统，包括：

包含业务流程模型的表征的永久计算机可读存储介质，该业务流程模型由多个对象定义，每一个所述对象具有与其相关的元数据属性，所述元数据属性也存储在所述计算机可读存储介质中；

被配置为在设计时间获得对于每个所述对象的业务流程分析智能的第一计算机可执行智能聚集模块；

被配置为在运行时间获得对于每个所述对象的流程性能智能的第二计算机可执行智能聚集模块；

被配置为(a)接收对应于设计时间和运行时间聚集智能的指示符，和(b)在一些或所有指示符上应用候选服务算法以达到用于模型中每一流程功能的总服务合格数值的计算机可执行分析模块，

其中所述模块可通过系统的至少一个处理器执行。

25.根据权利要求24所述的系统，进一步包括配置为推荐响应功能请求的至少一个候选服务的报告生成器，所述推荐基于与功能相关的总服务合格数值。

26.根据权利要求25所述的系统，其中所述指示符包括流程指示符、数据指示符、组织指示符，以及目标与事件指示符。

27.根据权利要求26所述的系统，其中所述总服务合格数值是所述指示符的加权组合。

28.根据权利要求27所述的系统，其中所述权值对应于一个或更多通过生成的面向服务的业务流程系统达到的用户指定的目标。

29.根据权利要求25所述的系统，其中所述总体候选服务算法包括，对于每个所述功能：

将在预定的时间段内所述功能的预期可重用性、所述功能的数据凝聚、分别表明可以被任务外包给利益相关者并对利益相关者可见的所述功能的执行范围的任务外包和可见性变量相加获得第一值；

通过从所述第一值减去用于所述功能的数据耦合度、包含在所述功能中的组织单元的最大数、和包含在所述功能中的应用系统的最大数来获得第二值，以及

将所述第二值乘以用于所述功能的业务关联指示符以获得用于所述功能的总服务合格数值。

30.根据权利要求25所述的系统，其中如果用于功能的总服务合格数值超过预定的阈值，至少一个处理器被配置为将功能展现为服务能力。

Images