你在 SOA 实现中应用筒仓分析了吗？

MomentumSI 的 CEO Jeff Schneider试图定义出 IT 筒仓和面向服务体系结构（SOA）之间的关系。

我认为一个筒仓（silo）是一个系统，或者说是信息仓库，它解决了企业的一部分问题，同时却将相同或者相似的问题留给其它的领域自己解决。筒仓造成了系统、业务逻辑和数据的重复。

Jeff 当然不是第一个探讨这种关系的人。 Dave Frankel，SAP 实验室的标准体系架构领导者，将 SOA定义为：

SOA 的核心思想是 IT 资产重组为松耦合组件。那些组成 SOA 核心部分的工具构建的组合应用以唯一的方式编排多个组件，由此拓展并最终打破那些妨碍集成、呆板的 IT 筒仓。这些筒仓需要多级集成和清理，导致越来越多的维护和操作费用。一般来说，筒仓很有害。

最近，Joe McKendrick 发布了一个报告，这个报告详细说明了农业信用加拿大（Farm Credit Canada，FCC）——一家加拿大农业金融服务提供商——采用 SOA 方法将自己从一个筒仓组织（其中，为每个特定业务功能部署了一个应用）重新组织为一个“以服务为中心”模型的过程，其中的应用程序按照面向服务体系结构（SOA）原则来构建。他在报告中指出，这个转换经历了一个六阶段。

1）CEO 驱动：“CEO 发起一场文化革新运动，将其作为创建一个‘以客户为中心’组织的思想基础。” 2）过程革新：“组织关注需要完成那些事情才能把组织过程和系统集成起来，进而能够提供一流客户体验。”

3）转变 IT 自身：“CIO 评估 IT 组织的当前状况，所有当前 IT 项目在此期间都要暂停。”为了支持由 SOA 原则支持的“以架构为中心”方式，所有的筒仓方式都被抛弃。

4）“通过实现一个精心挑选的 SOA 业务流程”，完成概念验证。

5）治理：“组织负责重新对其它过程进行详细设计，并承担那些与管理“过程驱动”IT 组织相关的治理问题。”

6）迄今为止转变 IT 功能及其关联技术的收益。CIO 识别各种收益，从业务和 IT 之间沟通的改善，到可重用的 IT 资产的开发。

Jeff 注意到，一般情况下：

几乎所有的巨型组织都有很多筒仓，成因多种多样： - IT 的资金产生于每个业务领域，每个领域购买 / 构建它们自己的系统

• 企业合并或者并购导致了重副（筒仓）系统
• 整个企业的短视或者规划导致了无意识的筒仓

……[然而] 这些公司 [的确] 没有执行“筒仓分析”。

他的文章提供了执行这个分析的实际步骤：

• 我们的筒仓是什么？
• 这些筒仓有一个合理的存在的理由吗？
• 我们希望哪个筒仓结束掉？
• 我们可以实际消除掉哪个筒仓？（政治，投资等等）
• SOA 会导致“筒仓服务”吗？

这个列表中最关键的一个问题是最后一个：SOA 会导致“筒仓服务”吗？Jenny Ang 和她的同事已经认定这会是一个潜在的 SOA 反模式。

Eric Roch 也在今年早些时候问过这个问题：

你如何确保 SOA 不会围绕业务单元创建一组新的筒仓？

Eric 建议

• 建立一个战略服务蓝图（未来的业务服务目录）
• 组建一个多功能的 SOA 指导委员会，由 SOA 发起人、每个应用系统的首席架构师以及一个企业架构师组成

Joe McKendrick 认为从两个关联层面应对这个问题：

• 首先，从技术角度，是联邦。超过 1/4 的公司已经转移到一个联邦的体系架构来支持多个 ESB 或者中介实例。试图通过单个 ESB 管理一个成长中的 SOA 是不可持续的。
• 然后，从业务角度，是治理。有效的治理将会理清混乱不堪的服务。

Jeff 总结说：

筒仓分析应该成为每一个业务分析者、架构师、开发者和治理专家的根深蒂固的观念。对我们下一代的教育失败会导致更多的筒仓——仅仅使用 Ruby 而不是 Java 来开发它们……

Jeff 列举出了很多每个 SOA 治理组织在某个时候都应该询问的重要问题。你在 SOA 实现中考虑到筒仓问题了吗？你通过你实现的新服务成功避免新的筒仓了吗？你的 BPM 和 MDM 战略如何与筒仓相交的？

查看英文原文： Did you Perform a Silo Analysis as part of your SOA Implementation?