本系列第1部分中介绍了作为服务建模方法 的一部分建立的服务分类指导方针，评估阶段主要是以此方针为依据，获得生产服务并评估其使用情况。经验表明，最初为实现某种特定功能或使用级别而开发的服务，往往在实际上得到了比原始预期更充分的使用。这样的运行时更改，是组织中所期望的SOA的有机发展，但必须对其加以有效管理，以避免它对SLA和SOA的有效性产生不良影响。在评估流程中，服务工程组应确定：服务是否按预期得到利用，是否需要重新分类以维持或改善服务的期望水平。这种重新分类更改了管理一项服务从而使其能向前推进的方式，并需要在支持或投资结构上做出更改。如果该服务是水平服务，是一个最初为业务线使用而设计，而现已开始在整个企业范围内使用的服务，那么这一点尤其正确。这样的服务可重新分类为企业服务，并相应地加以管理。
评估阶段的另一个重要方面是，利用服务基础架构，收集度量标准来论证ROI和SOA计划的成功。业务和IT收益都可通过SOA度量标准的收集得以确定。确定ROI和SOA的成本收益是一个广泛的话题，超出了本文的讨论范围（在另外一篇我打算写的文章中将会介绍）。为简明起见，SSLC相关的一条度量标准是服务的重用水平。特别地，评估SOA程序未来成功情况时，度量服务的重用频率与创建频率对比情况的度量标准非常重要。要使度量标准真正发挥效力，必须从第一天起开始捕捉相关数据，并使之能与过去的度量信息进行比较，如先前IT计划中的上市时间、重用以及中断-修复循环的减少。
最后，SSLC的评估阶段应该用来促使下一轮候选服务与需求目录协同。使用度量标准能够直接表明需求目录中标识的依赖项是否精确地表示了实际情况。另外，服务使用和复合指出了另外的一些关系，这些关系保证了开发特定、可管理、可度量的服务。通过评估这些关系，这些服务可能会显然比单纯地通过SSLC的设计时阶段来实现容易得多。
SOA面临的新挑战
许多报告和文章都指出了SOA给组织带来的益处。然而，任何新技术都会同时带来新挑战。特别地，SOA SSLC和相关管理流程必须为应对这些挑战做好准备。下一节介绍了一系列挑战，一些是好的，另一些是不好的，但所有这些挑战对于使服务工程团队获得更好的理解来说都很重要。
变更
前一节讲述了SSLC的运行时阶段，以及它们与组织SOA计划的关联方式。有一个常规因素与SSLC一样重要，需要引起特别注意：变更——业务演化中无法避免也必不可少的组成部分。准确理解SSLC是一种很好的方式，可为变更做好准备，还可为实现SOA计划提供一致的方法论。管理SOA和SSLC中的变更带来了全新的变更管理挑战。特别地，将服务引入组织带来了许多新抽象，需要仔细加以考虑。像服务契约和策略等概念，要求用另一种方式来思考功能是如何开发的。这将需要付出时间和实践来把这一点做好，直到共享服务团队可在整个组织范围内促进某种形式的一致性采用。
SOA还引入了这样一种可能性，在某个特定的时间，组织在生产中可能拥有多个版本的服务实现。这种想法不适于很多组织，也带来了管理和支持挑战：应该在多长时间内为用户的应用程序的先前版本提供支持、更改版本却不造成有害的逆向效应的能力，以及通知用户即将进行更改的能力。我遇到的很多组织都只是通过管理“强制”用户迁移到最新的服务版本，从而解决这些问题。尽管这确实是一个解决方案，但是一个更成熟的组织可以为用户提供一个机会窗口，使其能够在需要时才转到最新的版本，通过一个服务注册库提供对以前版本的支持，并利用服务契约的灵活性提供无缝的变更控制、请求转换等等。您需要记住，SOA是用来提高组织敏捷性的。要求应用程序团队升级到服务的各发布点可能会被认为对此类敏捷性有害。
打包应用程序
SOA计划在组织中取得成功的另一项新挑战可能来自令人出乎意料的地方；就是现有的打包应用程序。目前，大多数供应商为其产品中默认启用的功能提供web服务接口。取决于组织中这些打包应用程序的大小，它们可能引入数以百计的服务，这些服务可能并不符合您所建立的服务指导方针。未被结构化的服务的涌入可能会对SOA计划的成功造成严重破坏。这些服务可能不符合SLA需求，可能需要通过与企业组相对的业务线进行管理，并且可能导致依从性方面的问题。如果所公开的服务发布自核心企业系统，比如CRM、Data Warehouses和ERP，那么这一点尤其正确。强烈建议组织建立管理模型的一个方面，来明确地处理应公开并相应地管理哪些服务。此类方法之一可能是：通过SSLC的发布和供应阶段提供额外的服务策略或契约，来控制打包应用程序。与安全和管理阶段的一些准备工作相结合，此方法可能减轻您组织中难以管理的服务的增殖。
文章来源于领测软件测试网 https://www.ltesting.net/
