通常可实施独立软件供应商(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 软件包,对以下方面的了解是通过在分类过程中执行的分析获得的:
-
对此 ISV 软件包在企业内的重要性和影响的了解。
-
通过此 ISV 软件包实现任何新服务的倾向。
-
ISV 软件包内使用的体系结构标准和技术组件以及它们在企业内的角色。
-
对与 ISV 软件包兼容的中间件和技术组件的了解。
分析 ISV 软件包内的服务访问选项。
本步骤确定了访问 ISV 软件包内功能的机制(即与服务显现和实现直接相关的软件包技术方面)。 本信息用于帮助确定 ISV 软件包内的候选服务(下一步中),且稍后还将用于评估技术可行性和制定服务实现决策。
有多种机制可用于访问 ISV 软件包。在此步骤中,将分析范围内的每个软件包以确定并描述每个软件包可以使用哪些机制。通常而言,ISV 软件包支持以下一种或多种机制:
机制
|
描述
|
直接显现为服务
|
软件包使用与符合 SOA 的服务(通常为 Web service)直接显现功能。 此类服务可以在目录中列出。会对特定的实施进行评估以符合标准和互操作性。
|
API 的使用
|
软件包提供一个或多个可用于显现软件包内服务的 API。这些 API 可直接用于将功能显现为服务,或者可以通过 API 开发 Web service 包装程序或外观(facade)来实现对功能的访问。
|
直接数据访问
|
如果 API 不可用,但用于显现 ISV 软件包所管理数据的服务是必需的,则会开发一个直接访问软件包所使用数据库的服务。
请注意:虽然此方法在技术上是可行的,但绕过 ISV 软件包内的业务逻辑会带来潜在风险,即可能会损坏数据或违反程序强制的数据完整性。出于此原因,建议将此技术限于执行“只读”操作的服务。
即使这样,由于可能会改变 ISV 的数据模式,此方法仍存在风险,因此使用时应格外小心。
|
ISV 软件包服务确定技术
在本步骤中,将使用多种技术来分析 ISV
软件包并确定可显现为服务的功能。还将确定与功能关联的业务规则。会使用每种技术从不同的角度对软件包进行评估,这样能够对软件包进行彻底分析,从而确定候选服务。会在“业务功能/系统矩阵”和“业务规则目录”工作产品中捕获分析结果。与其他 SOMA
确定活动一样,候选服务会被添加到服务组合和服务层次结构中。
-
复审 ISV 软件包的预定义服务目录
某些 ISV 软件包提供了预定义服务目录。如果属于这种情况,将通过该目录来确定用于范围内领域和业务组件的候选服务并将它们添加到服务组合中。如果 ISV 支持,此技术是确定使用 ISV 软件包的候选服务的最简单方法。
请注意:在 SOMA 规范步骤中,这些服务的详细程度将被视为制定服务显现决策的考虑因素。因此,在 SOMA 确定过程中,捕获作为候选服务特性的详细程度很重要。可能有必要聚集或分解显现的服务,这取决于这些服务与
ISV 软件包内实现的服务之间的符合程度。 此分析还有助于协调服务层次结构内的候选服务。
-
复审 ISV 软件包的 API
ISV 软件包可能提供一个或多个可用于访问软件包内功能的 API。将检查这些 API 的范围内领域或业务组件以确定要添加到服务组合中的候选服务。由于可通过这些 API
访问的功能不会固有地作为服务来提供,因此需要开发一个服务包装程序或外观将来显现这些称为服务的 API。此方法的灵活性使得能够在单个服务内组合两个或两个以上的
API,从而能够使软件包内的服务被开发为与服务层次结构中的服务相符。在此情况下,执行人员可确定服务层次结构内的服务,并将它们与软件包内的支持功能和 API 调用相映射。
-
复审 ISV 业务流程映射和工作流
可采用硬拷贝或电子格式来记录 ISV 软件包所启用的业务流程和工作流。应对这些工件进行检查以确定要附加到服务组合中的其他候选服务。具体而言,此复查应当对软件包内的业务流程以及执行流程的工作流环境采取端到端查看。
这能够确定所有相关的候选服务,还能够确定服务实现过程中需要考虑的业务流程和工作流事项。
-
确定 ISV 软件包的服务边界
开发 ISV 软件包是为了支持业务流程和使用与业务组件(功能领域)和领域协调的范围来管理数据。这些业务组件形成了 ISV 软件包的“足迹”或“服务边界”。 但是,在特定的企业内,可能在 ISV
软件包的整体服务边界的子集内实施该软件包。 通过确定 ISV 软件包的整体服务边界,执行人员可确定该软件包服务边界内的其他服务是否应添加到服务组合中。 更重要的是,执行人员可确定是否应通过 ISV
软件包来实现所需的新服务。
如果确定新服务对于启用面向服务的解决方案是必需的,则执行人员应确定这些服务是否处在 ISV 软件包的服务边界内。如果是,则支持所需功能的 ISV 软件包内的服务将被确定并添加到服务组合中。 这使解决方案能够利用 ISV
软件包内的所有功能,并减少了在支持相同业务组件的多个系统内重复开发的风险。
-
分析 ISV 软件包内控制的数据元素
将对解决方案范围内的数据元素进行评估以确定是否在 ISV 软件包内管理这些元素。 如果数据是在 ISV 软件包内管理,将为候选服务分析软件包内读取或更新相同数据的其他业务流程,以添加到服务组合中。
此分析还展示了可能受解决方案影响且在服务实现过程中必须考虑的相关或外部流程和接口。 在服务实现过程中,将对它们进行记录和评估。
-
分析 ISV 安全性和其他技术组件
许多 ISV 软件包包含自己的安全性组件用于认证和授权,也可能包含其他支持诸如日志记录和消息传递等功能的技术组件。对于每个软件包,需确定并分析这些组件以确定可添加到服务组合中的候选技术服务。
此外,在分析过程中,在服务实现过程中必须确定并考虑这些组件可能引入的问题或约束。 例如,在服务实现过程中必须了解并提供为访问软件包内的功能而与软件包的安全性组件之间的必需交互。
应用这些不同的技术使得能够从不同的方面确定范围内 ISV 软件包中的候选服务。 它还可以确定在服务实现过程中必须考虑的 ISV 软件包的功能组件和技术组件所引入的问题和约束。
|