我长久以来一直相信理想的软件开发可以净化为一小套基本主体。例如，更好的抽象（对大众更有利），后期捆绑战胜早期捆绑（尽可能推迟决策，而不是不做），高内聚力（所有事务都在一个模块、组件中或者对象应该和单一目标或者主题相关）以及松耦合（过多依赖在维护的时候会导致涟漪效应）。当开始集成的时候，专有借口并不好（锁定，缺少灵活性），开放标准比较好（激励和简化开发和集成）。

　　这样的世界观坚定地出现在我的信念系统中，EAI的目标应该是简化，购买或创建架构良好的企业应用并通过开源标准整合它们，这些开源标准应该从大量的替代物中演变出来，这些替代物已经在企业架构师把我们从意面式代码中拉出来时就存在了。这些都还没有发生，而且我也很后悔没有实践自己的这些说教。

　　在2010年即将结束之际，关于EAI的趋势我思考了很多，我知道自己现在的情况，也就是我把自己押在了相对封闭的平台上（苹果、iPhone……），而且没想到更开发的替代选择。这让我在集成应用（像Salesforce）的时候很痛苦。下面是我过去三十年从事计算行业所得的经验教训：

　　每一个重要的新系统都必须同就系统和数据进行工作，这回要求一些EAI形式。业务将会永远继续购买企业应用，但是新系统的引入很难避免其他类似复杂的系统的移除。不是很著名的企业应用现在足够开放，允许在没有EAI的情况下，与其他厂商的系统进行互操作。这抨击了企业软件的积木。

　　企业应用厂商总是拥抱标准，但很难我那全同意这些标准，绝不限制依附标准接口的功能。从增强功能和专有扩展到第一个ANSI COBOL编译器到ERP和CRM系统，功能的“神秘酱料”总是理想互操作性目标的王牌。结果就是需求EAI的系统。

　　永远要为新的企业系统类预留空间，因此假想你的资产组合已经完成了，不讲需要进一步的集成太天真了。例如，企业能源/碳管理（EECM）软件出现了，在未来五年，它将从一个引人注意的概念变成一个服从和参与竞争的必备软件。EECM系统将需要来自现有系统的数据，像ERP和HR系统，将为你的服从和计划功能提供数据。

　　如果这听起来有点让人失望，就像新的一年即将到来，那么我来提三点积极的原因吧。首先，集成的一些标准的出现、成熟和耐久，主要由于共享利益和业务依赖。例如，SWIFT（Society for Worldwide Interbank Financial Telecommunication），开发了标准和一个“专有交流平台”（从Swift网站）在209个国家内被超过9000家金融服务公司所使用。这种稳定成为可能由底层的SWIFT组织结构作为一个高度协作的成员拥有的合作。由于卷入一场典型的行业环境，在低延迟下多方沟通，这是每个人的最大利益作出贡献，并使用SWIFT的团队的结果。不同于商业厂商，这是真正的最终用户驱动的优化，比其季度结算结果的产品更加稳定。

　　对于SWIFT，和协作的推动有关，我的乐观主义的第二个原因是开源软件社区的相对稳定度带来了这样的解决方案，像Apache ActiveMQ和ServiceMix，还有OpenESB等等。当这么多组织的共同利益聚集产生一个持久的开源项目，它对于和其他开源项目之间的互操作性和简化EAI预示着很好的未来。

　　最后，公共云计算模型的出现为厂商简化EAI需求提供了强有力的推动。正如企业解决方案逐渐地提供按每个服务模型付费，简化的EAI在资源分配能够接近实时改变，而且互操作性将会变成必须拥有的，厂商坚持专有的方式将会根本上失去和更敏捷的竞争者之间的共享。