SOA 采用反模式

    这些是阻碍或延迟客户和业务的 SOA 采用进程的反模式。

    A1:反模式名称:技术带宽(另请参阅:Web 服务 = SOA)

    问题：我们发现，很多公司从 IT 的角度开始着手 SOA 工作，而不是从业务角度看待问题。实现可能从技术角度而言是可行的，有时候也能成功，但由于首先没有考虑业务，因此其对业务的影响可能无法实现。

    环境：此反模式主要出现在建立了良好的 IT 部门的大型企业中，此部门主要雇佣的是技术人员，决策方面受到技术层面的影响更多。

    症状：此反模式的常见症状表现为发起人不能清楚地阐释采用 SOA 的价值主张。此外，另一个症状可能表现为缺乏针对 SOA 实现的业务/项目一致性。

    结果：由于此反模式，IT 成本将会上升，却没有实现任何投资回报 (ROI)。此外，公司可能会失去为 IT 投资组合注入灵活性的机会。

    根本原因：在大多数情况下，此反模式的根本原因在于，为了赶上通过采用此技术可能实现领先地位的竞争者所宣称的能力，公司因此而承受压力。由于这个原因，公司可能发现开展基于技术的工作来引入 SOA 更为容易，而不会花时间和精力将其与业务需求结合。

    解决方案：处理此反模式的非常好的方法是建立没有浮夸的 SOA 价值主张，可以通过标识和描述特定于客户的难点或业务挑战来实现这一点。此方法可以通过开发用于在业务的支持下恰当地引入技术的路线图来进行互补。

    解决方案示例:根据没有浮夸的 SOA 价值主张开发 SOA 平台

    一家全球汽车租赁公司了解可支持其关键业务动力的 SOA 解决方案的价值主张:

    1.可提供一个灵活的业务模型，以提高交付新业务服务的速度和灵活性

    2.通过简化流程来降低操作成本，从而使成本下降

    3.通过为其客户提供率先推向市场的创新服务来缩短外部业务流程的周期和成本

    4.通过允许方便灵活的集成来支持多个交付渠道，从而在整个企业范围内进行集成

    A2:反模式名称:老调重谈

    问题：此反模式描述的情况是这样的:公司置疑 SOA 不过是相同的旧技术的一个名称而已，SOA 并不能提供任何它们尚未提供的新功能。从表面上来看，似乎可能是这样，但过去已经提供的功能和通过恰当实现 SOA 可以提供的功能相比，Web 服务和 XML(以及其他相关的标准)的出现则是一个重大的区别。

    环境：这个反模式主要出现在那些习惯其已经长期使用的技术，而不愿意引入或考虑进行改变的 IT 专业人员身上。当 IT 部门经历了大费周折的技术转换后，或新技术并不能实现最初的承诺时，也可能出现此反模式。

    症状：最明显的症状就是公司中的一些技术管理人员强烈反对将 SOA 作为处理合法业务问题的正式方法。反对可表现为强烈而明显的争辩，反对采用 SOA;或者可以表现为隐含的被动的方式，在讨论业务问题的解决方案时完全忽略 SOA。

    结果：此反模式很可能会导致缺乏 SOA 支持，而最终会导致失去实现将支持业务难点的 SOA 价值主张的机会。

    根本原因：尽管 SOA 构建于其他计算范例(例如，面向对象和基于组件的开发)所引入和支持的相同原则之上，很多有经验的 IT 团队仍然不能真正理解 SOA 与这些其他计算范例之间的区别。缺乏理解是此反模式的一个基本根源。另一个根本原因则是 IT 团队在实现太多的“范例转换”方面的经验不丰富(而不愿尝试新的技术)的直接结果。

    解决方案：处理此反模式的一个方法就是强调 SOA 与早期解决方案的不同之处。例如，应对 API 和服务之间的区别加以讨论，应对开发标准依赖性及其区别属性进行说明。另一个主要不同点在于作为 SOA 主要组件的企业服务总线 (ESB) 的出现。ESV 提供的工具(如传输服务、中介服务和事件服务)就是一些通过采用 SOA 所提供的新服务的例子。不过，最有效的解决方案则是提供一些成功的示例，以突出区别和演示实现 SOA 解决方案的成功案例和可行性。