SOA很像一种园艺。它需要精心的照料,艰苦的工作。这个过程可能会很麻烦,有时候甚至让人沮丧。你肯定听说过数不清的类比,强调SOA与治理的关 系。但SOA绝不是简单地通过治理就可以实现。之前我从未认真考虑过这方面的问题,直到遇到一位客户希望我能在一个星期里帮助他重新整理可能要变成一团糟 的SOA“花园”。虽然,最后我们在各个方面都取得了很大的成功,但这并不是因为我们尝试了多么不同、多么先进的方法。我只是努力地将他们思想中的一些积 极因素付诸行动而已。
这里的情况是,客户是知道他们需要什么样的“花园”的。我们的工作是协助他们实现这个目标,而不是劝说 他们去培养一个不同的花园,或者简单地告诉他们如何避免可能会毁掉花园的“杂草”。我们要告诉他们如何培养自己的SOA“花园”,这样,即使我们离开,他 们也能有足够的能力照顾自己的花园。
我觉得SOA部署的顾问们将来可能会遇到越来越多的这种情况:客户们知道他们需要SOA,而企业也一直在强调“治理,治理,治理……”。这种情 况下,我觉得如果能将更多的注意力放在为这些需要SOA并了解治理重要性的企业提供建设性的指引,帮助他们将一些思想变成积极的行动,将会比较容易取得成功。
我们来看一下关于SOA的部分错误观念,以及如何将它们转化为积极的因素。
我们采用SOA是因为我们购买了SOA产品,但现在我们要的是治理。
我们今天就需要知道关于治理的所有细节!
能不能把其它公司成熟的治理产品给我们?
如何让所有方面保持同样的成熟度?
我们认为这应该是SOA治理的一部分,但怎么实现呢?
我们采用SOA是因为我们购买了SOA产品,但现在我们要的是治理。显然这里最大的问题是:认为SOA是一种买来的东西。还好那 些向客户们宣扬SOA的供应商们无法让客户相信SOA治理同样可以买到。这种情况下,必须澄清SOA治理不是去买什么东西,而是如何去做。就像培养花园不 是简单地把所有材料买对买全,而是还要在这些材料上付出努力,这样才能培养出一个漂亮的花园。我认为这时应该对客户所拥有的产品和工具进行评估,即使只是 从短期效益着手,也要明白这些产品对治理有什么样的作用,怎样有效地使用这些工具。至少,如果产品已经买了,那么企业就不需要再为这方面的资金费尽周折。 一般情况下,他们都会有一些对治理过程很有价值的产品。只要我们能让他们承认,他们可能会在不远的将来重新评估治理所需的产品,他们就能从现在开始进行治 理。
我们今天就需要知道关于治理的所有细节!之所以他们会这么说,很大程度上是因为那些被指派去解决SOA治理需求的人需要向他们的长官报告“我们 出色地完成任务了,我们是伟大的园丁。”公司外的顾问们需要帮他们改变这种态度,并不是所有细节都到位后,才能向上级报告。这里很重要的一点是,治理的一 个环节就是要了解治理机制将如何随时间成长。我们也可以将重点放在让他们学会使用现有的治理结构,并能根据SOA的需求做出简单适当的调整。如果我们能让 客户将精力放在开发SOA治理机制的计划上,他们自然会明白治理是如何慢慢成熟的。然后他们就会说“我们有SOA治理,而且我们有计划让它变得更好!”
能不能把其它公司成熟的治理产品给我们?撇开保密方面的问题不谈,从心理上说,这是一种“能不能把别人的花园送给我们?”的心态。这种想法认 为,如果其它企业已经走过了治理的过程,经历了成长的烦恼,那么我们就可以避开那些错误的行为,从而避免遇到同样的问题。虽然关于服务合约、策略和方法的 模板可以为我们提供一些指引,但必须明白的是,如果不能根据客户环境进行定制、验证,那么这些东西就毫无价值。不过只要客户能总是想到“这个模板对我有用 吗?”,我们就可以向客户提供一些通用的产品来开始这个过程。就像在花园中可以使用球根幼苗,而不是只能撒种子一样。
如何让所有方面保持同样的成熟度?这个问题是因为客户认为他们应该把精力放在那些滞后的元素上,而忽略甚至拖慢那些更为成熟的元素或部分。乐观 来看,他们至少认识到了应该特别注意那些滞后于总体成熟度的方面。你必须让他们明白,与其使整个花园保持同样的进度成长,不如成为能同时照顾凌乱部分和已 完成部分的双料专家。实际上,在SOA部署早期,确定那些更为成熟的部分并作为机遇加以利用,从而使有限的资源获得更有效的应用,可能更为重要。建立一个 “选择性的SOA”过程可以帮助确定哪些部分能提供更多的即时回报,即使只有一些比较抽象(更难评估)的效益,比如“更好的连通性”或者“更坚实的基 础”。另一点是不要勉强别人接受SOA。如果我们看到了一定的价值潜力,但项目中的另一些人没有,那么我们就应该继续进行下一个有潜力的项目,而不是使这 个项目“强行适合”SOA。因为这样要冒更多失败的风险,而这是我们在初期应该尽量避免的。过一段时间,当漂亮的花园成长起来的时候,让这些人变成虔诚的 园丁就会容易得多。
我们认为这应该是SOA治理的一部分,但怎么实现呢?这是客户在向SOA顾问询问一个具体的项目,他们想做是因为他们相信这是SOA治理的一部 分。一定不能在这里打击他们,除非他们确实太离谱。毕竟,我们不能仅仅因为自己不喜欢就把他们觉得漂亮的花朵扔出去。他们应该已经对SOA治理有了足够的 了解,知道这个项目是治理中的一个元素,而不是全部。如果我们否决了他们的想法,并强迫他们走上另一条路,那我们就是在做那些我们不想让他们在早期的项目 中做的事。应该尽力将他们的项目变成早期治理中的成功部分,并尽可能使用他们已有的产品。更重要的是要将这个项目作为SOA治理的一部分来评估其生命周 期,不管这个项目是否会在将来的计划中被加强、淘汰或者调整,或者有其它的将来可能使治理结构更成熟的不错的项目。
虽然这些安全不足以覆盖SOA顾问可能遇到的所有问题,但我认为这是在大多部署中最容易遇到的几个普遍情况。
一般来说,客户们会把SOA企业看作一个美丽的花园,却不知道如何实现。供应商们会说“我们没有完整的产品”,也不会担心每一件产品是否能在整体层次上发挥作用。因此我觉得,我们帮客户构建SOA企业时,帮助他们整理想法中比较积极的因素并付诸行动是非常重要的。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
SOA治理模型核心:人
治理在IT领域非常关键,但是很多时候企业的做法往往太过单向,企业SOA治理模型往往忽视了所有部分当中最关键的组件:人。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。