应用程序和数据架构

　　这个维度描述涉及数据和应用程序系统领域的架构，它包括应用程序软件库存、图表和应用程序之间的接口（这包括事件、消息和数据流）。数据架构包括概念、逻辑和物理数据模型及其元数据模型。

　　集成架构

　　集成架构描述企业中的集成的各个方面，包括人员、系统和数据库的内部和外部集成。开发灵活高效的复合业务服务需要检查集成的不同方面，这些集成子视图包括：

　　访问/呈现集成视图 处理访问系统功能的不同方法，以及对各种类型的客户端（门户、移动、内联网、电话设备、电子邮件设备、PDAs 等）的支持。

　　应用程序集成视图 处理组织内应用程序的集成，或者使用企业应用程序的业务伙伴。这允许应用程序互相连接，以便它们能够在企业层面上更好共享和使用信息。

　　信息（数据）集成视图 处理可以跨企业集成的各种形式的业务信息。这种集成在一个统一的信息资产视图上支持一致的搜索、访问、复制、转换和分析，从而满足业务需求。

　　流程集成视图 处理企业内外部业务中的变化，以及它如何在跨人员和异构系统的流程建模、自动化和监控过程中操作。

　　技术架构

　　本质上，技术架构是包含硬件和软件组件的基础设施，它包含企业服务器、数据服务器、防火墙、应用程序基础设施、安全、监控和中间件。技术架构还描述企业中使用的编程语言和操作系统。这个维度还评估已开发的软件组件利用开放技术标准的程度。

　　如何评估企业架构的 CBS 就绪程度

　　评估企业架构的第一步是完成一个 Request for Information （RFI），在其中处理前面提到的 4 个维度。这个 RFI 将发送给客户。从客户获得响应之后，准备一个基于检查表的模板，针对这个模板验证响应。这些模板最终结果针对 CBS 参考架构和 CBS 服务的开发对现有架构进行定性评估。如果一个组织在所有 4 个维度的定性评估中均合格，那么将继续进行第二个步骤 -- 定量评估，这需要该组织准备一个基于各种场景开发一个原型模型的说明。这个说明将描述如何根据场景设计、开发这个原型模型并描述将用于评估的指标，“基于场景的 PoC 评估” 小节将详细介绍这个说明。图 2 展示了用于遵循 CBS 的定性和定量方法。

　　图 2. 定性和定量迭代

　　业务架构遵循

　　一个定性评估可以从以下调查问卷开始。可以根据组织提供解决方案的业务领域和功能区域评估该组织。首先，应检查组织的基础设施方面，以支持业务需求。以下是一些需要考虑的重点问题（请参阅 “参考资料” 部分提到的文章“Exploring Business Process Management Systems and the impact of BPM on developers”）：

　　组织有良好定义的 Business Process Management System （BPMS） 来定义、维护、测量、分析和持续改进它们的业务流程吗？

　　企业拥有业务流程建模器、可执行流程建模器、流程执行引擎、业务活动监视器、流程管理门户等工具来支持 BPMS 的完整生命周期管理吗？

　　组织建立了一个 BPM Center of Excellence （BPM-COE） 中心来实践这样的框架、工具和方法学，以便将业务要求有效地转换为 IT 系统吗？

　　组织拥有帮助确保公司方向在运营层面上实现的流程治理吗？

　　RFI 中的 “业务要求” 部分需要将预定义的业务子功能包含到企业从事的业务领域。我们可以将一个客户银行自助服务门户作为一个示例。这个门户可能包含以下子功能：账户开立、账户查看、支票簿和 ATM 复制 PIN 的服务请求、账单支付、资金转账和信用卡服务等。组织需要在这些子功能中或围绕这些子功能提供它们的业务解决方案。根据从企业获取的 RFI 响应，组织业务遵循应该考虑以下几点：

　　组织当前同时支持多少业务子功能？

　　有多少业务子功能需要根据预定义的功能进行修改？

　　有多少业务子功能需要从头开发？

　　有多少业务子功能当前不受支持，但有明确的路线图以便在一个规定的时间范围内支持那些服务？

　　“业务架构评估” 部分还包含一个关于通过业务流程模型和业务服务实现业务子功能的问卷调查。在评估他们的业务服务实现时应该考虑以下几点：

　　组织采用了一些行业特有的业务流程模型了吗？

　　他们使用自己的自定义构建模型吗？如果是，这些自定义构建模型吸收业务要求中的变化的灵活性如何？

　　他们的业务服务支持 ACCORD、HiPAA 和 SWIFT 等行业特有的数据模型来在其他服务之间交换数据吗？

　　组织遵循任何标准方法或技术来识别 RUP for SOA、SOMA 等业务服务吗？

　　已实现的业务服务提供基于业务政策和用户上下文的灵活的可调节行为吗？

　　业务服务是通过多个通信通道提供的吗？

　　业务服务是从不同的 IT 系统实现的吗？如果是，它来自一个 Silo 格式吗？是集成的吗？或者，它是来自组件化的流程集成的吗？

　　上述问卷调查的所有答案将针对遵循 CBS 服务的开发进行研究和分析，并最终针对这个部分准备一个定性评估图表。

　　应用程序和数据架构遵循

　　在这个小节中，我们将详细介绍如何评估一个组织的应用程序和数据架构，以便遵循 CBS 参考架构。总体应用程序架构成熟度可以根据以下几个标准进行评估：与 CBS 参考架构的接近程度、IBM 的电子商务模式、企业应用程序架构模式、以及是否使用模型驱动的架构工具进行开发。这个部分将严格评估一些架构原则，比如层与层之间的松散耦合、遵循的 MVC 模式、实践的分层概念以及应用程序的伸缩能力。来自他们的应用程序架构的关键架构层和关键评估点（请参阅 “参考资料” 部分中的文章链接“Evaluating Service Oriented Architecture”）包括：

　　通道和呈现层

　　业务流程和精编层

　　服务或呈现功能

　　业务规则

　　服务注册层

　　数据和数据访问层

　　以下小节将详细介绍上述每个主题：

　　通道和呈现层

　　应用程序或系统的架构评估要考虑架构如何与通道和呈现层相关。复合应用程序需要从一个共享的公共托管环境服务多个客户机。通道和呈现层从以下几个点评估。

　　呈现层应该支持 STRUTS、JSF 和 Dot Net U 等开放标准框架，必须可以轻松扩展或修改来构建自定义呈现层框架。

　　呈现层还应该足够灵活，以便添加 PDA 客户端、表单和电子邮件等新通道。

　　如果组织正在使用某种自主框架，那么应该评估该框架与开源框架之间的关系。

　　检查通过 Web 服务接口的无外设（headless）系统功能调用。

　　检查呈现层是否与当前系统/应用程序松散耦合。

　　系统支持哪些不同类型的物理设备/通道？向现有系统添加一个新的物理设备的灵活性如何？