商业智能（BI）的政治之战

怎样才能无需移动数据到企业的数据仓库就能获得绩效？数据仓库如何支持新老类型的数据并在两者上都能交付绩效？最重要的是，在“移动或不动”的决策上你如何避免犯同样的错误，以至让现有的数据仓库变得更加昂贵而对你新的需要来说并不理想？

    商业智能（BI）的政治之战

    当今的商业智能（BI）用户，沉浸于能带来成本消减和额外销售的伟大的分析洞察力的实例研究，很可能会认为这些“移动或不动”的决策专属于IT，是在首席执行官（CEO）或营销总监（CMO）决定了最新的仪表盘、Facebook数据挖掘或绩效管理工具的使用之后才来决定的事。反过来，商业智能（BI）IT更倾向于认为这些决策是短期和即时的，用来满足即刻迫切的需要。很遗憾，过去的经验表明，这样一种商业智能（BI）的实施态度不仅是不明智的，也是徒劳的。

    有一个旧的故事，讲一个新牧师，他的一些教众请求他改变圣坛的位置。他问一位老牧师传统的位置是什么，老牧师没有回答，只是说在新的位置上试试。结果是在教众中引起了一个巨大的争论。他又问老牧师，老牧师说，把圣坛放回原位置。可是争论没有平息而是更热烈了。他又问老牧师，传统到底是什么？ 我的教众正疯了一样为它争斗。老牧师说，啊，那就是传统。

    同样地，当数据仓库首次推出时，首席执行官们（CEO）暂缓了IT的“移动或不动”的决策，他们想要把所有的数据硬塞进中央数据仓库。业务部门当然反对这种企业的IT应该成为他们的数据看门者的想法，因为这会让他们花上一周的时间等待本地销售数据的报表，而过去只用一天。其结果是，首席执行官们（CEO）经常收到IT或业务部门在这个问题上的争吵 — 它变成了传统。最终，数据集市的出现和基于数据仓库无法应付来自兼并的新数据的事实终止了争论，商业智能（BI）所付出的代价是，低劣的设备要处理来自企业外部的新数据和高管们和业务部门对企业商业智能（BI）的使用不足。

    为了避免这些政治争斗，商业智能（BI）用户需要建立一种长期的 “移动或不动”的方法，应及时在企业和IT两个层面告知实施决策。而不是“我有一把锤子，所有的东西看起来都像是钉子”，这种方法最大程度地强调了灵活性和任何商业智能（BI）的敏捷性 — 它反过来转换成要求商业智能（BI）IT交付的不是最高的绩效，而是合理的绩效和架构适应新数据种类的最大程度的灵活性。

    十年来的商业智能（BI）技术

    要让这种方法有效，使用商业智能（BI）的企业需要知道，使架构灵活于“移动或不动”的决策上，企业可以做什么和不可以做什么。这方面的好消息是软件技术在过去十年里的发展给了IT让他们的架构变得更灵活的能力，如果他们愿意用这些技术的话。

    在最近十年间商业智能（BI）技术的最大的进步不是云、分析、大众的商业智能（BI）、或者“近乎实时”的商业智能（BI），而是最初被称为企业信息整合（EII）而现在被称为数据虚拟化的一种技术。这项技术使得许多截然不同的数据统一的显示在用户、开发者、和管理者面前。为了做到这一点，它也需要数据虚拟化用户开发一种全球元数据目录，不仅的数据副本的目录，还有不同的存储格式。因此，在主数据管理中，数据虚拟化允许以各种各样的方式来表示一个顾客，其中许多来自收购公司的人在顾客的数据上使用自己的方法，都有一个共同的“主记录”。在商业智能（BI）中，数据虚拟化允许来自企业外部的大数据与还未在数据仓库中存储的新类型的操作数据相组合，并用数据仓库的数据执行近乎实时的数据挖掘和分析。

    数据虚拟化的实际效果是，在现实世界中，它交付数据仓库无法实现的“移动或不动”的灵活性。它以两种方式实现这种交付：

    它给商业智能（BI）终端用户第三种选择：不只是复制新数据到数据仓库和等待数据仓库允许你对它的访问，你还可以选择不复制数据并且以较慢的性能访问它。

    它让IT和企业意识到它的数据资产，允许IT提供高层次的商业智能（BI）接口，在需要时可以改变数据位置。并允许企业更好地理解他们不知道的新数据所提供的商业智能（BI）机会。

    目前适用的数据虚拟化产品不仅仅是来自像Composite 软件这样的公司，还来自主数据管理的供应商，比如IBM。而且嵌入在像MicroStrategy公司的商业智能的解决方案中。与此同时，商业智能（BI）购买者应该牢记在心的是，需要一个元数据官员（Metadata Officer）在贮存器中的支持元数据信息并在主数据的管理上实施企业标准化，而且从长远来看是一个好主意。

    商业智能（BI）用户应该知道的第二种技术是还在开发之中，也有点难以描述。跨地域分散数据副本的问题实质是，要么在每一次的一份数据副本被更新，用户看起来好像所有其他副本同时被更新了，否则不同的用户看到的是不一样的结果。例如，假设你的银行收到一笔存款到你的上海的支票帐户，而之后立即在北京提取了这笔款项。如果北京分公司没有及时收到第一次更新的通知，你将面临透支费用并完全有理由对银行不满。

    至少在过去的三十年里，软件业的人们一直设法解决此问题。涵盖所有情况的解决方案是一种被称为“两相”的承诺，但是它需要在北京和上海之间两个来在回的沟通，而在现实生活中它是如此之慢，只能处理当今数据一个很小的百分比。在1990年代晚期，微软和其他人发现了一种方法，可以延迟一些更新却仍然使它在局域网内看起来像所有的数据都是同步的，这种方法支持着今天的全球企业。尤其是，在过去的几年中，支持分布式云数据存储的需要已导致许多案例的识别，在这些用例中，并不需要两相的承诺而被称为“最终一致性”就可以了。结果是，在云中，你更能在不同的地点保持数据的多个副本而无需将商业智能（BI）的性能减慢到难以接受的程度。当然，像云所宣传的那样“你的数据在云中的某处，而你无需知道它的位置”仍然有一段很长的路要走。而在现实世界中我们似乎永远不会有把握地说，数据的位置并不重要。

    因此，使用商业智能（BI）的企业应该期望IT能使用数据虚拟化在云中或企业之外交付更为灵活的商业智能（BI），而且应该要求IT考虑在某个用例中非SQL型的数据副本的灵活性的好处，但不应期待云数据地点的消失。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。