【转】你的SOA团队不应该说的七件事

我们的天气可能正冷却，但是SOA世界的正在升温中。 当它在世界上在一些最大的公司遇到企业架构团队时，ZapThink听到了关于这温暖的消息。 在一个这样的会议上， 正被讨论的公司让在他们的组织中的来自各个角落的的企业架构师们来讨论他们在实现面向服务的架构(SOA)的计划图。 大约25 人的这群聚会在将近6 年里是第一次。SOA是这个最新的会议存在的理由，也是一个SOA更进一步升温的迹象。我们花费两天检查他们面临的向SOA转变的技术和机构化挑战。 在这fest架构结束之前，他们已经推敲出一些关键的行动步骤来帮助他们推进他们的SOA 计划。

　　在我们在第2 天包起之前，他们已经关于他们的通向SOA 采用的路径做出了具体的关于下一步的决定 -- 但是最很好地显示的发展是实际上从他们的讨论丢失的。 特别的，我们在他们没说的7 件事情上明确称赞他们 -- 公司在他们引导他们的方向到相反的通往SOA的道路的时候面临的一些复发的陷阱。 通过避免这7 个陷阱，这些公司相当显著地推进他们的SOA 计划。

　　因此， 我们想借此机会与你同享我们注意到的什么是缺席的，以便你也能避免这些你们的在采用SOA过程中的障碍。 这里， 然后，是7 件事情你应该保证不在你的企业架构团队全体会议期间说:

　　1.让我们从我们更喜欢的卖主得到我们的SOA。 因为ZapThink 以前已经解释很多次，你不能从软件得到SOA，因为SOA是由最佳实践组成的。 既然架构是你要做的一些东西，而不是你买的东西，所以你必须在选择软件之前苦心推敲一个构架的计划。很多软件供应商正把他们的产品定位为SOA 实施的秘密的调味酱， 或者更坏，他们在说公司应该把他们的整个SOA 部署建立在他们的平台上。当卖主提供功能性的重要的元素时， 你不能从任何产品得到你需要正确地实现架构的最佳实践，不管产品有多么好。 因此，当实现SOA时，首先决定要架构，然后才是软件

　　2.(这里用3 个首字母缩略词代替)在哪里? 人们喜欢3 封信首字母缩略词-POA，EDA，SOA，ROI，凡你想得起的。 最过于让人兴奋的技术术语列表之一，例如，是企业服务公共总线(ESB)。 没有人对它是什么达成完全一致意见，但是好像每个人都认为他们需要一个ESB来使SOA工作。 的确，ESB 描述了把具有可靠的消息传输的联合分布的服务中间者所具有的一套能力。 但是很多公司正意识到他们已经有很多这样的能力，因此能使用他们的现有的基础设施实现ESB。 当你已经有足够的中间件的时候这对你是一个好机会 -- 因此寻找ESB(或者任何其他3首字母缩略词，为了那件事情)经常是错误的开始地方。相反， 从架构开始，确定那些最好的方法来实现松耦合的，分布式的，可组合的服务并且然后再仔细推敲那些使之发生的最好的基础设施。

　　3.我们对那个部门的人们交谈。 我们的与大的公司见面的最满足的方面之一是整个公司每个的部门都能够出现并参与进来。 他们集合来自他们的全球组织的每个角落的建筑师精心推敲的他们的通向SOA 的道路图。当他们近乎实现分享的服务时， 整个组织可能不会利用他们所有的， 但是对你得企业架构有一个整体框架的图像从而可以从上往下的驱动你的SOA计划.通过不包括联网人群，安全专家，应用设计者，IT 专家或者经营品种专家在你得构架会议计划中，在你的建筑的计划的会议方面的专家，你不必要强制你的SOA努力的价值和范围。

　　4.你已经完全知道有关它的东西了。 SOA 以IT 和商业一同工作的方式引进了技术上，机构化和文化的变化。 仅仅因为你的确习惯于工作的方法而简单地继续支持旧方式，那将对你转移到面向服务的道路没有任何的帮助。 为使得你的SOA 主动性成功，你将需要集合交叉功能，交叉部门的团队。把不同的级别的人们混合和相配是一种政治，冲突和甚至混乱的烹饪菜单。 提出这些问题的最好的解决方法是一次解决他们一步， 并且第一步是每人愿意在队听其他并且尊重并且重视他们的意见。带有一些怀疑地接近SOA是健康的方式， 但是不要这样做而没有关乎于其它组的意见和意识到SOA 实际上将会改变你今天思考的方式。

