在今天这个高速运转、动荡变化的商业世界里，为了快速适应新需求、新规则及新机遇，业务系统的敏捷性至关重要。变更需要在数日而非数周或数月内实现，且不应动用一大群IT员工就能做到。而当前的业务系统结构却经常成为敏捷性的壁垒，变更成本代价又太过高昂。

　　业务系统通常是许多独立的应急应用系统，或者是（正在不断增加的）云中的应用的组合。这些应用之间的联系也需要是敏捷的，要能快速适应新需求和机遇。本文讨论了业务系统通常是如何进行组合的，而事件驱动应用可以提高组织的灵活性及智能化程度，以便降低总的变更成本。以下是详解。

　　时间驱动及请求驱动交互是业务应用的两种常见的通讯类型。时间驱动型交互按照一个预定义的时间表管理应用向另一个应用请求服务或信息时的活动，比如说像轮询这样的场景。时间驱动交互的一个例子是每天从物资仓储管理系统下载获得最新的物资目录。

　　在请求驱动型交互里，应用根据需要向另一系统请求服务或信息，通常是以逻辑嵌入的形式体现在应用中，比如推-送场景。请求驱动型交互的例子是当向CRM系统添加一新客户时，CRM会向记账系统提出将客户作为新的应收账款成员的请求。

　　在像每日的物资目录这类交互频率不高或交换信息量很少的情况下，时间驱动型交互可以工作得很好。随着业务要求更多接近于实时的信息，时间驱动的交互频率在不断增长。举个例子，与每日更新的供应商物资目录不同，购买者需要最新的价格和存货数。时间驱动型交互最终将会导致性能及伸缩性的下降，因为系统间的通讯经常会在不需要的时候发生，导致不必要的波动。

　　请求驱动型交互提供了一个更好的场景。应用对另一个系统的服务或信息请求是作为应用的逻辑而体现的。作为交互的形式，这多少要比时间驱动的办法要好一些，因为每一次交互均涉及应用中的一个特定需求。然而，最终的系统并不会像可能的那样灵活有效，而对新需求和机会的适应则需要应用内部进行修改。这一类变更一般都是比较昂贵的，需要花费数周或数月的时间。

　　第三种类型的交互正变得更为普遍—在这些交互中，业务系统指出何时有有意义的业务事件发生，允许任何消费者根据需要对事件进行处理。这些事件驱动型的交互正引领着新型的业务应用及解决方案的开发，使得业务能快速适应变化。事件驱动方案并非什么新鲜事物，但现在，它在降低变更成本至关重要的商业应用领域里正在获得应有的关注。