技术架构遵循

　　下面我们检查软件基础设施将如何支持任务关键的核心应用程序的部署。企业服务器、应用程序服务器、流程服务器、数据库服务器、安全服务器、通知服务器以及它们的部署配置属于这个类别。技术架构评估涵盖以下主题：

　　基础设施服务

　　安全架构

　　系统管理和支持服务

　　开放技术标准

　　经营模型和部署架构

　　性能

　　其他 NFR、可用性和可靠性

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

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

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

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

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

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

　　基础设施服务

　　我们检查了应用程序部署的重用或在企业层面的重用所需的各种基础设施组件（请参阅 “参考资料” 部分提供的文章 “SOA Practitioners guide part 2 SOA reference architecture”）。如果这些服务在企业的所有层面上都是可重用的，那么这说明组织是统一的，拥有一个统一的方法来使用含有成熟服务的架构解决方案。通过此前使用这样的服务构建的解决方案提供的历史数据，可以很容易地确定组织能否满足服务水平协议。评估基于组织中可用的各种服务。为确定如何最好地建立基础设施架构，我们将考虑以下几个问题：

　　组织中有哪些公共组件/服务可用于开发自定义应用程序/打包应用程序？这些服务可能包括数据服务、日志服务、故障处理服务、审计、搜索、通知以及会话管理服务。

　　组织中有哪些不同类型的门户服务可重用并获得统一的观感？这些服务包括个性化、报告、本地化和 Web 流量监控服务。

　　组织中有哪些不同类型的企业基础设施服务可用？我们将寻找 LDAP、电子邮件、协作（聊天/IM/白板）和内容管理等服务。

　　组织中有哪些不同的主数据管理服务可用？自定义数据集成服务和产品主数据管理服务属于这个类别。

　　安全架构

　　重要的是要理解当前安全模型、用户角色、权限和应用程序功能。以下几点可以帮助评估安全架构的成熟度：

　　组织中实现了哪些不同的 IT 安全服务？

　　确认 IT 安全是否可以在所有应用程序层实现？

　　更改和更新安全架构的难度如何？

　　查明安全架构是否通过一个协议防火墙、域防火墙和企业防火墙配置实现。

　　应用程序是否支持单点登录（SSO）？SSO 同时处于应用程序和 Web 服务级别吗？

　　组织拥有现成的安全政策管理框架吗？

　　系统管理和支持服务

　　在这个小节中，我们将评估应用程序的架构与应用程序管理和支持服务之间的关系。有些应用程序架构完全没有系统管理服务支持，而有些应用程序的架构和设计优良，拥有完整的生命周期服务支持/应用程序管理，比如治理、访问、授权和监控。

　　检查系统监控和管理服务是否使用 JMX、开源 SNMP APIs 等开放标准和 APIs 实现。

　　检查是否所有这些管理服务或使用的开放标准产品正在实现监控业务和 IT 关键性能指标的要求。

　　检查监控数据是否正在帮助管理架构师调优基础设施，并帮助业务分析师重新定义优化的业务流程。

　　部署架构

　　下面我们检查各种中间件服务器，它们用于支持通过指定的应用程序架构实现的解决方案。通常，组织将提供解决方案的一个详细部署模型。

　　检查组织在冻结他们的拓扑架构时是否遵循了任何标准电子商务部署架构模式？

　　检查系统的经营模型和拓扑架构，它们将展示将在一个典型生产环境中运行的硬件节点以及软件组件的各种版本。检查模型是否完整清晰，是否提供了关于区域、硬件、软件以及连接规范或细节的详细信息。

　　检查其他方面，比如解决方案是否虚拟化，解决方案网格是否允许您利用集群化和工作负载平衡。

　　性能

　　通过检查组织针对低、中和复杂用例提供的性能指标结果来评估应用程序的性能。根据用户数量和事务数量，通过支持的硬件配置获取关于系统伸缩性的信息。多数组织都不够成熟，不能提供服务级别的性能基准测试。重点关注这样的服务水平性能指标：能够帮助预测构建复合应用程序时的端到端响应时间和计划服务器容量。另外，检查以下几个方面：

　　根据事务响应时间和流量，组织拥有任何能够改进解决方案性能的软件架构组件或产品吗？

