降低失败的成本

　　这里主要有四种降低失败成本的方法。或者换句话说，系统在不断变化，就是要增加系统整体成功的可能性：

　　·模糊性——对于开发商和设计师来说，最令人头疼的部分就是设计未知要求。当然，如果发号施令的人不知道要干什么？别人也无法完成任务。但是我们经常被要求完成一些不明确的任务。很多时候，业务部门要先看过具体的实施以后，才明白自己究竟想要什么。他们需要的是一个原型。像领航员一样，原型是一个真实可交付模型，无需花费过多的成本，你就可以轻易的改造和处理这个模型。

　　如果你要把SOA的各个方面都设计成原型，就会产生模糊性。这里的模糊性不仅局限于服务合同——SOA基础设施也会出现同样的问题。那么在你不知道服务如何使用的情况下，为什么要花费一年的时间500万美元的巨资实施ESB产品呢？还是先从一个典型SOA基础设施方案做起吧。但是对改变做出预计，并不代表要浪费时间！仔细思考，猜想一下你所需要的服务，并时刻铭记，合同、颗粒性、治理、管理、安全性这些方面都有可能发生变化。向业务展示这些成果，这样他们就可以利用这些成果，更好的定义自己的要求。如果你设计原型的速度更快，使用的成本更低，质量更好，你就会成功的更快。

　　·设计灵活性——当你注意到技术或者业务的某些部分经常发生变化，在设计系统之初就该意识到这种变化的可能性。从SOA方面来看，我们可以依靠抽取的力量来满足这样的可变性。我们在ZapFlash松耦合的七个方面这篇文章，以及随后的网研会和白皮书中都曾经提到过实施可变性的方法。如果你能实施抽取，创建灵活性，即使事情发生了变化，你也不会太过失望，从候选的服务、合同、元数据、模式和流程做起，记住它们会发生变化，当变化发生时，要保持心情舒畅。

　　·重复工作——面对不断发生的变化和模糊性，设计和实施也不能保证完全成功。同时你还要调整自己的机构、方法、实践，而且还要为持续的变化做好预算。多年以来，我们一直倡导从瀑布式开发转移到迭代式开发，因为迭代式开发自然会迫使机构计划技术，流程以及预算方面的变化。正如我们最近所讨论，抛弃这种以项目为核心的想法，对我们帮助很大。同样在促进迭代的数量、质量以及效率方面，也要杜绝组织优秀这种思想。

　　·经常测量——准许模糊性、设计灵活性、可迭代性并不能保证会获得成功——你必须保证方向性正确！失败乃成功之母，这种想法可以帮助消除完美主义者恐惧。我们需要按照成功标准，衡量每一个迭代和实施需求。这些成功标准可能是功能性的也可能是非功能性的。这些标准也许和可获利性这样的业务量度或者性能这样的技术量度有关。只有知道用什么测量，你才知道怎样管理，这样才能确保你一路的失败最终会通向成功。我想，如果我告诉你以上几个步骤很容易做到。

　　你肯定认为我是在有意误导。Business-IT环境中的许多事物都和SOA的“失败乃成功之母”策略背道而驰。一方面，IT预算仍然深深植根于“只能做对，否则后果自负”的支付——祈祷实施方法。似乎预算、计划和资源之间没有任何回旋的余地来重复做某件事情。我们的回答是：改变你的预算、时间计划和资源配置，因为你在不断重复这些工作，如果你能给我指出一家第一次就获得成功的公司，那你就能获商业界的诺贝尔奖了。

　　阻碍重做SOA方法的另一个力量就是SOA咨询师使迭代变得异常昂贵，无法实施。如果你让咨询师为你实施SOA，你就是在告诉他们，你需要的是什么，如果他们给出的结果复合你的要求，你会非常高兴 。但是如果你的期望发生变化了，又该如何呢？交付的结果现在可能没问题，可是谁又能保证明天会怎样呢？如果你一开始并不知道自己想要的是什么呢？如果咨询师本身也不是很了解SOA呢，你不过是他们的实验品（这种事经常发生），外包，生产和使用第三方似乎更倾向于支付——祈祷这种方法。精明的咨询师知道他们的工作是帮助迭代，并改变他们的实施和业务模型满足迭代。敬请继续关注我们的栏目，我们将针对这一话题做出更加详细的报道。

　　ZapThink采取的措施

　　SOA的整体观念就是在使用和组合许多不同类别的，被抽取的服务过程中保证灵活性。在保证变化的前提下耗费的成本越低，业务的灵活性就越大。

　　如果你发现改变服务会打乱不同层次的抽取，你就应该明白，自己的架构存在问题。即使你能证明自己可以创建服务，并不意味着你可以证明不经破坏就可以做出改变。要想实现这一点，你必须有意把事情做错，这样才能证明你是对的。