这篇文章摘自Rick Sherman编写的《Business Intelligence Guidebook: From Data Integration to Analytics》一书。RickSherman是BI和数据管理咨询公司Athena ITSolutions的创始人，Northeastern University工程学院的兼职教员，行业出版物、活动和网络研讨会的常客。

本文中，Sherman深入探讨了BI环境在许多企业中是如何被孤立的方法和应用开发方式所阻碍的。他阐释了采用一个全面的经过精心策划的BI架构策略所能带来的好处，并列出了四个BI框架的架构层。

BI环境和房屋存在着一些共同点。当你打算盖一座房子，你要首先考虑盖房目的：一个住的地方，一个工作的地方，养育孩子的地方，一个可以和相爱的人慢慢变老的地方。了解了这些，你再将建筑风格，大小和房间类型列出一个清单。然后你雇佣一个建筑师设计房屋并规划出一个详细的蓝图。

架构师向你反馈各种房间如何组合在一起更为合适，建筑标准是什么，以及如何布置线路和管道等基础设施。最重要的是，架构师会根据你给出的房子位置、大小、愿望、预算和时间来告知你建造房子的可能性和实际情况。此外，他还能想到一些你没有想到方面。

如果你跳过架构师这一步而直接让建筑工人建造房屋，那将会发生什么？房子可能不满足建筑规范，布局将十分尴尬，风格不具有吸引力。建筑工人为了找到你真正想要的房子类型，可能会花费更长的时间。与此同时，你甚至不知道你想要什么。

就像没有蓝图的房子一样，许多企业BI环境没有享受到体系结构框架的好处。它只是一个由以下部分组成大杂烩：

• 除了企业BI环境，还存在许多特定于应用的报表环境。业务人员将根据他们正试图分析的部分，被迫在这些环境之间切换。
• 各种为BI创建的数据库会存在于应用环境之外，它们在不同时间被不同团队以不同的目的创建。这些数据库可能称为数据仓库（DW）、数据集市、可操作性数据存储、存储库、在线分析处理数据集或一些内部缩略词。
• 一些各异的BI工具，与特定于应用的报表环境或企业BI解决方案相关。企业BI环境支持数个BI工具是很正常的，因为不同的BI工具是在不同时期被指定为企业标准的。一旦一个BI工具成为标准，它可能在很长一段时间中变得根深蒂固，即使企业已经有了新的BI工具来作为最新标准。
• 数据集成工具被企业选做用来加载DW的标准，然而，人们仍然使用大量手动创建的自定义SQL代码或其他提取、转换和加载工具来加载BI工具所需的数据库。

业务人员按照其所负责的业务功能和流程分组，因此企业倾向于建立（或购买）离散的业务应用。最初的情况是，业务人员使用这些应用的数据仓库生成报表，后来企业尝试扩充报表，但他们通常只关注企业一直在使用的应用程序上的BI项目，而并没有检查这些项目应该如何融入到整体架构中。因此，许多BI环境已经成为一个技术、产品和数据仓储松散连接的结构，需要投入密集的资源来进行升级，维护和加固。

业务人员面对其BI环境的情况感到非常沮丧，随着时间的推移，这需要越来越长时间来维护加固，并且离整个企业可用的通用化版本越来越远。他们总是在想那些在时间，资源和BI项目预算上的大笔投资，于是他们会问，为什么现在仍然必须使用电子表格作为报表和分析的中间层。

越来越多的时间花费在协调数据孤岛间的数据和维护系统上，却没有去扩大BI业务的广度和价值，这越发让人感到沮丧。“企业只需使用最新的技术就可以走出这片烂摊子”这样的谣言常被提及，但新技术带来的往往只是另外一个数据孤岛而已。

体系结构框架

一个具备持久商业价值的成功企业BI解决方案不是“一蹴而就”的项目，而是需要随着时间推移慢慢完善。如果处理得当，依据业务人员数量、业务流程的影响、数据使用和分析方式，BI将会扩张。每个新BI项目都需要一个体系结构框架，这样可以让这些项目进行互补，创造一个有凝聚力的，具有成本效益的BI解决方案。设计的框架需要适应不断产生的需求、功能、技术上的变化。虽然框架设计师并不能预知未来，但却能通过设计框架来应对这些挑战。除了为企业增加BI功能，设计师还需要考虑对开发，测试，正在进行的操作，性能监控和文档等方面的支持。如果仅仅关注当前项目蓝图的实现，上述很多地方将缺失或被忽略。

框架的四大组成模块

如图所示

• 信息架构
• 数据架构
• 技术架构
• 产品架构