任务:现有资产分析
本任务根据服务和分区确定面向服务的解决方案的设计元素,并记录那些服务的初始规范。
用途
  • 根据服务和分区确定面向服务的解决方案的设计元素。
  • 记录服务的初始规范。
  • 确定服务之间的初始依赖关系和通信。
关系
角色主要: 其他: 辅助:
输入必需: 可选: 外部:
输出
主要描述
现有资产分析是为了实现服务而利用现有资产(例如现有系统,如打包或定制的应用程序)、行业标准、模型和资产的过程。 现有资产分析将使用由下至上的方法来识别并验证候选服务、组件和流程。 出于风险管理目的,应该尽早地评估与现有系统有关的技术约束。 因此,服务实现决策的技术可行性分析通常在现有资产分析过程中(或之后)尽快进行。
步骤
从定制应用程序确定候选服务

有两个子步骤用于确定现有应用程序提供的功能。第一个子步骤是粗放型映射,它将业务流程与现有应用程序的组合相映射。 第二个子步骤是精细型映射,它涉及将服务与旧应用程序内的特定事务或批处理过程相映射。 精细型映射是在服务规范过程中完成的。

粗放型映射的目的是获取初始值,例如业务功能与服务的初始映射。

为了从现有应用程序的功能确定候选服务,必须了解业务流程与现有应用程序之间的关系。可将此描述为粗放型映射。这是业务活动或业务流程与现有应用程序的业务功能之间的映射,如下所示。

要捕获业务流程与现有应用程序之间的关系,应执行以下粗放型映射步骤:

  1. 了解每个应用程序支持的业务功能。  通常情况下,业务功能可与业务流程内的活动相映射。
  2. 根据使用的技术、体系结构风格等来记录现有应用程序的属性。
  3. 确定执行公共服务的应用程序。

粗放型映射和应用程序组合分析

了解业务价值和现有应用程序的技术质量有助于创建具有最高优先级的转换计划(提供给价值最高的服务),并有助于根据应用程序的技术质量(例如耦合度)来对范围和技术风险进行评估。

应用程序组合分析为粗放型映射提供了范围和边界。例如,业务价值最低或技术价值较低而将要废弃的应用程序可能不在候选服务确定范围之内。

应用程序组合分析(如果执行)可以为粗放型映射提供与现有服务有关的信息。此分析的输出是如下所示的候选服务。

从打包的应用程序确定候选服务

通常可实施独立软件供应商(ISV)的软件包以便在组织内启用子系统和/或服务组件。例如,综合性的企业资源规划(ERP)ISV 软件包(例如 SAP、PeopleSoft 以及 Oracle 提供的此类软件包)通常都作为包含多个子系统的完整系统来实施,这些子系统充分支持组织内的一个或多个领域。 本部分描述了使执行人员能够确定现有 ISV 软件包内的功能和候选服务的一系列步骤。此分析使得能够根据现有 ISV 软件包的功能来移植“业务功能/系统矩阵”,“业务规则目录”和“服务模型”工作产品。

请注意:由于每个 ISV 软件包各不相同,因此不可能为每个软件包都开发一个详细的规定方法。 以下活动描述了一种通用方法和一组通用活动,它们将:

  • 确定 ISV 软件包内的候选服务。
  • 确定在服务实现过程中将考虑的 ISV 软件包的高级别特性。

ISV 软件包确定

理想情况下,范围内领域和业务组件的 ISV 软件包应该已在 CBM 系统中确定为业务组件覆盖程序段输入(或同等输入)。 这将在预想的解决方案范围内产生一组在特定业务组件内实现功能的 ISV 软件包。如果缺少此输入,则必须确认支持范围内域和业务组件的 ISV 软件包并将其与业务组件相映射。

请注意,某些 ISV 软件包(例如 SAP、PeopleSoft 和 Oracle)是由许多核心模块和可选模块组成的。例如,SAP 具有制造模块,人力资源模块和客户关系管理模块。在此类情况下,指定使用 ISV 软件包的哪些特定模块很重要。这样使分析更有针对性,从而节省时间并避免了不必要的服务增长。

ISV 软件包分类

通过 ISV 软件包分类能够对需要在服务实现过程中考虑的重要特性进行高级别的了解(这对功能组件和技术组件都适用)。 可以根据特性,例如核心能力、规模和收入(在表 10 中汇总)将 ISV 分为第 1 层、第 2 层或第 3 层 ISV。 请尤其注意技术影响和业务影响方面。

