我刚刚从SAP的年度行业影响力会议上回来。当我参加类似的会议时，我一般会在我的笔记本电脑上记录大量的笔记，以便为我以后查阅以及搞清发表讲话人员所表达的真正含义提供依据。这是一个很有趣的过程。当我记录并分析这些笔记时，我开始明白了一项旨在产生影响力的活动的“炒作”因素。

　　我很喜欢花时间去看同行Michael Krigsman的博客(IT项目失败专栏)，他在博客中提出了一些有趣的见解。我也很爱光顾Joe McKendrick的博客，他为ZDNet写有关SOA的文章。总之，他们二者的关于SOA和SAP的理解是值得我们重视的。

　　现在，回到我的话题上来。我在SAP的年度行业影响力会议上所作的笔记到底告诉我什么?首先是，SAP的领导者们现在正在被三件事情困扰：创新、面向服务架构和成功。

　　以下是我对上述每一个问题的看法：

　　创新

　　关于这次大会开幕时的定调演讲，在我做了七页笔记，其中“创新”这个词出现了25次。虽然我相信这不是一个最高纪录---在过去的6个月里，我出席的每一个厂商会议都侧重于创新---SAP对创新的定义并不奇怪---它是与过程创新结合在一起的。在许多方面，SAP是正确的。通过一种过程方法，你可以获得巨大的潜力使得工作效率实现突破。以下是定调演讲中，我喜欢的一段话。

　　“这是关于不断创新的。你将SAP的不断创新和产业创新与SOA的宏伟蓝图结合。这就可能实现增量突破。这种方法可以通过一个循序渐进的方式来使用以实现突破。你可以引入新的流程并增加更多的灵活性来创造商业突破……”

　　上述一段话表达的一个有趣的意思就是,SAP是在谈论一种增量创新的方法，这种方法是采用一种结构化的服务架构，最终结果是将创造商业突破。没有人可以同这个观点辩论。不过，我一直在等待，但却一直没能得到的是一个能将这种法同用户的经验结合在一起的例子。

　　面向服务架构SOA

　　SAP很喜欢SOA。我曾经与SAP高层领导人员进行过几次交谈。并且我同意SAP的工作做得确实很好，他们打破了传统的代码块，将其按功能分解为模块化的组件。这对于SAP的内部部门来讲，这确实是一个好的方法，因为这意味着当SAP从一个版本迁移到下一个版本时，它本身的开发部门的工作量将会减少很多。使用标准的基于网络服务的接口而不是专有的应用程序接口，可以省不少力气。 SAP在其平台上，强烈坚持行业标准。我的问题是，SOA真的打算成为一个SAP主导的架构，该公司能否有能力领导该领域。

　　在我看来，SOA必须基于一种异构方式来搭建。商业服务必须是松散耦合的---不管它们被用于建造什么平台。 在这个问题上，SAP并不是唯一一个公司---甲骨文，微软， IBM，BEA等，都希望自己的平台成为SOA标准。对于用户来讲，这将是一个危险的举动。

　　成功

　　其实我认为，如果任何一家厂商“赢得”了这个架构游戏，输家则只能是用户。如果我下一年写关于SAP完成了它的目标并且成为了SOA标准的文章，我也会在第一时间宣布SOA已经死亡了。尽管SAP是一个聪明的，有竞争力，技术尖端的公司，但它重点关注的成功应该是基于用户的成功，即用户在一个高度分散性，复杂性和异构的世界里取得的成功。