问：人们把聚合看做更快的交付开发时间。这在20世纪90年代中所讨论的RAD（快速应用开发 ）有怎样的相同或不同之处呢?

　　答：我想先感谢RAD定义的具体时间表的提供者。如果你查看维基百科，你会发现从方法论来讨论RAD。90年代初的那些开发人员认为RAD是完全不同的，即一场围绕工具的变革。

　　TT SOA编辑推荐：企业Mashup应用指南

　　从Visual Basic（用户交互领袖阿兰•库珀创建）开始，以及后来的工具，如PowerBuilder和Borland公司的Delphi，开发人员可以通过拖拽可重用的组件到“组装帆布”建立一个应用程序，也可以写简单的角本来连接他们。这是革命性的。你不能写代码来建立用户界面； 你直接操纵它的组件。讨论了几十年的重用之后，VB的“VBX”窗口成为最早的真正广泛的成功故事之一。

　　随着这些工具的出现的同时，C/S架构的概念得到了动力。你在用户机器上的所有的逻辑，大部分的业务流程和数据都存在于一个中央数据库中（通常为SQL）。

　　这就是90年代的RAD，应用程序开发的技术水平突然大大的降低， 同时，架构和基础设备已大大简化。 这使得工作更容易分开：一个团队做业务分析，另一个写用户界面的代码，另一个设计数据库和编写存储过程。 整个工作的分工需要团队迅速交付自己的作业，因为他们在进度表上是相互依存的。 但是项目仍然在以瀑布模型似的修改下运行。

　　接下来发生的事就是把我们带到了SOA时代，最终到了企业聚合。由于Web势头越来越强劲，业务已经从沉重的桌面应用程序开发转移资金，系统必须比C/S架构更具有伸缩性和有效性。 团队必须作用于“信息时代”。 像Java这种更加灵活和有能力的语言成为主流，取代旧的工具。 当“多层次”流行的时候，“C/S”变成了一个肮脏的词汇。 可重用UI组件这一概念让位给可重用服务，它应该制造出更强大的可重用机制。

　　但是当我们做了这样的改变，我们就失去了RAD中的“R”，架构变得更为复杂的行业产品，像J2EE服务器和ESB（企业服务总线）等。虽然IT部门创建了可升级的目录， 可重用的服务，但是谁是他们的客户呢？在naval-gazing技术中，它经常被同一个团队或者部门的人先来开发。 当然，这仍然能被重用，但是常常在一个可区分的等级内。

　　这是他们在企业聚合扮演的角色。在90年代的RAD和SOA之间 ，聚合担当一个桥的技术。聚合最根本的就是重用机制，因为最终的产品本身仍然可重组到新的聚合里， 围绕聚合的工具会使你想起你所喜欢的几十年前的生产力，但有一个新的转折：UI的进展（和在一般的技术中增加最终用户的触觉）意味着在很多情况下非开发者可以建立他们自己的解决方案。这些新的受众为企业服务建立了一个崭新的市场。

　　他们将在快速应用集合中得到益处，但是这要有一个强大的架构在后台去备份它。

　　90年代的RAD是由IT门对门的去为业务建立解决方案。 之后，到了SOA时代， IT建立了内部服务，然后配置他们来满足特定的用例。 这就像我们是一个 木匠，如果有人想要一个书柜，我们就得进入他们的房间，问他们想要什么，然后为他们制造它。 今天，我们就更像Home Depot，企业服务是木材、钉子、油漆，而聚合产品就是把他们聚合到一起的工具。 我们仍然有总承包企业（我们存在的IT职员）， 但是我们还有大量业务用户用非技术的形式自己做自己事情的人。 自助服务科技有望得到爆炸式的增长。