第一节：模块

     BI系统（或者说数据仓库系统）也同样需要架构，它作为一种软件系统，是符合一般架构原则的。首先，我们来看看架构设计中包括那些内容。 架构的重点是描述系统的结构，以及它们之间的关联、交互接口。

     BI系统可以划分成业务模型、元数据、数据质量、接口平台、报表集市、指标库等若干模块。可以看出，在这里，这些模块的命名都是静态的名词，而不是动词 （例如业务建模、数据质量管理等）。之所以如此，是因为这是在描述系统的结构而非功能。具体来讲，业务模型是存放业务数据的结构，可以再往下细分，并有不 同的分层方法。例如可以分成ODS、EDW、DM等层，也有的会根据业务复杂度或数据量考虑，舍弃ODS层。业务模型是支撑业务分析需求的，例如报表、仪 表盘、OLAP、专题应用等。

     元数据为整个系统数据的形态和数据流动的过程起到支撑作用，也就是说，数据从源头开始，到最终用户眼前，其来龙去脉，每个环节的状态都需要掌握。还有人将 它比喻成模块之间的粘合剂，但我更愿意将它称作是“数据”之间的粘合剂，因为模块之间自有它们的交互接口规格来粘合。数据质量模块为衡量数据源质量、 ETL过程处理质量提供支撑。

     接口平台是处于源系统和数据仓库系统之间的玩意儿，作用在于可以更方便地明确界定双方职责。当然，通常有很多系统似乎并不大愿意将职责搞得过于明确了倒宁 愿糊涂一些。糊涂一些的好处在于一开始省了好多事，但在以后扯皮的事情就少不了了。此外，报表集市为报表应用提供支持，指标库为绩效管理需求提供支持。其 实，这两者还可以归入业务模型一类，因为它们都是服务于分析需求的。

第二节：需求

     之所以分成若干模块，是为了让架构清晰，降低这些模块之间的耦合，这符合“分离变化”的原则。那么，这一结构到底是否合理呢？还得看这个架构面临的需求到 底是什么。做好这一步，就需要把系统的用户分为两大类角色：一是系统运营角色，他们对系统的正常运行、维护负责； 二是业务分析角色，他们需要从这个系统得到数据分析的功能。

     显然，第二种角色的分析数据来源都将来自业务模型模块，而第一种角色将从剩余模块中满足自己的需要，而不直接和业务模型这个模块打交道。在架构设计中，重 点应该放在如何满足系统管理用户的需求上面。当然，只是"重点"，而非舍弃业务分析角色，毕竟在业务模型模块中，还需要根据业务、数据量、分析应用等方面 的特点，来进一步细化。

     就个人经验认为，架构设计应该是与具体业务关系不大的，这种架构应该是半通用的。之所以是半通用，是因为在系统功能上面，BI项目大同小异，而在业务需求 上面，架构只需要对客户的业务、分析需求分成几个大类，例如按行业为业务模型分类，按OLAP、报表来为分析应用分类，不需要太过细致。

     下面，让我们来看看系统运营角色的需求。

     首先，我们可以把这类角色再细分成两类： 一是开发设计及实施者。之所以将开发者作为系统的用户，是因为数据仓库项目应该看作一个过程，而不是产品，因此在开发阶段，其实其架构最重要的用户就是开 发者，当然要为之提供便利。 二是系统管理员。系统交付之后，如何监控系统运行、发现数据质量问题、应付新的分析需求等，当然都是系统管理员的分内之事。

     那么，对于开发实施人员，他需要进行系统部署、ETL的开发调试、质量的稽核；对于设计人员，则需要进行模型的变更、系统调优、系统一致性分析等；而系统管理员则需要监控ETL过程、监控系统运行、响应系统警报、接口数据管理等。这些都可以看作是用例。
这些用例就是架构设计的"需求"，如何满足他们，并且保持良好的体系和清晰的结构，能够易于维护且能够满足日后肯定会增加的业务需求等等，这些都是架构师们仔细斟酌的事情。

      最后，看一下分析人员的需求。举个例子来讲，某销售总监说：“我需要了解近半年来东区和西区的销售量、收入、成本对比”，这可以算是一个用例。对这个需 求，架构师该如何做呢？正确做法是，在架构中不能考虑东区、西区这些业务概念，那样就太过于细致，而是应当将这种需求抽象成一种分析应用，例如 “即席查询”。如此，架构师所着重考虑的事情就是如何满足这一类需求，而非这一个需求。

架构设计四项原则：
1、架构设计主要面向系统用户为主；
2、架构设计的内容主要包括：系统功能需求、分析需求分类；支持这两者的后台结构，对结构进行粗略划分，以让其内部能够保持简单的交互方式；
3、架构设计中不要包含过于细致的业务术语（除非为了说明方便），要尽可能保持架构的复用；
4、如果架构设计确实包含不能被其他项目复用的地方，将这部分独立出去。