【转】SOA重在解决业务需求而非架构方法

        尽管很多家软件厂商的销售下跌了很多，面向服务的架构(SOA)却是你需要做的事情，而不是你要买的东西。就像ZapThink多年来一直说的那样，SOA包括了最好的实践，再加上需要遵循的准则。预期通过购买软件来获得架构就如想通过购买钢琴学会弹奏莫扎特一样。

　　不论如何，尽管很多组织到今天依然在与它们的SOA提议相斗争，因此，它们开始寻找外界的帮助，令它们能与自己的SOA发展同步。一些企业转向 供应商寻求帮助，另一些转向了咨询公司，还有很多发现最有用的SOA协助来自于能提供产品和专业服务相结合的供应商。与你寻求SOA帮助的公司类型无关， 虽然在某些方面你必须选择那家企业——而且那往往意味着汇总征求意见书(RFP)，同时让其在潜在的供应商之间流通。

　　然而汇总SOA的RFPs充满困难。那么你想要第三方为你做些什么?不管你是否在购买软件、专业服务或是它们的组合，从你的IT环境你会第一眼 看到SOA所能提供的更大程度上的敏捷性给你到来的机遇。还有撰写RFP的传统方法是将一系列指定的需求列入清单。那么，你能描述出这样的SOA的RFP 吗?该RFP能详细说明组织对敏捷性的真实需求，并且以这种方式你能比较你可能得到的回应，并做出正确的选择。

　　基础的RFP错误

　　为了避免这些缺陷，了解这些缺陷所在的地方是很有帮助的，所以让我们先看看组织在寻求SOA帮助时常常会犯的一些RFP错误：

• 　　混淆架构和实现——不太可能的是，你的架构仅制定出你的SOA计划这一件事，但是如果你需要SOA帮助，这就意味着你还没有准备好详细说明任 何一种实现。SOA RFPs中不需要任何关于你所预期的你的供应商将提供的具体技术的描述。因此，你应该避开任何宣称你能通过购买任何具体产品而获得SOA的供应商。
• 　　试图贪多——你的执行团队在商业周刊上读到了SOA而且现在就想要一个?所以你汇总了大量详细的RFP，这些RFP描绘了你的供应商将你从现 在的欠佳状态带入SOA的天堂世界所能做的所有事情。非常遗憾，它达不到这个要求。在你描绘你的SOA旅途上更一步的任务之前，还需要了解很多未知之事， 克服展演的文化和政治问题。
• 　　预期供应商在它们的回应中提供SOA建议——你想证实你的供应商有足够的SOA经验，但要求它们在建议书中提供具体的建议是不公平的，毕竟，它们提供的最好的实践是它们提供给你的核心价值。客户参考是验证供应商资格的更好的方法。
• 　　预期可通过客观的准则来比较建议书——政府组织往往有这个要求，征求少量的建议，然后用正式的准则比较它们，以免产生任何偏颇或是歧视。不幸 的是，在评价与SOA相关的专业服务的建议书时，这些正式的准则是不充分的，因为在SOA的方法中一个组织与另一个组织之间有太多的变量。因此，这些客观 的准则只得着重于不是那么重要的细节(往往是技术能力)，而不是更加重要的架构技巧和人机互动的技巧。

　　关键的RFP技巧

　　现在你已经知道了需要避免的一些较大的缺陷，这是一些将有效的SOA RFPs汇总的技巧：

• 　　预期并鼓励实现SOA的可重复方法——将可重复方法运用于你的SOA提议，该方法结合了自上而下与自下而上的活动，展示了依据该方法的商业价 值，是一个已建立SOA的最好实践。因此，对于很多组织来说它在重复处理它们的RFPs时也是有用的。首先提出SOA试点计划的RFP，仅当完成了这个试 点并评估了成果之后在转向下一个RFP。你在何处开始以及你处理各种发福的顺序依赖于你的组织，还有你学习经验的方式。
• 　　寻求强大的组织变革能力——SOA 的技术部分是最简单的部分。处理那些为了能与SOA一起进步，你的组织所必须经历组织变革和政治变革要复杂的多。你也许已经发现你的RFP中心更多地在于 变革管理、沟通以及传道技巧，而不是如建模、需求聚集以及系统设计等传统的架构技巧。
• 　　采用客观的评估技术——仅仅考虑哪个供应商能将你的老板带入最好的饭店是不够的，通过从技术和组织层面来考虑供应商与你的组织的适合程度来评 价这些建议书是很有用的。成功的SOA提议依赖于组织变革，所以寻找一个能有效担任变革代理的供应商是最基本的。最机敏的技术供应商也许没有驱动你的组织 变革的能力，因此将撞到南墙，而最有效的供应商也许没有深厚的技术力量。
• 　　不要只专注于SOA——这个建议是最违反人们的直觉的，但也可能是最重要的。你会遇到一些问题催促你考虑架构的改变，或者你不愿已开始就撰写 RFP。然而，代替在RFP中描述解决问题的方法，而将你的精力放在描述问题并让供应商用它们自己的方法来解决它们。接着通过分析这些方法是如何面向服务 来部分评价这些回应。在这里你不是寻找具体的活动，而是供应商的整体方法和逻辑。

　　ZapThink建议

　　如ZapFlash的标题所示，SOA RFPs的弱点在于整个RFP流程未能很好的适用于SOA提议。SOA的核心商业动力在于业务的敏捷性，而要真正做到敏捷，业务必须在商业环境中很好的处 理变革以获得竞争优势。然而传统的RFPs与敏捷要求格格不入，因为RFP的性质要求其拥有具体的要求。

　　即使是那些拥有足够的内部自我处理SOA的能力的组织，传统的需求⇒设计⇒开发⇒测试⇒配置方法论是与SOA完全不适合的，原因在于构建不断变 化的需求的必要性。所以，对于将引入第三方的组织来说，需求⇒RFP⇒设计的方法已不再有用。相反，组织应该寻找能将SOA提议在组织以及技术前台推进的 供应商，并持续的专注于业务问题的解决。

　　实际上，对于组织以及其供应商而言，最成功的第三方关系遵循这个模式。最成功的SOA咨询企业是那些更多的专注于解决业务问题，而不是传递架构 方法的企业，是那些与它们的客户建立和伙伴关系走得很近，更多地传递整体业务改进而不是具体的、已定义好的方案的企业。与之相似，最成功地利用第三方专业 知识的SOA提议是那些将供应商带入业务的各个不同方面的提议。然而，这种关系很少与RFPs想适应。实际上最好的SOA咨询和顾问企业总是避免笼统地回 应RFPs，因为那些一开始就将它们分离的组织往往还没为SOA做好准备，因此不能为客户做出很好的成绩。