面向服务架构被吹捧为“必须拥有”。拥有它或者灭亡，IT分析师如是说，好像把SOA认为是一些规范的绝对值。然而，SOA作为一项技术并不能带来业务灵活性。事实上，在机构中部署SOA堆栈并不是敏捷的，开始可能会受到严重的误导和完全不利。在最坏的情况下，SOA没有从混乱的技术中解脱出来，而是在更高层次上建立新的噩梦。

　　在早期的博客中，我已经讨论了IT中服务主导逻辑的含义。因为整体的业务前景正在相对稳定的情况下发生变化，自给自足的企业中封闭的且可控的系统相对来说不固定，适应网络的、开放的且转换的系统已经存在,所以信息技术从集中的、独立的、专有的和整体的企业信息系统转向对等的、面向服务的、基于标准的和企业间模块化的复合程序。

　　然而，不同的行业正迎来不同程度上主导逻辑。并非所有的市场都是动态的。并非所有业务都需要最大程序的敏捷性。传统的IT和业务的对齐工作在相对稳定并且可预见的环境中合理地进行。如图1所示，IT投资成本效益平衡，在商品主导逻辑内部尤爱传统IT， 在业务技术中前期投资可能会“技术过度”。

　　相比之下，在复杂的、竞争的和非线性的业务环境中，新业务技术势在必行；否则，会出现“技术缺陷”。一个更具包容性的方法叫做企业治理——在业务和IT中会合。变化必须从架构的角度上解决，需要连贯的、一致的设计原则，整体地对各种业务和组织方面的问题进行整合。SOA构成这种融合和整合的基础。但是还需要一个敏捷的组织。

图1 必要的业务和技术路线

　　技术过度和技术缺陷都不可取。

　　无论如何，在所有行业中，总的趋势是朝着日益复杂、竞争激烈的商业环境发展。即使机构仍然遵循商品主导逻辑，也必须采取慎重的步骤，通过建立更高级别的机构，增加他们的“吸收能力”，IT能力与日益增长的市场活力的步调是一致的，惟恐他们会下降导致技术的缺陷。进一步采用技术，未能提高承载能力很可能会导致自我强化的“锁定”。

　　正如在以前的博客中讨论的一样，IT的重点是从纯粹的系统开发向系统间的能力和更具包容性的企业工程转移。为了充分利用业务技术的能量，整个机构应该根据服务的总体战略改造，并贯穿其每个方面。

　　技术过度也会引起业务技术滥用。如果机构从传统的、功能性的角度工作，技术往往参照相同的场景。一个典型的例子，BPM（业务流程管理），据说是SOA的“杀手级的应用程序”。然而，运行BPM会带来破坏敏捷性的风险，它宣称要实现这一目标。只有一小部分流程是不变的，足以允许他们通过BPM“管理”他们自己。大多数业务流程是不时的变化的，需要很大程度上的自主权来消除必要的BPM。不许多情况下，提高敏捷性的是信息，而不是自动化流程

　　IT基础设施厂商想卖给你SOA，如果他们没有卖出，会重新命名，然后再试一次。然而，SOA不能购买。它也不能建立在一次性的开发项目中。SOA属于开展业务重要的新方式，需要机构持续的学习并且完全接受新的世界观。

　　SOA，还是不呢？如果你还没有准备好，请选择不。大处着眼，但是要从小的地方开始。建立你的服务战略和SOA路线图，整合业务、机构和技术方面，建立企业治理，随之调整企业架构，发展相关的能力。只有这样，在技术上花费必要程度的时间，才能避免技术上的过度以及因为技术的不足而沉没。