随着业务日益多样化，应序集成逐渐成为趋势。因此，这个问题对于软件决策制定者而言，不应该是是否需要应用集成，而应该是为什么你认为不需要。业务规模、类型、产品、服务和员工的多样性可能导致一些IT技术新趋势不一定适合某些业务场景。你可能会觉得自己不需要应用集成策略，或者这些并不适合我的公司。

本文探讨多种场景，它们验证了企业非常需要应用程序集成策略。随着企业从人工手动模型到IT模型的转变，信息在员工和提供商以及客户间，从一个应用流转到另外的应用，应用集成越来越重要。

业务实践的敏捷性需求，应用程序软件模块化以及云计算是如今影响到每个企业的三大趋势。这些趋势共同影响着企业，使得应用程序集成日益重要，并且定义了未来的最佳发展路径。这意味着作为企业，不得不去评估这三大趋势可能会如何影响到自己。可以简单针对下文每个趋势的问题集，计算回答为“是”的问题的个数。

企业敏捷性如何？

大家都想要业务敏捷性；谁会说不需要敏捷应对机遇，问题和竞争呢？问题是工作在应用程序间流转时，应对是否能够包含变化呢？回答如下问题：

1. 现在你是否在应用程序间传递工作？

2. 过去两年里，你是否基于业务改变购买或开发了新的应用程序？

3. 你的公司是否面临产品或者服务链的改变，或者竞争的改变？

4. 你的公司是否是高度规范管理的，并且期望快速应对合规变化？

5. 是否预计到会发生业务状态的变化，比如成立公司，合并和兼并，或者地域运营？

组件化是应用集成的驱动因素

应用程序集成策略的第二驱动因素更偏技术领域。我们认为IT应用就是软件包，也就是说它们是自包含的单元。实际上，软件开发实践一直很倾向于模块化或者组件化来降低开发成本和风险。当考虑到用户时，公司也能够使用组件化来复制应用程序组件，从而提高可靠性并且在可变的活动负载下改进性能。

想要在你的公司里检验组件化是否是应用集成的驱动因素，需要回答下列问题：

1. 任何现有软件—内部开发或者购买的—是否能够通过使用多个软件副本来利用或者提供可扩展性或弹性？

2. 是否在现有应用里使用了负载均衡或者应用程序加速？

3. 短期内是否计划开发或购买新的应用程序——它会和现有的应用程序共享信息？

4. 你的公司在内部是否为现有软件进行了大量开发工作？

云计算使得决策更为复杂

应用程序集成的最后一个驱动因素是云计算。因为围绕云计算的各种眼花缭乱的宣传，以及应用部署到云上的各种五花八门的方式，使得这一驱动因素最难评估。

要记住最重要的事情是云计算会让其他驱动因素或者驱动因素组合所创建的应用程序的集成策略更为复杂。也就是说云计算计划会迫使在其他驱动因素的某一个问题上回答了“是”的企业觉得自己被这些驱动因素严重影响了。云计算会使得本来很小的应用程序集成需求变得十分重要。

需要记住的另一件事是，在内部运行的不需要集成的应用程序——在云上却可能需要很多集成。几乎一直需要将用户和云宿主的应用程序间的连接当成集成工作流。因此，不要问是否使用云会涉及到应用程序集成策略——假定会涉及就对了。

需要查看哪些问题呢？见如下列表：

1. 对于引入云计算，是否有现实的可操作的计划？几乎所有公司都认为他们会使用云，但是应用程序集成策略必须关联到实际项目上 — 而不是预测上。

2. 你的云计算服务是否包含如下特性:

a. 弹性IP地址，比如Amazon提供的；

b. 任何形式的负载均衡

c. 弹性云资源工具，比如Availability Zones；

d. 云宿主的Web服务，添加数据流处理，缓存或者工作调度和排队

e. Web前端流程在云上，而后台处理在本地。

3. 是否计划，或者准备计划，使用多个云供应商？

4. 是否真的想要用混合云？

如果如上所有问题的回答都不是“是”，并且你的企业有多于100个员工，那么可能就需要重新思考下这些问题的答案。很少公司，除了非常小的公司，能完全不需要考虑应用集成需求。因此，即使你确定自己对于上述问题的否定回答是正确的，还是建议选择出你最慎重考虑过的驱动因素，假定它就是你的应用程序集成的驱动元素。

如果只在一个驱动因素的问题集里有“是”的回答，那么集成需求必须关注于该特定的驱动因素。该单个因素下有越多的“是”的回答，就越应该关注在产品和该驱动因素特有的实践上。

如果多个驱动因素都有问题的答案是“是”，那么必须意识到你的企业高度依赖于应用程序集成，需要查看覆盖所有集成问题的产品和实践。

应用程序集成策略包括在应用程序和组件之间有序流转的工作。工作流和组件的位置和注册都很重要。这两类问题如何在需求中得到最佳平衡依赖于你如何回答上述问题。如果答案都很明了，你就已经准备好，可以为应用程序集成产品开始提交RFP的流程了。

这是介绍应用程序集成的四篇系列文章的第二部分。下一篇文章会关注于考虑购买应用程序集成软件时需要关注的功能。