SOA 业务案例

  • Boris Lublinsky
  • 胡键

2008 年 12 月 15 日

话题:SOA架构

我们之前已经报道过,SOA 成功实施的一个重要因素就是“用具体成本节省数据清楚表达出 SOA 实施业务收益的能力”。这一观点在 Chris Haddad最新的博客中再次得到了强调:

四年前,没人把 SOA 业务案例当回事儿。企业组织为获得“竞争优势”和“机动性”盲目地采购 SOA 解决方案,根本没有清晰地指出度量指标和成功标准……而今天,精打细算的 SOA 预算环境使得是让他们的 SOA 业务案例能吸引投资者目光,并创造和维护 SOA 的势头成为了面向服务架构(SOA)粉丝们的当务之急。

Chris 接着举例说明了他曾遇到的情况,当时他被要求评估一个 SOA 项目,该项目声称“要实现一个业务流程管理套件(BPMS)……并证明了该套件增强了组织的机动性”,但是该项目却无法定义要被实现的机动性。

将 IT 环境持续重构成更具组合性和动态性的构造单元极其重要。最新的技术、工艺和工具能够更加轻而易举地将整块应用程序和系统分 解成更具重用性和高效的资产。然而,鲜见 IT 专业人士对其公司应用和面向服务改进项目(如 SOA、SDLC 和 BPM)能产生的业务收益进行量化和跟踪。不 把投资和收益关联在一起正在阻碍对改革活动的持续跟进。

这一观点得到了Mike Kavis 的回应

IT 人员最常犯的一个错误就是,他们完全从技术角度实施 SOA。他们把大量时间和精力花在了架构、治理和评估厂商上面,这固然不 错,但他们忘了 SOA 需要解决现实的业务问题。他们在构建架构上投入了大量时间和金钱——不料却发现最后没有一个业务人员理解收益,并且没有一个人对这个 技术感兴趣。

他的建议是:

首先从现实的业务问题出发。这正是为什么 BPM(业务流程管理)是 SOA“杀手锏”的原因。通过改进和自动化业务流程,BPM 解 决了部分业务问题。它给运营表现带来了可视化,通过允许业务人员动态变更业务流程而无需 IT 介入提高了机动性,消除了浪费——从而降低了成本——并且像这 样的好处还有很多。一定要首先向业务人员展示 SOA 将如何解决现实业务问题。

按照 Burton Group 应用平台战略和数据管理战略的副总裁Chris Howard的说法:

作为社区的技术领导,要想克服 SOA 疲软,我们需要改变 SOA 的会话方式。我们必须重新把 SOA 放在一个清晰的业务环境中进行讨论,抛弃那种为了 SOA 而 SOA 的想法。

SOA 不仅是一个技术问题,而且(更)是一个业务问题,不从业务出发去理解和表达问题,实施一定会失败。有时因为缺乏控制着资金和开发资源的高管支持,甚至在 SOA 实际启动之前它就已经失败了。

查看英文原文: Business Case for SOA

SOA架构