有没有什么办法能够自顶向下地对企业实施mashup的努力进行协调？

　　这是一个有趣的问题，因为可以对它进行不同方式的解读。通过企业应用mashup成功实现的集成可被划分为不同的三类：鼓励、促进和治理。这三种方案，加上围绕着固化指标进行的成本效益分析，能够为成功的应用mashup管理活动提供基线。

　　鼓励企业mashup的应用

　　我要谈到的第一个方面是管理如何能够鼓励应用mashup的使用。既然mashup建设是个非常有创意的概念，看起来好像它应该是一种自己出现的行为。但是在推进这类活动方面其实公司可以做很多事情。常见的一种实践是定期举办编程挑战赛（Code Jams），鼓励员工放下手头的日常工作（通常只需要几个钟头），然后开发出很酷的解决方案。其唯一的目标就是做出某件令你的同事印象深刻的东西。奖品可以从单纯的“吹嘘资本”到肤浅庸俗的小玩意儿、礼物卡或随便其他什么奖品。

　　像Facebook那样的公司会定期运用这种手法来让自己的员工超脱于IT正常的架构之外。通常而言，这个东西不一定是要基于mashup的，但是你可以把“两到多个或新或旧的系统组合起来”当成你设立的编程大赛的要求。

　　这里还有由谷歌普及开来的著名的“20%时间”方案。该方法的基本前提是，员工受到鼓励可以每周花费一天的时间去做某些与其日常职责无关的事情。这些时间可用于创造某些新的东西，或对某件遭到破坏的东西进行修理。由于大多数公司无法做出如此重大的承诺，设立更短一点的时间来用于创新可再次刺激进行探索，从而可引导新的mashup的诞生。

　　企业mashup的促进

　　为了进一步促进这两个鼓励企业mashup的方案，管理部门可确保开发人员拥有创建mashup所需的资源。这可能意味着确保开发人员可轻易获得对不同内部系统的访问以便提取数据。开设代理服务器以便员工可访问外部网站，那里公布的有用的API是有所帮助的。确保开源及/或授权、商用mashup工具容易获得则更佳。

　　在这一点上，mashup的构建跟其他开发工作并没有什么不同。如果你希望个人或团队完成工作，你不得不确保他们拥有合适的工具和数据以便开始。一旦解决问题或支持系统成为员工日常职责的一部分，那么他们就将能克服获得访问和取得完成工具所需之工具的阵痛。不过大多数人不会将承担这种责任作为试图创造新东西的一部分。如果你希望支持创新，你得让此过程尽可能地平滑。

　　Mashup的治理

　　最后，我想谈谈这一问题中的治理的含义。“编排”就具有这层在潜在的可mashup组件之间进行某种类型的强制协调的含义。在一个很高的层面上去思考这一问题是有原因的。比方说，如果不同的系统所公开的带主键的数据不能相互一致的话，将其内容mashup起来就会变成几乎是不可能的事情。或者更糟——开发人员就会开始做出不正确的假设或推断中间的连接断掉了。

　　是否应该推荐某种类型的数据字典作为创建企业mashup应用的严格的先决条件？对此我有些犹豫不决，因为我以往做此类项目的经历已经证实了这是相当棘手的工作，几乎跟mashup的体验是背道而驰的（或许我还应该补充一点，几乎看不到承诺的果实）。

　　我更愿意看到为聚焦于数据映射问题本身而创建的接口。我自己就曾参与过创建若干此类API的工作，并发现它们很快就变成了许多其他mashup的基础。毫不奇怪的是，当一个公司存在数据映射问题的时候，你几乎就可以确定会存在着多个系统和工作流正在乞求把它们自己mashup到一起来。

　　在开始的时候，我提到过有多种方式来回答这一问题。这与我有关管理的最后一条建议吻合得非常好。mashup将不可避免地为同一问题提供多套解决方案。正如其他任何产品一样，公司需要认识到mashup也存在拥有成本（COA）。

　　在某个时候，mashup树需要进行修剪以便保持健康。在那些解决方案当中，管理人员需要决定要支持哪一个，舍弃哪一个。习惯上围绕着可伸缩性、可靠性、适应性以及成本的比较权衡是着手此事的好地方。将mashup方案视为IT的一流产品则是树立其在开发人员和最终用户心目中的可信度的最后一步。