　　组织拥有性能建模和容量计划工具吗？当前解决方案考虑了未来 2 至 3 年的用户工作负载增长计划了吗？

　　在解决方案阶段的 Software Development Life Cycle 过程中，我们想查看性能工程生命周期方法学/工具是否已经被遵循或应用。

　　其他非功能要求（可用性和可靠性）

　　在以下关键条件下检查系统可用性：

　　当系统受到未授权或未格式化的消息的攻击时

　　当系统超载时

　　在维护期间

　　在软件版本更改期间

　　为以下项目检查故障和恢复之下的系统可靠性：

　　事务性流程状态

　　恢复之后维护相同的数据

　　上述每个维度中提到的问卷调查帮助您使用一些定性属性评估企业架构，比如低度、中度和高度遵循 IBM CBS 参考架构。

　　为了更好地理解对 CBS 架构的遵循程度的定量评估概念，下面讨论一个基于应用程序架构维度中的 PoC 评估的样例场景。

　　基于场景的 PoC 评估方法

　　我们应该通过构建基于场景的 PoC 来定量评估此前提到过的架构维度。我们应该通过按照企业定义的功能来生成功能测试案例来评估业务架构。这些测试案例将在已部署的解决方案上运行，并使用提交的功能特性来验证。定量评估基于功能测试期间确定的测试案例的数量进行。类似的定量评估将基于一个评估场景分别针对信息、集成和技术架构部分进行。例如，我们将考虑一个来自应用程序架构维度的典型场景，我们将在一个组织转向 CBS 参考架构的架构转换阶段基于这个场景评估该组织。

　　场景：

　　现有应用程序服务和组件可以直接用于开发一个复合应用程序吗？

　　定量评估基于以下这组预先定义的评估点进行。每个确认点都以以下方式定义：它拥有一个独立的不同于它的理想遵循度的差别水平。查看以降序排列的数据点，它们偏离 CBS 服务遵循度，因此，针对每个点的评估得分逐渐减小。

　　组织拥有一些服务/组件，它们直接呈现为 Web 服务，正在从 BPEL 流程使用。这些服务在 UDDI 或一些等效注册表中发布（得分：100%）。

　　组织拥有一些服务/组件，它们直接呈现为 Web 服务，正在从 BPEL 流程使用。但这些服务没有在 UDDI 或一些等效注册表中发布（得分：75%）。

　　组织拥有一些服务/组件，它们通过某个架构框架组件（网关服务）间接呈现为 Web 服务，但能够从 BPEL 流程使用（得分：50%）。

　　组织拥有一些服务/组件，它们直接呈现为 Web 服务，但不能从外部客户机调用，原因是：由于不遵守 WSDL，SOAP 地址绑定 URL 规范缺失（得分：25%）。

　　组织拥有一个作为 EJB 接口实现和呈现的服务/组件（得分：0%）。

　　根据这个场景，我们通过将一个 Web 服务导入其组装环境来构建一个小型 PoC,并通过一个已构造的 BPEL 流程、使用针对一个 Web 服务的直接以及间接（通过 UDDI）端点 URL 查询来调用它。如果使用条件 4 中指定的 Web 服务类型，那么这种类型的 WSDL 不允许导入 WID 本身。基于这些 PoC 执行和观察，定量评估针对这个场景进行。类似的 PoC 模型基于集成和技术架构维度中的场景构建，并对它们的架构进行定性评估。

　　结束语

　　在本文中，我们通过从一个组织获取的 RFI 响应检查了企业架构。首先，我们参照 CBS 解决方案参考架构，根据前面小节中提到的评估点对他们的业务、应用程序和数据、集成和技术架构遵循度进行初始定性评估。由于评估基于企业提供的信息，因此企业架构的定量评估通过在现场执行一个 PoC 来进行，这样您就能确定企业的状态 -- 企业是否准备好利用企业的现有资产，因为这些资产可能与复合业务服务有关。最终的 PoC 评估报告将解释组织需要弥补的差距，以便继续前进，构建复合业务服务。如果组织还不能完全满足 CBS 解决方案的要求，那么需要准备一个支持策略并提交给组织。

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