创建适用于域间SOA技术的商业案例

    你会发现“当前”架构的低效率所造成的成本消耗几乎等同于利用通用域间技术方案（比如ESR）的“将来”架构所带来的价值。我们通过两次计算的对比得出了解决问题的价值和解决问题后所产生的价值。如果你的比值超出了30%，那么你可能需要重新进行分析，或者重新检查你所用的技术方案。要记住没有任何东西是完美的，很可能你在企业架构中实行了优化却没有得到成果。你只要尽力就可以。

    此外，你还要考虑我们之前讨论过的其它因素，包括复杂度--这是成本消耗或收益的乘数。实际上，你的架构越是复杂，那么它低效率时所产生的成本消耗就越大，而优化后所带来的价值也就越高。这个复杂因子通常在0.5～1.5之间。

    与复杂性一样，你也要同样对待重用性--即微域内外重用的服务的数量。你可以将这个看作一个百分比，服务重用百分比为15%--这是一个很常见的比例。你也可以将其看作一个乘数因子，根据重用的服务数量它通常在0.95`1.05之间。某些企业几乎不重用服务，也有企业重用很多。这取决于业务与架构的需求。

    虽然我们上面定义的分析性问题可以产生一个相当诱人的商业案例，但是实际价值通常在难以定义的软性问题上。不过它确实能提供一个更为有效更为积极的IT架构，能让顾客和雇员都感到满意。你的具体方式要取决于你的业务范围，但是不管怎样，它所能带来的价值是很可观的。

    实际上SOA在小部门层次的问题域上（即本文所提到的微域）几乎没有什么价值。因为，要想取得SOA的价值，我们就要建立一个策略在企业范围（或宏域）内同时共享服务和信息。这是让你的商业案例发挥作用的第一步。

    要实现这一点，最好的办法是明白你自己的业务驱动，然后做出一个计划从徽域和宏域两个方面解决SOA问题，这意味着以渐进的方式解决各个域和业务中的问题。还有，你必须确定在各个域中和域间发生的信息和服务共享问题，以及相关的技术问题。SER应该具有良好的扩展性、安全性和可靠性，并且是标准的、和技术无关的。就像连接各个城镇的高速公路一样，你也必须连接企业内的各种技术，从而最大化SOA的价值。