EDS资深研究员和《使用SOA、BPM和MBM构建敏捷企业（Building the Agile Enterprise with SOA, BPM and MBM）》一书的作者Fred Cummins，在其最新文章中表示：在我们追求业务-IT对齐的过程中，是时候来一次范型的转换了。他引用说：

Brain Dooley在2008年的名为“业务-IT的对齐（老调重弹）”的Cutter Consrtium文章中 [...]将其看作是流程和通讯的问题[并且]对“对齐”这个术语是否仍然切题提出了质疑。

在“业务/IT对齐‘已死’——下一个是什么？”这篇文章中，Bob Evans提出IT如果不能采取一种新的方式，不可能为业务和客户带来显著的价值，因为“对齐已到尽头”。

Peter Hinssen在“业务/IT的融合：如何超越对齐和转变你企业中的IT”文中[断言]， [...]是时候重新思考IT[并且建议]所需要的是业务与IT的融合——“将IT和业务相融合以专注于技术驱动的创新”。

Tom Lodahl和Kay Redditt在他们的文章“再谈业务/IT的对齐”中，声称这种改变应当是一种扩散过程，IT人需要分散到整个业务组织中，融入他们所支持的企业。

同时他还同意：

是转变模式的时候了，对齐[既没]抓住所需要的改变的实质，[...]流程，融合与散播也做不到。

他这样看：

最根本的问题是业务人员和IT人员站在不同的视角，而企业需要在业务和IT视角之间取得一个平衡。Art Jahnke，在2004年的文章“意见陈述——业务-IT的对齐为何如此之难?”中，认为业务执行官作出IT决策时缺少对IT的认知，而那些技术驱动的组织又缺乏对业务需求的理解 。这种视角的差异不能通过一个原则或是正式的协商来解决，这需要协作。

Fred宣称：

敏捷开发方法是对重新引入灵活性和协作的一种尝试，但敏捷方法并不能伸缩到大型的项目——它们对于小型，多类别的团队比较管用。

所需要的模式改变应当是基于面向服务架构(SOA)的。作为设计业务的一种方法，SOA为业务与IT的新型关系提供了一个基础。这些关系支持在多个定义良好的上下文之间进行协作，所以由业务人员和IT人员组成的小型团队可以一起协作来解决特定的业务需求。

Fred将一个服务定义为：

一个服务单元是一个组织性单元，它管理一个独特的能力（可能是人员，资源，设备，应用和智力资产），并将这些能力以服务的形式加以应用以满足外部客户或企业内其它单元的需求。每个服务需求——范围与接口——的定义，都是把服务定义为一个相对稳定的企业组件，可以预定将其能力应用于多个上下文，典型的就是满足不同业务线的需求。

他认为，随着服务的发展：

IT架构师[可以]带着对“信息技术是如何被用来优化企业设计的”理解，与业务架构师协作来设计业务结构。同时，他们可以评估将新技术应用于各个服务单元的潜在业务价值，并为技术投资的管理决策提供参考。

除此之外，他认为IT同时还负责：

• 管理技术资源以优化整个企业对信息技术的使用。IT将负责优化共享的技术基础设施。
• 就企业及其生态系统来说，支持企业智力决策信息的可访问性。这牵涉到获取，集成以及聚合多个来源的数据并提供及时且一致的企业状态视图，以及相关事件与趋势。

他作出如下总结：

SOA的模式转变支持IT在企业级水平担负起优化技术资源的责任，同时支持在实现和自动化服务单元时本地化的创新与协作。

你的SOA项目支持增强业务与你的IT组织之间的协作吗？你的SOA治理组织如何参与并支持这一协作呢？

查看英文原文：Opinion: It is Time for a New Paradigm Shift in Business-IT Alignment