业务流程和精编层

　　应用程序架构的评估要考虑业务流程和精编功能。评估人员应该检查组织，查看他们是否采用任何业务流程层和运行时引擎来编排他们的业务服务/应用程序功能。以下几点用于评估这个架构层。

　　如果组织使用了任何自主流程流或工作流层，通过将其移植到外部 BPEL 设计工具和运行时引擎来检查它是否遵循 BPEL 标准。识别在开放标准运行是引擎上运行这样的自主工作流需要遵循的步骤和程序。

　　组织是否拥有任何自动为部署而生成 BPEL 运行时代码的业务流程建模工具？

　　检查遵循 BPEL 的运行时引擎如何实现为一个可伸缩的成熟产品，并拥有补偿、业务和技术异常处理功能以及指标、交易量监控功能。

　　检查当前流程流是否支持调用人工任务、选择器、业务规则和 ESB。

　　检查 BPEL 流程流和服务交互是如何实现的：它们是紧密耦合还是松散耦合的？BPEL 流程本身可以使用开放标准呈现吗？

　　服务和呈现功能

　　现在，我们将从另一个角度检查如何评估系统和应用程序的架构：它如何与作为接口和 API 的服务或呈现功能相关。服务成熟度从以下几点确定：

　　如何访问服务？是通过 Web 服务或 SCA 接口这样的开放技术标准吗？

　　服务如何通过底层系统实现，它们是紧密耦合的还是松散耦合的？

　　组织的边界服务遵循 ACCORD、HiPAA 等行业标准进行企业数据共享和访问吗？

　　服务使用适当的分解和粒度级别实现吗？

　　服务同时支持同步和异步调用吗？

　　服务同时支持异常处理和故障恢复吗？

　　服务同时支持身份验证和授权码？

　　服务在设计时和运行时都有在注册表中发布的条件吗？

　　设计时和运行时都支持服务版本控制吗？

　　技术服务如何组织，以及应用程序服务或业务服务在实现业务交易时如何与这些技术服务交互？

　　业务规则

　　本小节评估应用程序的架构与业务规则之间的关系。业务规则是如何实现的？它们与系统紧密耦合且不能被外部化吗？尽管有些实现是松散耦合的，但它们仍旧不能被外部化，要修改规则需要代码级别的修改。有些实现被松散耦合和外部化，但使用一个自主规则引擎和自主编程框架。有些业务规则也是松散耦合和外部化的，它们的编程模型遵循 JSR94 等标准，规则可以随业务要求轻松改变。以下几点用于评估解决方案的架构中采用的业务规则的强度。

　　规则引擎是如何构建的？它是纯 Java 类或 EJBs 吗？它实现为一个可伸缩的成熟产品，具有在线编辑和完整的生命周期管理支持吗？

　　现有规则引擎支持第三方规则引擎连接，以便添加新的规则或将现有规则传输到第三方引擎吗？

　　检查这个规则组件是否可以呈现为一个 Web 服务或 SCA 服务，以便从外部 BPEL 流程流编排（orchestrate）或从第三方客户机调用。

　　服务注册层

　　服务注册表提供服务的注册、元数据的管理和自动化服务。这个层根据以下问题的答案进行评估：

　　是否正在使用一个注册表？如果没有，使用共享服务的各方如何知道服务的可用性和功能？如何维护服务信息以避免不必要的复制？

　　有什么政策来确保注册表的正确使用？

　　如何在注册表内部和外部定义和管理服务元数据？设计中考虑了未来可能出现的长期需求了吗？

　　在 SOA 生命周期（从开始到结束）中的哪个阶段使用这个注册表？

　　服务访问控制和更改管理政策是如何治理的？是否有适当的控制来平衡安全、可修改性、以及遵循 IT 和其他标准？

　　注册表正用于服务调用的动态路由（比如，故障转移、负载平衡和应用程序分区）吗？如果是，注册表安装是单个故障点吗？它满足性能和故障转移时间要求吗？

　　注册表是公开的还是私有的？注册表实现能恰当地处理内部和外部服务之间的区别吗？

　　数据和数据访问层

　　这个小节评估应用程序的架构与数据和数据访问之间的关系。进行这个小节的评估时要考虑以下几点：

　　数据模型有多健壮和多灵活？它遵循成熟的行业标准吗？可以轻松添加新的数据元素吗？

　　数据访问层使用什么实现？它是紧密耦合且使用自主框架吗？它是松散耦合且遵循诸如开源数据对象之类的成熟框架吗？

　　组织利用 toplink、hibernate 或 iBatis 等对象关系映射工具吗？

　　如果一个数据资源库跨企业分发，它遵循哪种机制来允许对应用程序的访问？

　　要支持 “信息即服务”，组织需要利用哪些种类的工具或产品？

　　企业数据架构如何通过更少的数据延迟帮助处理从事务型数据到分析型数据的转换？

　　企业数据架构如何帮助对数据进行分析性处理，以便根据需要向业务用户交付信息？

　　集成架构遵循

　　这个小节从以下角度评估应用程序的架构：它与包含第三方和遗留系统的应用程序、组件和服务的集成之间的关系。评估集成层的成熟度时应考虑以下几点。

　　需要询问的关于集成层的几个样例评估问题是：

　　集成层的健壮程度如何？它实现为一个可伸缩的成熟产品吗？或者，它基于一个按需（as-needed）基础，使用一个开源 API 或使用多个连接器和适配器来实现吗？

　　受到支持的集成架构模式是什么？它将使用 ESB、hub and spoke、或者 point-to-point 吗？

　　集成层支持的功能有哪些，比如消息路由、数据格式转换、针对所有服务的中央安全网关？它将支持发布和订阅消息模型和消息聚合吗？

　　集成层与系统或应用程序的其余部分松散耦合或紧密耦合的程度如何？

　　组织当前支持哪些不同类型的集成规范/标准/框架？例如，它支持 RPC、RMI、SOAP/JMS 或 SOAP/HTTP 吗？

　　集成层支持异常处理、事件管理、审计、日志记录等辅助功能并支持访问控制吗？

　　当前遵循的应用程序架构提供了一个条件来将这个集成层引入到拥有具有集成架构的成熟解决方案的层之间吗？

　　我们特意通过获取关于下面的问题的信息来采集关于遗留应用程序集成在企业内部发生方式的信息：

　　为新系统和遗留系统的集成采用了什么机制？我们寻找的机制包括屏幕搜刮器、Web 服务调用、带有用于遗留平台的适配器的 ESB、消息传递系统、直接遗留软件 API 调用、特定于技术的网关和桥接。

　　已选择的机制是如何根据复杂性和实现成本进行比较的？

　　根据预期的调用数量、理想的响应时间，已选择的机制满足系统性能要求吗？

　　访问控制和数据隐私等安全要求在现有和遗留系统中都得到满足了吗？

[1]   [2]   [3]   [4]