不管SOA的未来如何,至少当前的SOA可是生龙活虎。SOA的核心理念,像成本节省、提高生产力、消除信息和应用孤岛等将继续存在下去。但是,随着“SOA”越来越像云计算王国的一部分,它很有可能会发展成别的东西。
最近,最受欢迎的想法就是重新定义SOA,重新考虑构建、管理和扩展这个基础设施的方式,以使其能够真正与业务目标统一。其中,最有效而且节省成本的一个办法——也是被成百上千的成功施行者所证明的方法——就是治理。
但是,如果没有一个对业务目标的清晰认识,而只是简单地应用治理,却可能起到反效果。这里的关键是要了解哪里、什么时候治理才是最重要的。
各种大小规模企业的经验积累证明,迈过以下“八扇大门”才能制定成功的治理过程。它们作为指引治理过程的蓝图互相之间是互补性质的,而且能够解决软件开发生命周期中不断增长的复杂需求问题。你可以先将这些方式应用到一条生产线上,然后慢慢体验更详细的设计和开发,最后再部署到整个生产。
在你构建和部署SOA时,是否遵循了这八条建议可能就是失败与成功的区别所在。
第一扇门:定义业务需求
在这个阶段,许多企业的业务和IT领导人都在无意间做出了不实际的期望值。在一号门,重点是决定业务目标和需求,并且清晰地描述技术如何对这些目标的执行提供支持。
除了列出业务目标、相关需求和关键的性能指标,还必须在主要利益相关人之间建立一致的标准以验证各个阶段。
而且很重要的一点,可能也是很明显的,就是要抛弃缩写、术语。有些最成功的SOA项目领导人甚至很少对业务领导人使用SOA这个词。
第二扇门:保持方案架构的一致性
对于有多项IT活动进行的大型企业来说,各开发团队不可避免地会使用不同的方法解决业务问题。虽然这可以产生不少最佳实践,但是更经常地会产生困扰、臃肿和由于复制软件证书和人员调动而引起的成本增长。更不用说由于复杂性的提升所带来的架构可靠性、稳定性和互通性的降低。
以门一中的业务需求定义为基础,门二主要是建立构建服务所必须遵循的清晰的标准、政策和最佳实践。这些标准包括参考架构、平台标准、软件利用标准和重用政策。
第三扇门:服务识别与规范
简单地说门三就是:要知道你将去向哪里,首先要知道你已经到过哪里。在这个阶段,重点是识别当前的服务并从技术和业务角度决定其对企业的价值。
许多企业在检查他们的架构时都会被他们的发现吓一跳。在这个过程中,他们经常会发现臃肿的服务和不一致的业务过程执行方式。一个支持自动化方法并且提供早期缺陷诊断的治理策略可以显著地减少部署时间并提高ROI。
第四扇门:服务设计
继架构和评估之后,门四是以服务设计为主——根据当前的情况考虑如何设计企业的服务。服务设计可成为架构规范的指引,并验证是否遵循所有的设计策略及标准。
从这一点来说,治理可以解决诸如定义服务模式、决定构建服务的具体技术,以及验证是否已经满足所有需求等问题。另外,它还能仔细检查用户界面,为顾客、合作伙伴和其它利益相关人保证其以业务为中心。
要注意这第四条建议代表了架构与开发执行上的转换,因为它要求公司采用并加强统一的设计模式。毕竟,不一致的设计方式将产生不一致的结果,并可能使企业处于危险之中。
第五扇门:服务构建
有趣的是,许多架构设计师和开始人员都错误地把门五当作SOA的第一步。而这里它是构建服务的重要一步。
从上面几条建议我们可以看出,如果没有清晰地定义业务需求、了解当前情况,而直接跳进服务创建这一阶段的话恰会产生反效果。必须认清JBOWS(一打网络服务)与SOA的区别。
在服务构建阶段,应该注意验证开发重点是否与在方案架构及服务设计阶段确定的政策、最佳实践和标准一致。
如果治理是架构的重要组成部分,那么它就能保证对所有新服务进行检查。理想情况下,这是由一个自动过程进行的:根据开发组件跟踪其源码并在服务的整个生命周期跟踪其质量。有了这个与组件相关的信息,重用的潜力就会以指数倍地增长–因为审核跟踪会一直伴随着服务质量。这样,在部署组件之前就会先对其进行检查以确定其符合相关政策。
第六扇门:服务测试
部署之前,先要对服务进行测试,而这正是SOA治理起关键作用(检测服务的政策相关性并截取潜在的错误代码)的另一个地方。
虽然有许多测试工具并且架构设计师和开发人员已在使用,但是在部署服务时还要根据一些特殊标准进行测试。而且服务测试一定要包含:
· 允许迅速更换测试软件的自动构建环境,
· 测试非功能性需求、规范、创建、和测试数据加载的负载/压力测试工具,
· 可以持续向管理层报告测试状态的测试管理报告工具。
第七扇门:服务认证与部署
胜利即将到来,门七的任务即是将服务融合到产品环境中,并且最小化客户端故障时间及其对业务的影响。从本质上来说,你是在保持业务运行并且对客户、合作伙伴和雇员保持一定的透明度的同时转换业务。
可能你已经发现,如果这一步由手工完成,会很容易犯错误。这正是自动化治理发挥光芒的地方,因为它能够保证迅速、准确地部署服务的正确版本,而且不会忽视对其进行最后的认证检查以确定服务符合政策与标准。
第八扇门:服务的生命力
显然,我们应该根据实际情况定期对治理过程、流程、政策和标准进行检查和更新。服务的生命力这一阶段是在进行中——特别是SOA迅速增长、服务持续添加的情况下检查服务的整体质量。
门八还为IT及业务决策制定者们提供了一种透明的方式来检测SOA的有效性和效率,并能先一步确定何时何地可能会需要发生改变。
结论
某些企业可能会把治理当成非必须的、浪费时间的“待办事项”,但是这种做法只会带来灾难性的后果。要注意自动化治理有助于流水线化软件开发生命周期,并且使其成为整体过程的无缝组成部分。
但是,成功的自动治理并不是随手拈来的。企业必须对其有足够的重视、有计划地进行,并且还需要领导层能够清晰地定义各种职责。它还需要成熟并且能够持续增强的政策和程序。而且,它还必须支持控制门的建立,从而从中反映并支持企业的目标和文化。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
SOA治理模型核心:人
治理在IT领域非常关键,但是很多时候企业的做法往往太过单向,企业SOA治理模型往往忽视了所有部分当中最关键的组件:人。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。