为什么我们仍在谈论软件集成？
英文原文：Why Are We Still Talking About Software Integration?
周之前，数十位 CFO 齐聚加州 Redwood，他们在此参加一个技术研讨会，会议议题是探讨财务转型的策略。彼时，一位演讲者向听众提问：“你们当中有多少人担心你们的数据质量，并且明白它对于你们的业务意味着什么？”
与会者们纷纷举起了手。
其实也没必要感到惊讶，CFO 们担忧是因为脏数据长期以来给传统财务规划和企业绩效管理(EPM)解决方案所造成的种种问题。他们担心是因为这些解决方案不可避免的必须要与其他软件集成，而当两个不同的应用需要打交道时，便会产生数据的问题。
虽然已经出席了这样一个关于转型的论坛，但这些 CFO 们仍旧感到这些年来与企业绩效管理应用捆绑所带来的巨大压力。脏数据让他们感到恐惧，因为在过去，软件集成是一个艰难的过程，这个过程犹如一门黑暗艺术，需要由一位经过特别训练的先知指导长期而痛苦的集成过程。
在 on-premise 企业绩效管理和分析平台为主流的时代，软件集成的任务通常都是由客户自己完成。不要感到惊讶，因为这些软件实现几乎都是经过了几个月的周密调研而完成的硬编码，这种私有定制不会在其他相似的系统上出现。
客户没有要求 EPM 提供商提供能够轻松集成的环境，因为在这种软件环境下，轻松集成这个目标实在是太不现实了。所以 Oracle 的客户使用 Fusion 中间件，SAP 的客户使用 Netweaver，IBM 的客户使用 Websphere 将他们的应用集成到一起。
这在应用开发之前就已经完成了，服务和数据逐渐向云端迁移。根据 InformationWeek 最近一份针对云计算的调查显示 79% 受访者的业务依赖了多种云服务。为了使得这些云应用能够互相交互，三分之一的用户部署了由云服务提供商提供的连接器，如 SnapLogic，而 41% 的用户通过编写定制化的脚本和利用服务商围绕 API 提供的服务存根自己完成内部和外部应用之间的连接。
我觉得这真是令人感到沮丧。云计算的非凡之处在于提供了一个越过 on-premise 平台地域限制的机会。它不应该让云服务的用户自己去思考如何集成他们的云服务解决方案。然而，现实是云服务的用户仍旧被集成的事情所困扰。这就如同让新买 了电视机的用户自己准备焊接工具去完成电视与机顶盒或录像机之间的连接，从而使电视正常工作一样可笑。
当然，数据在不同的应用之间的交互必须经过转换。而且事实是目前在云应用集成领域没有相关的数据识别标准。但云服务解决方案提供者能够为用户提供一种简单地，甚至是透明的集成方式。正因如此，事实上软件集成不应该是当今企业仍然需要考虑的问题。
换句话说，软件集成也许曾经在 on-premise 时代是令用户头疼不已的问题。但到了如今的云时代，应该由云服务提供商去解决这个问题。
统一化，而不是集成
不像其他遗留系统，云应用使得软件的统一而不是集成成为可能。统一化需要设计一个全新的方法，需要重新考虑不同软件应用之间数据流的问题。并且这个过程需要对用户隐藏实现细节，创造一个统一的，遵从人们工作需求的过程而不是阻碍产品体验的额外的过程或步骤。
那么 CFO 们应该寻找什么样的基于云的 EPM 解决方案呢？又如何构建易于统一的而不是集成的云应用？我想到了三个对于 EPM 平台向云服务演变至关重要的属性，并且我相信它们对于所有云应用的发展都将是具有指导性的。
1. 不需要数据映射
十几年来，数据和软件的集成都被定义成类似的ETL(抽取Extract，变换Transform，加载Load)步骤。但是 ETL 天生就是受限的，因为变换（映射）的步骤需要使用一系列强制定义的规则或方法以确保数据在目标应用中仍然有效。
这种数据映射过程需要耗费几个月的时间，并且一旦完成就不能改变。所以除非你能够精确预测到未来你对数据所有可能的使用方式，或确保你的云应用 不会变化或更新，再或者你的业务需求将在数年之内都不会发生变化，否则你就不可避免的需要在未来重建数据的映射。好吧，你懂的…
数据映射不是一个能够随着业务变化而变化的过程。一个可选的方案是将数据或文件抽取出来放到一个基于云存储的安全平台上，例如 BOX。当应用的执行需要这些数据时，你能够按照需求变换这些数据。而ELT(抽取Extract，加载Load，变换Transform)过程提供的是一种更流畅也更灵活的方案，让你加载所需要的所有数据，并且按需进行变换，这样就不需要数据映射了。
2. 为协作而生
根据一份麦肯锡的全球调查显示 IDC 的工作人员花费 18% 的工作时间用于内部沟通和协作(如果算上通过邮件进行的沟通，这个数字将跃升至 46%)。所以任何一个新的 EPM 解决方案必须从设计伊始就考虑协作的问题。
这与简单地在云中发布一个电子表格数据使得相关人员能够查看这样一个任务不同。这里提到的协作指的是通过内建机制共享非结构化的数据进行实时的协同工作，使得相关参与方能够对同一份文档同时进行更新、修正以及改进。这种协作能够加快而不是阻碍业务流程。
3. 工业级之强，却非工业级之重
云服务的长处和灵活性并不能为 EPM 提供商免除支持复杂事务的需求。EPM 应用仍旧需要经受最严苛的、破坏性的、不断增长的大量数据的挑战。它们仍然需要对遗留的 EPM 系统保持不可妥协的可靠性及完整性。幸运的是，当你从经典的软件集成向基于云服务的一致化方向迁移的同时，能够保留可靠性并且获取效率上的收益，这在 on-premise 策略中是不可能实现的。
基于假设的 EPM 实现方案的设计必须包含高级别的冗余性以保证在诸如电源故障或其他严重问题发生时良好的可用性，所以客户必须要承担这种冗余性所带来的额外建设和维护成 本。而正相反，基于云服务的 EPM 应用天生就是被设计于正确响应可预见的或不可预见的云节点故障。所以即使是一个数据中心遭到毁灭性的打击也不会使你的 EPM 应用宕机。
当 EPM 提供商提供的云服务不需要强制用户去关注软件集成问题的时候，CFO 们能够更专心于他们需要真正关心的问题。不久之后，数据质量的问题将不会再令他们烦恼。这才是我所期盼的。
原文链接： readwrite.com 翻译： 伯乐在线 - 熊崽 Kevin