　　5.你用你的方式来做SOA，我将用我的方式来做。 你怎样着构建架构和你将怎样着手使用架构，这对于公司来说，分清这两者是重要的。 只不过， 因为不同组织可能有他们创造服务的不同的想法和政策以及定义这些服务的协议，但是这并不意味着应该有多个SOA 实现。终究，对SOA的关键好处之一， 是松弛耦合的能力提供给用户灵活性从而使得一个部门消费服务的方式不必与一些其他部门消费他们的方式相同。但是为了得到那种要求的实施的灵活性，具有统一架构也是很关键的。那就是为什么公司需要把一个公司范围内的企业级架构团队集合起来是很重要的原因之一。如果架构师屈服于组织的自己的简仓倾向，那么结果最后的架构永远也不能满足SOA所承诺的。所以有许多不同的服务，协议，策略和过程是很好的。但是在一个组织里面有不同的企业级架构的竞争版本确是不好的。

　　6 让我们考虑一个不同的途径通往SOA。如果真的有什么可行的可以通向SOA的途径，那么我们将不会在一个企业级架构会议上听到这些问题，但是这个问题实际的情况是真的是没有其他的可选方法公司可以仔细的考虑。当SOA注定要在整个过程中演化，意识到SOA代表了一个更多地关注于企业级架构的机会，从而可以可以为争吵其他的途径提供借口。与其花费毫无结果的时间来争吵，更好的方式是讨论如何来正确的实现SOA和计划出你发展计划的下一步怎么走。

　　7 SOA 太难了。记住那个古老的格言，“你可以正确的完成它，或者你可以从做它”? 确定的，SOA是一个挑战，但是不同的却会需要更多的工作:弄清楚需要如何得到正确的SOA或者弄脏你的架构，从而你(或者任何在你走了之后得到你的工作的人)将会在某个时候需要去清理干净沿着路下去的脏乱?事实是，SOA是苦难的是你找到一些有价值的东西的指示。毕竟购买一些新的软件块是微不足道的，但是那样并不能单独解决你的精确集成和灵活问题。

　　ZapThink感受

　　大多数我们交谈的公司在他们的SOA计划上都在相同的地方很粗糙:非常多的Web服务活动分散在整个公司里面，关于SOA充足的讨论，一些松耦合服务，但是很少的整个企业内的架构活动的调整和协调。因为这个，简单的把企业内的架构师从企业的各个地方聚集到一起来，使得大家对SOA有相同的理解的行动本身就是在向SOA实现移动前进的重要和意义重大的一步。做这些打开的直线交流，允许不同的组汇报他们的进展，使每一个人能够加速计划，并使得团队有可以从像ZapThink这样的公司学到更多的技术的，文化的和组织的各个方面和SOA相关的知识的机会。这些小组具有的最有意义的目的是阐明一个单独的SOA故事使得这个小组可以有更高级的管理。开发一个单独的SOA商业案例和路标对于那些必须面对挑战的公司和团队的来说是一个巨大的胜利。

　　我们学到的最重要的课之一是一个公司不需要一个正式的命令来使得他的企业级架构一同工作。所以为了证明花在开会的时间和旅行的费用是正确的，执行支持是至关重要的，但是公司一旦发布了商业讨论的基础，只有企业级架构小组可以决定他们如何处理它们在整个组织里面的作为一个重要团队的SOA领导的行为的路标。所以，把目光聚集到把你的架构师从你组织的每个角落聚集起来的目的上来，同时避免掉进我们在上面说的陷阱中去。这也许听起来像一个令人畏缩的任务，才把所有需要的人都聚集起来一起使得SOA能够成功，但是即使是最大的公司也很可能没有超过一打的具有必要的范围的职责的企业级架构师来作为为重要的力量的加强来增强你的SOA努力。找到他们并把他们聚集起来，即使需要很多天，同时你也就可以在通往有效的企业级SOA的道路上了。