ISV 类别 第 1 层 ISV 第 2 层和第 3 层 ISV
描述 诸如企业资源规划(ERP)供应商等大型 ISV,提供有助于企业管理其核心资源和操作的打包应用程序。 中小型 ISV,倾向于提供特定于行业的纵向业务解决方案
特性
  • 用于产品规划、部件采购、维护库存、与供应商交互、提供客户服务以及跟踪订单的集成、多模块,跨行业的应用程序。
  • 还可以包含用于企业的财务和人力资源方面的应用程序模块。
  • 通常跨 CBM 映射中多个业务组件(甚至和域)。
  • 通常与其专有的中间件、安全性组件和其他技术组件一起打包。
  • 通常启用特定于行业的纵向子系统,这些子系统支持企业内的特定功能。
  • 通常已记录了与一个或多个第 1 层 ISV 关联的业务接口。
  • 通常包含在 CBM 领域和少数业务组件内。
  • 通常依赖外部的第三方中间件和其他技术组件。
  • 可能具有自己的安全性组件。
技术影响 由于大量使用,这些 ISV 可能对组织内使用的技术体系结构和标准产生重大影响。在此类情况下,在服务实现过程中会确定并考虑这些影响。
在服务实现过程中,需要考虑中间件和其他技术组件,如认证和日志记录。
在大型组织内,这些 ISV 通常在体系结构方面的影响较小,但在小型、高度专业化且特定于行业的组织中,它们也可能对服务实现具有重大的影响。
这些软件包通常不提供自己的中间件或技术组件。它们依赖于第三方中间件和技术组件 - 也可能依赖于第 1 层 ISV 提供的中间件或技术组件。 一些较小的 ISV 可能不会提供技术组件的接口。它们依赖于第三方中间件和技术组件 - 也可能依赖于第 1 层 ISV 提供的中间件或技术组件。 一些较小的 ISV 可能不会提供技术组件的接口。
业务影响 已在第 1 层 ISV 中投资的组织通常倾向于最大程度地利用这些 ISV 软件包。 在此类情况下,很可能会使用现有的软件包来实现服务并启用新服务。 由于这些软件包倾向于实现较小范围的功能,因此通过扩展这些包来实现新服务的倾向和机会较少。
示例 SAP、Siebel、Peoplesoft 和 Oracle Financials Manugistics、Provia 和 Evoke/TD>

由于 ISV 软件包实际上在每个组织内使用,因此大多数面向服务的解决方案将根据 ISV 软件包合并通过服务组件实现的服务。 对这些 ISV 软件包分类将使执行人员能够了解这些软件包在 SQA 解决方案内的角色和相对重要性,同时可确定在服务实现过程中要考虑的技术和功能特性。

对于每个 ISV 软件包,对以下方面的了解是通过在分类过程中执行的分析获得的:

  1. 对此 ISV 软件包在企业内的重要性和影响的了解。
  2. 通过此 ISV 软件包实现任何新服务的倾向。
  3. ISV 软件包内使用的体系结构标准和技术组件以及它们在企业内的角色。
  4. 对与 ISV 软件包兼容的中间件和技术组件的了解。

分析 ISV 软件包内的服务访问选项。

本步骤确定了访问 ISV 软件包内功能的机制(即与服务显现和实现直接相关的软件包技术方面)。 本信息用于帮助确定 ISV 软件包内的候选服务(下一步中),且稍后还将用于评估技术可行性和制定服务实现决策。

有多种机制可用于访问 ISV 软件包。在此步骤中,将分析范围内的每个软件包以确定并描述每个软件包可以使用哪些机制。通常而言,ISV 软件包支持以下一种或多种机制:

机制 描述
直接显现为服务 软件包使用与符合 SOA 的服务(通常为 Web service)直接显现功能。 此类服务可以在目录中列出。会对特定的实施进行评估以符合标准和互操作性。
API 的使用 软件包提供一个或多个可用于显现软件包内服务的 API。这些 API 可直接用于将功能显现为服务,或者可以通过 API 开发 Web service 包装程序或外观(facade)来实现对功能的访问。
直接数据访问 如果 API 不可用,但用于显现 ISV 软件包所管理数据的服务是必需的,则会开发一个直接访问软件包所使用数据库的服务。
请注意:虽然此方法在技术上是可行的,但绕过 ISV 软件包内的业务逻辑会带来潜在风险,即可能会损坏数据或违反程序强制的数据完整性。出于此原因,建议将此技术限于执行“只读”操作的服务。 即使这样,由于可能会改变 ISV 的数据模式,此方法仍存在风险,因此使用时应格外小心。

ISV 软件包服务确定技术

