只是业务而已
SOA 的支持者不断不畏余力地宣传 SOA 的主要技术优势:松散绑定，能够通过组件封装可重用业务功能，最后(但没有像通常那样刻意强调)还能提供更好的集成。
包括我自己也是 SOA 的支持者之一，但我不断在问自己一个问题:客户真的对这种技术推论感兴趣吗?
在过去两年，我一直在与希望获得 SOA 产生的价值主张的客户全面合作。在与客户沟通时，我经常发现客户认为，有很多其他体系结构能提供比我所提到的更多的技术价值。有些客户可能一厢情愿地得出结论，认为非常有经验的架构师和开发团队可以通过使用传统企业应用程序集成 (EAI) 体系结构获得很大价值。很多客户会争辩说，这些方法经过验证，实现风险并没有直接采用 SOA 进行设计的风险大。
这个观点可能会让架构师认识到在有些情况下，SOA 是错误的选择，或者，至少不是最好的选择。SOA 的技术可行性是否是选择其作为解决一系列业务问题的体系结构方法的原因?我会说不是:很多业务及 IT 相关的问题(例如缺乏有力的企业控制模型和策略)将减慢或阻碍任何构思良好的技术 SOA 活动的实现。
在最近一次为期三天的 SOA 研讨会上，一位汽车行业的首席技术官 (CTO) 告诉我下面的话:“我对 SOA 看法是‘只是业务而已’。”他告诉我他采用 SOA 的原因在于:
﹡ 提高他和他的团队实现新产品和流程或更改现有项目的速度
﹡ 降低实现和拥有成本
﹡ 通过外包业务元素或从固定定价改为可变定价(根据业务量)，从而支持灵活的定价模型
﹡ 简化合并和收购所需的集成工作
﹡ 实现更好的 IT 使用率和投资回报
这位特别的 CTO 的话与很多其他人的说法都不一样。他们只关心关键之处:我如何为股东提供回报?
当然，作为一个有经验的架构师(微笑)，我知道一些解决此问题的体系结构备选方案:
1. 扩展其现有的 EAI 基础结构
2. 计划采用更多的事件驱动体系结构(完全分离的、发布/订阅，等等)
3. 或许可采用 SOA
由于这是一个 SOA 研讨会，而客户为此付费，因此我最初准备选择第三个选项。实际上，对于这个情况，我使用了一点 EAI，一点事件驱动和很多 SOA 方面的东西。SOA 允许在必要时包含 EAI 和事件驱动方法。
对于高速发展的汽车行业，为了保持竞争优势和按时在预算内提供产品，企业必须具有灵活性。这个客户的难点集中在对其业务流程进行管理和合并。正如我的同事在此讨论中指出的，将 IT 基础结构与核心业务流程结合，对于达成目标十分关键。SOA 相关的原则已被证明可以简化业务操作，能减少与实际代码关系很小而集中在人机交互和人员活动上的冗余项。在资金有限的业务环境中，几乎没有客户能为解决特定的业务问题无限制地投入资金，而有时间并愿意对其控制流程进行修整的客户则更少了。这样做听起来不错，但却不会实际这样做。
关键在于对现有基础结构、流程和现有控制模型加以利用和扩展。通过恰当地使用现有 SOA 原则，可以对整个设计和实现流程进行管理，如:
1. 标识问题。
2. 标识组成业务并是难点所在的流程。
3. 对这些流程进行建模，以对其进行简化。
4. 标识现有服务，并编写表示这些流程的其他服务。
5. 将这些服务部署到可提供运行时功能且操作效率高的环境中。
6. 监视这些服务和流程，以获得更高的效率。
那么，网络呢?虽然我们不知道其解决方案到底是什么样的，但应当客观地看待每一个问题。请同时根据技术指标和业务指标来确定是否采用 SOA。如果合适，就使用它。如果不合适，就不用它。SOA 概念和原则将始终可以通过某种方式应用到您的体系结构中。
