运行中的业务授权

　　这个实例告诉我们企业mashups的意义是什么？以及流程mashups的特性。首先治理在这里发挥了重大的作用。实际上业务授权需要治理。因为IT不会为流程提供强大的工具，除非你可以灵活的管理这些工具的使用情况。

　　其次，业务分析师的企业接口是针对某个特殊用途而设计的，作用有限，只有一小部分人拥有mashups接口，他们可以通过这些接口做出改变。在这个实例中，业务分析师被纳入了呼叫中心小组，而在实际过程中，这个认为可能是IT的，尤其是mashups工具技术性极强时。理论上讲，mashups是为业务为中心的知识工作者而服务的，但是其可用性取决于这些工具。

　　第三，需要注意的是，这个程序是一个流程mashups而不是数据mashups，因为该程序的目标是支持呼叫中心流程。从技术角度来说，业务分析师修改程序所采取的步骤本身就是一个流程，这个流程不是程序的关键，流程和数据mashups的关系才是关键。换句话说，这个SOBA的situationality要比典型的数据mashups小，每次用户和工具发生交互作用时，这个mashups流程都会发生变化。

　　因此，mashups最重要的不是situationality，而是可重用性。毕竟我们没必要多次运行一个流程，所以我们不用最先将流程自动化，否则自动化就不划算了。

　　situationality和可重用性是一个领域的两个极端，从我们的观点来看，这个流程则处于中间位置，这个流程具有一定的可视性需要测量实施这些流程的程序situationality。就是这些流程计算这些流程mashups（总的来说就是SOA）。

　　ZapThink采取的措施

　　同流程mashups相比，支持数据mashups所需的工具和基础设施是不尽相同的。因此，二者明显在技术角度划清了界限。也许，业务人员对二者的区别不是很清楚。毕竟，从业务角度来说，流程通常会涉及信息。如果不能使用mashups，很难从信息中获取价值，当业务运转时，这个活动就可以构成一个业务流程。对于业务用户来说，这个授权的意义远比数据和流程之间的差别要大得多。

　　不管是数据mashups，还是流程mashups，企业mashups在全局中的意义重大，正处于这场完美风暴的风眼，而现在的这场风暴就是业务授权，业务灵活性以及业务流程。 对于机构来说，有这么多技术细节，实在很难保证不亏欠。但是，为了了解IT是如何在SOA启用的企业2.0环境下提交业务值，我们必须要对企业mashups的多样性和功效有所了解。