在本步骤中,将使用多种技术来分析 ISV 软件包并确定可显现为服务的功能。还将确定与功能关联的业务规则。会使用每种技术从不同的角度对软件包进行评估,这样能够对软件包进行彻底分析,从而确定候选服务。会在“业务功能/系统矩阵”和“业务规则目录”工作产品中捕获分析结果。与其他 SOMA 确定活动一样,候选服务会被添加到服务组合和服务层次结构中。

  1. 复审 ISV 软件包的预定义服务目录

    某些 ISV 软件包提供了预定义服务目录。如果属于这种情况,将通过该目录来确定用于范围内领域和业务组件的候选服务并将它们添加到服务组合中。如果 ISV 支持,此技术是确定使用 ISV 软件包的候选服务的最简单方法。

    请注意:在 SOMA 规范步骤中,这些服务的详细程度将被视为制定服务显现决策的考虑因素。因此,在 SOMA 确定过程中,捕获作为候选服务特性的详细程度很重要。可能有必要聚集或分解显现的服务,这取决于这些服务与 ISV 软件包内实现的服务之间的符合程度。 此分析还有助于协调服务层次结构内的候选服务。
  2. 复审 ISV 软件包的 API

    ISV 软件包可能提供一个或多个可用于访问软件包内功能的 API。将检查这些 API 的范围内领域或业务组件以确定要添加到服务组合中的候选服务。由于可通过这些 API 访问的功能不会固有地作为服务来提供,因此需要开发一个服务包装程序或外观将来显现这些称为服务的 API。此方法的灵活性使得能够在单个服务内组合两个或两个以上的 API,从而能够使软件包内的服务被开发为与服务层次结构中的服务相符。在此情况下,执行人员可确定服务层次结构内的服务,并将它们与软件包内的支持功能和 API 调用相映射。
  3. 复审 ISV 业务流程映射和工作流

    可采用硬拷贝或电子格式来记录 ISV 软件包所启用的业务流程和工作流。应对这些工件进行检查以确定要附加到服务组合中的其他候选服务。具体而言,此复查应当对软件包内的业务流程以及执行流程的工作流环境采取端到端查看。 这能够确定所有相关的候选服务,还能够确定服务实现过程中需要考虑的业务流程和工作流事项。
  4. 确定 ISV 软件包的服务边界

    开发 ISV 软件包是为了支持业务流程和使用与业务组件(功能领域)和领域协调的范围来管理数据。这些业务组件形成了 ISV 软件包的“足迹”或“服务边界”。 但是,在特定的企业内,可能在 ISV 软件包的整体服务边界的子集内实施该软件包。 通过确定 ISV 软件包的整体服务边界,执行人员可确定该软件包服务边界内的其他服务是否应添加到服务组合中。 更重要的是,执行人员可确定是否应通过 ISV 软件包来实现所需的新服务。

    如果确定新服务对于启用面向服务的解决方案是必需的,则执行人员应确定这些服务是否处在 ISV 软件包的服务边界内。如果是,则支持所需功能的 ISV 软件包内的服务将被确定并添加到服务组合中。 这使解决方案能够利用 ISV 软件包内的所有功能,并减少了在支持相同业务组件的多个系统内重复开发的风险。
  5. 分析 ISV 软件包内控制的数据元素

    将对解决方案范围内的数据元素进行评估以确定是否在 ISV 软件包内管理这些元素。 如果数据是在 ISV 软件包内管理,将为候选服务分析软件包内读取或更新相同数据的其他业务流程,以添加到服务组合中。

    此分析还展示了可能受解决方案影响且在服务实现过程中必须考虑的相关或外部流程和接口。 在服务实现过程中,将对它们进行记录和评估。
  6. 分析 ISV 安全性和其他技术组件

    许多 ISV 软件包包含自己的安全性组件用于认证和授权,也可能包含其他支持诸如日志记录和消息传递等功能的技术组件。对于每个软件包,需确定并分析这些组件以确定可添加到服务组合中的候选技术服务。

    此外,在分析过程中,在服务实现过程中必须确定并考虑这些组件可能引入的问题或约束。 例如,在服务实现过程中必须了解并提供为访问软件包内的功能而与软件包的安全性组件之间的必需交互。

应用这些不同的技术使得能够从不同的方面确定范围内 ISV 软件包中的候选服务。 它还可以确定在服务实现过程中必须考虑的 ISV 软件包的功能组件和技术组件所引入的问题和约束。

确保记录了资产的非功能需求

在记录现有资产的非功能需求时,需考虑以下关键问题。

  • 异常处理 - 需要了解异常处理现今是如何进行的。在批处理过程中,当发生异常时,程序会异常终止(不正常地终止)并产生核心转储。 程序员必须查看核心转储并确定应采取什么操作。 这可能是不可接受的。但应确定需要采取什么操作,例如,如何与异常处理框架集成。
  • 进程和数据分发 - 需要检验在何处执行数据和进程。在某台机器上执行的 CICS 应用程序可能会向其他机器发送请求(在 CICS 中也称为函数输送)或对其他机器上的数据进行远程调用。我们可能希望直接转到(JDBC 到 DB)正在运行进程或数据的远程机器上,而不是使用从 JDBC 到 DB 的连接器。
  • 数据可用性 - 如果在我们 VSAM 中具有客户文件,而譬如该 VSAM 需要 4 小时维护窗口,那么我们不支持 24 小时(7天)的客户服务。我们需要考虑一个新的存储解决方案。
  • 授权/认证 - 许多旧应用程序在应用程序代码中具有授权和认证机制。 这会要求将用户访问管理迁移到最佳实践支持的联合管理环境中。
  • 登台延迟 - 通常,批处理程序每天夜里运行一次。如果需要更频繁地运行此程序,则必须修改调度程序以更改频率。
属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息