规避SOA治理技术影响的9条战略

3.确保治理平台支持所有的服务部署技术

适用范围：设计阶段

有不少人将Web服务看做是实施SOA的唯一方法，事实上，其它技术也同样可以胜任这一工作，其中包括Javaobjects、CORBA等等。重要的一点是，你的治理平台必须能识别这一系列的服务，不管选择的是何种实施战略。

如果你所选择的治理解决方案无法满足这些要求，那么结果要么就是只能进行部分治理，要么就需要再添加其它治理平台。相信这些结果都不是企业希望看到的。

4.认识测试在整体SOA治理中的重要性

适用范围：测试和质量保证阶段

在“测试”上给予足够的重视和时间，同时测试的内容不仅是针对个体服务，也要包含复杂的多重服务组合。合成测试通常是由回归测试（regressiontesting）的绩效所驱动。由于在运行时的合成使用很难去辨识，因此最好是部署监控技术来判别真正的服务互动。最后，鉴于测试和治理两者之间密不可分的关系，建议在你的整体治理环境中集成有效的测试软件。

5.收集治理相关的重要度量并定期评估

适用范围：运行阶段

现代治理平台能捕捉大量的操作型数据，而收集足够的度量是评估和采取行动的基础。这些度量通常需带有智能，可用来预测和防止问题的发生。或许有些治理解决方案的图形化能力参差不齐，但你可以采用一些BI产品作为补充来对数据加以分析。

6.在多层IT资源中追踪SOA活动

适用范围：测试、质量保证和运行阶段

尽管SOA活动的目标是将商业逻辑集中到可重用的服务上，但是具体到结构的搭建，就会牵涉到很多活动组件。其中任一组件的失效都会造成问题，而要识别出问题的源头更是庞大的工作量。况且在很多情况下，问题并非出在服务上，而是在下层资源上。

不过用户不会去关心问题出在哪里，他们只要问题得到解决或防止。因此，治理平台要能够监控资产并与资产互动，优秀的治理解决方案可以防止问题的发生，及帮助你快速解决问题。

7.选择治理技术前先准备好RFP

适用范围：所有阶段

评估和选择解决方案是一件繁重的任务，从一开始，你就要去了解到底需要什么：按照你选择数据库、应用服务器和其它基础架构技术的方式，编写一个能够反应出企业实际需求的RFP（软件需求提案）。

如果公司内部缺少这方面的经验，可以考虑聘请外部顾问来编写。然后让厂商认真参考RFP，这时应注重质量，而不是数量。一旦收窄了治理解决方案供应商的范围，下一步就可以要求厂商提供试运行来验证解决方案的实效。

8.避免要求修改代码的治理工具

适用范围：设计阶段和运行阶段

为了能有效使用，有些治理产品在购买后需要进行一定程度的代码修改。这就对开发人员产生了很高的要求，稍有错误，就会造成数据的不准确和不完整，导致最终决策的偏差。代码编写会给开发人员带来更大的复杂性和变数，降低有效治理的可能性。

9.确保工具适合现有IT治理格局

适用范围：运行阶段

对于大部分企业而言，SOA会带来一系列的新工具、新流程和新工作方式，而“治理”这两个字，其实已不算一个全新的概念。实际上，IT治理技术许多年前就已存在，这些治理工具通常被用来监控服务器、客户端、网络和软件应用的健康度。随着服务在整体运算架构中所占比重越来越大，理想的方法是将SOA治理工具无缝与其它IT管理平台集成，否则，独立工具所带来的额外复杂性和培训要求只会降低人们使用治理软件的意愿。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友