应用集成从1980年代中期就已经成为企业软件的痛点，也是那个时候我第一次开始做IT报道。同样的老问题让不同的软件共存，大部分是因为业主权益要比开放标准高。此外，应用集成也始终是购买者被最新的应用吸引之后产生的想法，集成的痛点经常被遗忘。
在云计算时代这两个因素也没有改变，因此我怀疑新的基于云的集成服务也会如此。因为企业软件实践中一些云服务首要集成策略和彻底改变，我也对此充满希望。
早在1980年代，企业内部部门应用通常彼此不兼容。集成客户和合作伙伴软件呢?忘了吧。在这个巴别塔场景中，大多数企业在不同的操作系统、数据库、开发语言上构建一种混合应用。
下一步发生了什么?理想中，软件和硬件制造商就标准、接口和其他的让所有事物更好地彼此协作的基础上进行协作。互操作性和集成问题逐渐消失，刺激创新和创新者赚钱模式的创作出现。相反专属打包软件创造出来，短期的东西为那些从一个厂商那购买一切的购买者安置好。
“密月阶段”将组合价格提升，并导致套件过剩。开源操作系统(尤其是Linux)的出现，以及厂商导致的应用锁定尤其让人感到任务繁重，随着创新者创建了比一些软件应用组件更好的点产品。一些企业想要完全的开源或者混合开源和专属软件，但是都面临着集成的问题。
他们还是做了。在最近的调查中，应用集成是软件架构师、工程以及C级别执行人员首要的云问题。在最新的2013 TechTarget Cloud Pulse Survey中，很多受访者表示他们忽视了自定制和集成问题，直到问题出现。还有64%的受访者表示在云和本地系统之间连接数据、应用和流程是立即要解决或者近期要解决的问题。
同样的，受访者将集成和自定制列为软件即服务(SaaS)应用(每个14%)的首要问题。在Cloud Pulse调查中，SaaS应用成为34%的受访者的集成挑战，其项目不能同其他云端或者内部的项目交互。再一次，自定制同集成紧密相连：即时有自定制，34%Cloud Pulse受访者仍旧表示SaaS应用不适用于其客户端业务需求。
根据Cloud Pulse调查受访者，Ovum高级分析师Saurabh Sharma和CIMI云咨询师Tom Nolle所述，增加了云应用到企业应用组合中，解决了棘手的问题。他们再一次告诉我，奇怪的应用混合拼凑在一起，遗留系统、移动、云等等，但是在这个案例中，它们处在动态资源分配环境中，每一个的复杂性导致集成更加困难。事物转移到云端，转移的应用和数据的集成就更难实现，Nolle说道。
专属保护主义，也是我上面提到的集成障碍，确是大多数SaaS厂商支持的，Sharma表示，产业不可能为云计算表转化每一种架构，让事情变得更容易。此外，Web服务应用程序接口(API)并没有承诺为SaaS和本地应用之间清晰的集成交付银弹。那是因为本地应用在不同的标准下开发，通常需要更加自定制的代码开发，来和SaaS环境交互。
即使人性的贪婪锁定了标准，但是对于云端和本地之间的应用集成还是有希望的。平台即服务(PaaS)会协助开发者构建与云兼容的应用。Cloud Pulse受访者在被问到是什么因素导致他们选择了其PaaS提供商时：
49%表示提供商是已经计划的云生态系统的一部分;
36%表示提供商支持应用开发语言;
35%指出提供商和现有架构集成;
31%指出提供商比其他提供商有更好的性能或者功能;
25%报告开发者已经拥有这个PaaS平台的相关经验。
PaaS平台主要用于开发和部署云应用，63%的受访者说道。PaaS也在SAP这样的应用中起到扩展SaaS产品的作用(43%)，开发和部署移动应用(40%)和提供应用测试环境(36%)。
面向服务架构(SOA)以很多方式提供了强有力的集成基础，包括通过暴露依附开源标准的服务降低集成成本。在Web服务范式上构建，SOA应用可以轻松迁移到云端，并同其他的基于Web服务的项目集成，他们很好的咬合了云的应用到资源的关系模型。
转移到DevOps团队需要开发者考虑部署战略和IT来提供互操作性以及为开发者整合上下文环境。
新的基于云的工具和服务提供了一些安慰，这些包括现在的应用集成工具和服务，比如Dell Boomi、Informatica云集成平台、CloudSwitch集成服务、IBM Cast Iron、MuleSoft等。新工具和服务也在不断发展。比如Tasktop关于软件生命周期集成服务的介绍，承诺将集成策略固定在企业的业务计划中，是预先的，而不是事后才做。
更多应集成期望
我不久前曾看到对于“集成架构师”职位的招聘广告。如果这要转移到拥有一个内部集成专家，我完全同意。集成可不是“马后炮”，尤其如果这是DevOps团队成员的核心关注点。
开放标准会是应用集成和互操作性的圣杯。直到厂商找出开放标准组成的赚钱模型，然而，放入一些新的集成工具、服务以及内部专家来工作更容易。
