SOA治理已经成为一个重大的问题。企业的IT小组和CIO围绕SOA、企业体系结构、软件开发生命周期(SDLC)等制订一些新的治理策略。从开发人员的视角了解IT治理,包括治理里程碑、治理的重要性,以及如何使日常工作更有效率等考虑因素。通过理解这一视角,您可以了解如何避免在治理问题方面与开发团队发生冲突。
一般说来,有关治理的文章讨论的主题是,随着公司在面向服务的体系结构(SOA)中逐渐成熟,治理所充当的角色发生的变化。企业体系结构(EA)小组开发治理策略和过程,而CIO则会组建委员会执行治理,与此同时,应用程序开发小组也在思考治理对他们有何影响。应用程序小组往往会有一种自以为是的态度:“企业里的那些家伙,他们不了解我的工作和事务的优先顺序。我没有时间和资金处理这个!“
本文会向应用程序开发团队阐明治理的价值。它还能帮助架构师理解开发小组的观点,并了解如何调整他们发出的消息才能更容易被接受,受到较少的抵触。
什么是治理?
最近有一篇developerWorks文章“SOA治理简介”(这篇文章的链接,请参阅参考资料),对治理进行了详细讨论。它将治理定义为一套建立和执行的方法,用来使某个小组同意在一起工作。
治理意味着授权。它提供一个策略和最佳实践的框架,可以用这个框架定义谁有权做出何种类型的IT决策。它还能指定应对这些决策负责的人员。很多分析人员已经清晰地划定了治理和管理之间的区别,而重申这一区别是十分重要的。
治理与具体的IT决策无关;它会决定有能力做出这些决策的人员所充当的角色。管理则通过治理指导原则获得授权,并做出具体的IT决策。
您感到困惑吗?想想您的SOA项目;这种项目中的治理比传统项目中的更复杂。现在您构建的服务规模更小了,大家都希望(而且应该)重用它们。治理策略经过定义,用来控制这些服务的生命周期以最大程度地实现重用。您必须经常对各种问题进行监视,例如,是谁公布了服务,服务是怎样设计和构建的,由谁支付其费用,由谁管理安全性,等等。
治理是SOA项目成功的关键。没有治理,您就不能充分理解SOA的价值;没有治理,您手头的工具可能会变得一团糟。
为什么要治理?
治理的价值也许还不甚明显。可能要到第一个SOA项目完成后,您才会开始意识到治理策略的重要性。不过,许多SOA的实践者都会有强烈的感受,认为您应当预先定义这些策略,甚至在您开始第一个项目以构建服务之前就应进行定义。
治理能围绕服务创建、服务发现、服务标识和重用等制订规则和策略,以避免混乱。它针对服务的执行方式定义了服务水平协议(SLA),令使用者和提供者都能明白他们所受的限制和抱有的预期。简单地说,治理为提供者和使用者提供了相同的服务质量视图。治理还可以定义在整个企业内注册和发现服务的流程,从而避免或减少冗余服务和重复工作。
治理策略确保您遵循标准的流程,并使流程中的每一步都有适当的文档记录。这可以使法律、法规和其他遵从性规定(如Sarbanes-Oxley法案)得以执行。
在实现治理结构时避免出现常见的问题
应用程序开发团队和居于中心地位的EA小组常常会发生冲突,因为EA小组是在一个理想的环境中设计流程、过程和指导原则的。他们往往不会把细节告诉所有的项目团队,以使后者理解他们独特的项目需求、时间安排和业务驱动因素。上一句话的关键词是所有。EA小组可能会觉得,只告诉下列小组就足够了:
·从事最大项目的小组
·从事的项目可见度最高的小组
·最易于相处的小组
没有被咨询的应用程序团队会有受人排挤的感觉。这些小组对治理的实现将抱有严重的抵触情绪,会对SOA活动的总体成功造成障碍。
对于EA小组来说,更好的办法是开始时先用一个较小的项目展示治理具有的价值。通过这一方法,他们可以很快向其他小组显示出这种价值,并类推出较大的项目可以从中得到的好处。
在这些EA小组中,建议将策略的制订者和执行者分开。EA小组应起到导师的作用。他们应该告诉应用程序小组如何使用更好的设计指导原则和遵循标准实践,并向这些小组解释治理策略。他们不应承担类似“警察”的职能,即确保各个应用程序小组遵循所有的治理指导原则。执行治理策略的工作应该留给指导委员会或某个得到授权,专门充当此角色的治理机构来做。图1显示了一个概略视图,介绍CIO办公室是如何组建这样一个机构的。
图1. 治理结构
图1 中显示的不同人员必须共同工作,以确保SOA和各个单独的项目取得成功。治理审查委员会是一个负责定义策略的小组,而企业架构师则是这个小组和业务线IT小组(应用程序架构师和开发人员)之间的粘合剂。如果这些小组间常常发生冲突,您的SOA就不会取得成功。本文剩余的部分将讨论企业架构师、应用程序架构师和开发人员在项目中应扮演的角色。
针对企业架构师的治理
假设您的组织已经对治理进行了定义(无论您是否拥有组织结构),如图1所示。您作为企业架构师,可能参与了(或未参与)治理策略的定义工作。您下一步该干什么?
SOA治理改变了社会关系。企业架构师充当的角色是老师或教育家,而不是警察。督管的工作可以由审查委员会来执行。作为应用程序团队的指导者,您的角色是向他们介绍治理的价值,让他们了解如何从治理过程、策略和工具中得益,以及为遵循这些策略而做出的额外工作是怎样使他们更有效率、实现更高的业务价值的。您必须成为一名推销员,努力理解应用程序团队对新策略的看法,并帮助他们将治理融入流程之中。要同情他们的感受,但也要做好回答难题的准备。您必须理解和欣赏治理的价值,然后才能使别人和您的想法一致。
企业架构师的另一项工作是持续监视SOA的治理策略。您必须注意哪些策略被采用,哪些没被采用,哪些需要进行调整。您必须与审查委员会进行联系,确保按照要求进行了策略的修正或创建工作。您还必须确保策略被明确地记录在文档中,并使应用程序架构师与开发人员与最新的策略保持同步。
治理程序的成功依赖于企业架构师。如果您与应用程序架构师和开发人员的交流在一开始就很顺利,那么这将有助于整个项目更加平稳地向前发展。
针对应用程序架构师的治理
面对治理,大多数应用程序架构师的第一个想法就是“上面的家伙在监视我呢”。这种反应是正常的。不过,作为一名应用程序架构师,您必须理解治理的价值并适应它。治理会帮助您在人员和流程之间架起一座桥梁,您的注意力将得到扩展,不再只关注应用程序或项目了。您的角色不仅仅是确保自己遵循所有的治理策略和流程。您还必须证明这些策略是否有效,帮助您的团队理解这些现有的策略并从中获益。您必须确保现有的工具能使您以更有效的方式提供应用程序或服务。
治理应使应用程序架构师不必替团队打理这些流程和控制措施,而是将更多的精力放在业务和体系结构问题上,为项目设计出更好的业务解决方案和服务。合作和沟通是最重要的。
值得注意的是,治理并不会接管您的工作。您仍然要扮演架构师的角色,负责设计应用程序或服务。治理只是提供指导原则和参数,帮助您进行设计。它会回答一些与可伸缩性、可用性等等有关的问题。
针对开发人员的治理
作为一名开发人员,治理对您的影响是最小的。它不会对您的日常工作造成影响。治理更像是政治而不是技术。就让您的架构师或项目经理去处理政治方面的东西吧,从您的角度来看,治理策略提供必需的工具、最佳实践和指导原则,可以使您更有效地从事项目工作,提供解决方案或服务。这些策略是用来降低您的工作压力的,它能确保您构建和管理服务的方法保持一致。
治理策略会告诉您如何构建服务、怎样找到由其他人构建的可用服务,以及您的服务应当遵循哪些SLA。它们还为您提供了进行这些工作所需的工具。治理能减少在实现SOA时的不可预测和未知的因素。因此,采用治理能够提供一组可供遵循的清晰标准和策略,从而降低被别人指责的可能性。
总结
SOA是一种基于服务或面向服务的企业体系结构(EA)。围绕着治理出现的问题已经不算新闻了。在IT组织中组建EA小组或项目管理办公室(PMO),是将要使用治理的先兆。好处和挑战是并存的。不过,随着IT组织沿着SOA成熟度曲线不断向上移动,治理也变得越来越重要了。作为IT团队的一员(架构师或开发人员),您无需害怕治理;您应该热烈欢迎它,因为它能帮助您减轻工作压力。您的工作会更有效率,因为治理去掉了某些未知因素,并对某些关于SOA的基本问题作出了回答。它还能帮助您满足法律方面的需求,如遵从Sarbanes-Oxley法案。
治理和SOA需要团队合作。总的来说,所有不同的相关人员必须协同工作,以确保SOA和各个单独的项目取得成功。
关于作者
Kunal Mittal是一位擅长Java技术、J2EE和Web服务技术的顾问。他已与人合作出版了多本有关这些主题的书籍。Kunal目前在Sony Pictures Entertainment中担任Domestic TV IT部门的主管,他负责该部门开发的应用程序的技术架构及管理。有关更多信息,请访问他的网站www.kunalmittal.com,您也可通过kunal@kunalmittal.com与他联系。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
SOA治理模型核心:人
治理在IT领域非常关键,但是很多时候企业的做法往往太过单向,企业SOA治理模型往往忽视了所有部分当中最关键的组件:人。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。