今早起来，看到一篇不错的报告，是Michael Bloch和Andres Hoyos-Gomez 编著的，他们是麦肯锡巴黎分公司董事。以前，我其实很早的时候就开始关注技术的价值问题，当然，发表过一些文章，这个也是商业本身应该关注，任何技术，如果不能创造价值，那么一切都是空谈。如何分析出价值，如何创造价值，我认为，作为具备管理精髓的“信息”而言，应该是比较容易的切入点和创造点。记得，有次和Solofeng谈起关于BI的见解，他表明态度，他是已经开始关注BI价值了，我呢，现状是在关注深入的实现技术，后来他没有说话了，我想大概他认为关注价值的人已经比关注技术的到达了一个更高层次了吧 ；） 不过，我是从商业价值出身的，现在觉得，没有一个创新的技术，或则稳固、优良的技术团队，很多事情，其实做起来很痛苦，更不用说创新、创造了。技术的创新与实践，永远是信息科学的引擎动力。不过，对于很多技术出生的人来说，开始关注信息价值，那还是一件看起来非常兴奋的事情，毕竟，不用日复一日的面对机器“说话”了 ；）

 

以下是原文，以供鉴赏：

 

通过IT创造业务价值颇具挑战性。能够成功做到这一点的首席信息官（CIO）可扩展其行动范围，超越技术领域及传统IT部门的用武之地。

如果说有哪个问题经常让许多组织中的高管头疼，那就是如何确定信息技术为其服务的业务增加的真正价值。对于创造价值，IT无疑发挥着核心作用，因此，在总投资中所占的份额也在不断增加。但是，要界定、衡量以及最大化这一价值却仍然令人无从下手。为了揭示这一关键问题，麦肯锡与CIGREF¹协作研究了在不同行业中法国以及国际大企业的最佳实践²。

2007年3月至11月间，我们采访了法国企业中的11名首席信息官（CIO）。这些深入的访谈提供了宝贵的真知灼见，使得我们可以直接受益于首席信息官们的经验――他们当中许多人所在的企业就成功运用IT获得了竞争优势。分析他们在信息技术方面的做法可以展示IT能够如何提高经济业绩。我们以国际案例对这些真知灼见进行了补充。

That is good classify content about decision making, just share first：

 

1.  Based on balanced mix of financial, strategic targets

2.  Based on long-and short-term considerations

3.  Assessment of our company's execution capabilities was realistic

4.  Thorough, objective review of business case even though some senior executives were strongly in favor of decision

5.  Evaluation approach was tailored for this specific decision

6.  Truly innovative ideas were allowed to reach senior management

7.  Based on a robust fact base

8.  Dissenting voices were given ample opportunity to express themselves

9.  Stakeholders shared all critical information

10. Market demand was forecasted accurately

11. Individuals' incrntives were aligned with strategic objectives defined by this decision

12. Our competitiors' reactions were accurately anticipated, factored into our plans

13. Actively sought evidence contrary to initial plan and factored it in

 

I will renew this blog about this subject soon after. 

 

Saturday, January 24, 2009  今天是大年三十的前一天，我照常来到耸立在云雾中的Yintai Centre的办公室，很明显，今天办公室里静的厉害，空空无人，市场部那些五光十色的同仁们早已回家了，为什么会跟市场部的呆在一起？因为，我们的工作相当于就是公司全球市场部的大脑，提供全球的市场智能支持。在这样一个安静祥和的早晨，不用理会落窗外呼啸的风，在办公室里独享着一杯STARBUCKS加奶，是一种平和的安详，明天下午4点的飞机，又是一个新的一年了。

 

记得思科CEO John Chambers把1750万美元的“礼包”赠给马云的时候，马云表示一定要向思科学习，因为他到现在都还在迷惑思科是怎么赚钱的。其实之前，我也同样迷惑，卖路由器？卖电话？能卖成世界上最大市值的科技公司？显然是不可能的。记得以前，看到思科在推“思科网助学堂”（和Youtube有什么区别？）后来又推出了“思科网真”产品，不过，今天，来到思科内网的C-Vision，看到“Dec Comp Mtg, Integrated Workforce Experience demo”中 John Chambers 和 Jim Grubb做的一个新展示，It's Mamazing!! and very cool!! 联系到我手上正在做的事情，一下子豁然开朗，呵呵，我不得不承认：嗨！！伙计们，我看好思科！思科和华为的竞争显然已经不是一个级别上的了，当然，更重要的是，我看到了我手上做的事情的价值和机会。

 

也难怪，在思科内网的首页，标注着新任Obama的潜在支持，美国政府应该会在新网络上增强更多的投资，大概总额在$ 6 billion funds。“ The Obama administration recognizes that IT infrastructure is as critical as traditional infrastructure like roads and bridges. ” 那天又看到一个国外的投资机构Montrose Advisors的总裁John Train把思科列为2009年最有潜力的投资公司，当时我还百思不得其解，蛮像一个蝴蝶效应的，还记得John Chambers在北大那次演讲的最后一句话：，“未来我们的竞争对手将不是北电、阿尔卡特这样的通信公司，而是Google。”

 

新网络，人为本。

 

                                                                                                                              ———— 孙子

 

近来比较忙一点，抽空整理、整理思路，面对一大堆新系统：M-ODS，CI，CM/CME，MACT... ...哎，数也，数也。昨天，在北京的Sofitel Wanda Hotel参加了2009 Cisco Le Party，终于见识了以前冥冥当中觉得猛的CCIE爷们儿的山寨乐子，能用上的雷劲儿，都用上了，最后的黄健翔的思科版，尤为霸道。团队不错，很温馨，很像一个大家庭。地震，金融风暴，股市楼市，如果要问我在这个乱世里的Plan的话，好好工作，好好生活，多学学，多看看，多思考思考，站在办公室的窗边往外眺望，看着远处的CBD以及更远处的中央电视台的新办公楼，心情终于平静下来了，就像那天在报纸上提到最多的一个词——蛰伏。

 

BI的工作，很多时候，还是缺少创意的Problem Shooting，思考，作为BI工作的上层本质，但是Modeling就那几个，其余的还是要回归到数据的问题，方法论，抽象，EAT，决策支持，不是完全一个系统的事，本来的决策天生就依附于两点：理性和感性。所幸我是一个市场出生，自认有很不错的Marketing Perception，昨天和Marketing Dep.的Jacob聊到了关于市场和销售的区别，特别是在理性管理这块，拿到了一些新的市场流程，很受启发，不过要完全的依照系统来完全管理，甚至来智能化，我感觉还是需要一个长久的过程。这就像我昨天又打开了下TTNN里的一堆杂聊，从信息系统谈到了统计，又谈市场，转而到了决策，BI这个概念也被谈的够乱的，依我说，也就是一个概念罢了。生于乱世，治乱，唯有数也。

 

今天在看金融时报的时候，有篇摩根士丹利亚洲董事长斯蒂芬·罗奇写的评论《US not certain of avoiding Japan-Style ‘Lost Decade’》，大概的意思就是说，如今的美国遭遇，可能会与当年的日本几度相识，只是，美国知道日本当年错在哪里，从而，可以着手应对。不过，我感觉，美国不会如所想象的那么差，首先，货币的政策的放贷，由于很多“热心”的国家和人民乐于向美国借钱，从而支持美国的经济，其次，美国的基于知识的创新文化是其它国家没有办法短时间内复制过去的，因此，美国的创新经济将继续持续下去，因为，这是对知识的一种尊重，并且，能将知识转化为科技与商业价值的一种能力。中国可以借钱给美国，甚至，成立买房团去美国采购，银行可以利用保守继续向前发展，但是，对于一种质的飞跃和创新，却显得无法可施，就像以前，我在一本杂志上看到的一段评述一样：中国可以复制，但是却没有办法创新，即使有一两点创新的火花，但是，很快会被腐朽，急功近利，投机取巧，以及保守的文化所吞噬。中国还仍然处在物质建设期，一切的价值观的出发都开始于物质，落于物质，当然，创造价值也只能仅仅靠物质，而非精神（知识）。那天看新闻，总是在评价，美国，怎么怎么的坏，哪个银行又倒了，哪个企业又举步维艰了，但是你真正的去美国看看，问问那些美国人，真正落魄的人，有，都是那些美国人民当中懒惰的人，勤快的，聪明的，一样过的非常的满足，美国的金融危机，说成是美国的一次大萧条的前兆，不如说是对于美国国民的一次优胜劣汰的筛选和督促罢了。常生病的人，抵抗力才会日益见好，从来没有生过病的，说不定哪天就一下子全倒掉了。

 

 

 

最后，祝你在Dashbroad展现方式上好运。

 

In this quarter, financial crisis begin to try our confidence. When it is very dark of pre-announcing every company's earnings, Technology Services and Outsourcing Services seem to receive the special favor. Management believe data even more. How to be the flexible company during the crisis, and change on demand, that give more opportunity to the Business Intelligence. It seems that Cisco will give up the San Francisco, and HP will trust China even more. Like CEO Mark's announcement in HP Q4 Review, 'Technology Services and Outsourcing Services showed particular strength. ' The Prudent analysis is core needs depend on data. Liquidity is essential for survival, but right now every CEO pays more close attention to the Cash flow than at any time.

 

Forecast, budgets, and changed on demand, these seem to specially prepare for BI. Bring more chances to BI after big fear and uncertainty in the future. Who will win in the next year, BI has the final say.

 

PS: India terrorism issue seem to destroy the confidence about IT Outsourcing from Westen, more opportunity will inflow into China.

   Oracle Finaicails analyzer and Oracle Sales analyzer, it seems that I have not hear about for a long time. Oracle Financial Analyzer (OFA) is a powerful multidimensional reporting and planning tool based on the high performance Oracle Express database engine. Oracle Sales analyzer is focus on the sales analysis parts. I remmeber my first time touch the Business intelligence is using the OFA and present the report to my prefessor Ms. Yao. And that time, I feel very exciting for analysis the dimension build cube, and enjoy the data analysis atmosphere. How wise the Oracle is! Focus on the Financials and Sales which are the big data decision making field. All information needs supply the financial and marketing statement and of course need to analysis detailedly for the management union. How to take care about your management team, that is big issue which I realize in that time.

 

Internet change the business processes more, nowadays, business IT structure prefer to the B/S, OFA is combined built-in the E-Business Suite(EBS) 11i and after EBS 12R, Oracle discoverer and Oracle portalet instead of the OFA BI position, and OFA/OSA become the BI modeling engine outside. But I still think of the Express dynasty just first time like puppy. By the way, manys guys maybe think the OFA and OSA is being out of time, but I think BI tool is just tool, more important thing is your BI analysis and construction thinking.

 

前不久，在TTNN上发了个言，和Qing争论了番，我大概想表述的问题是，虽然，我也认可像Qing所指的应该做一些关于数据仓库实施方法论的东西，不过我期望这种东西，不要仅仅关注在怎样让“机器”跑起来，而是如何让企业利用商业智能、数据仓库抵达成功。

今天，和同事吃中午饭的时候，也议到了这个问题，如何让一个企业明白真正的信息价值，如何去证明。麦肯锡最近的一个关于企业利用Web2.0的技术谈到，现在影响企业实施创新性技术的第一壁垒还是让企业家看不到明显的财务绩效回报。

 

元数据痕迹的大用场
简・奇普蔡斯（Jan Chipchase）
    用户生成内容的激增，将使组织能够比以往任何时候都更加了解客户，这会对用户隐私产生重大影响，同时也是商家的天赐良机。随着越来越多的用户活动“走向数字化”，他们留下的数据痕迹加在一起，就会构成一幅幅用户行为模式图。在互联程度日益密切的未来社会中，各种数据痕迹将创造出一个庞大的元数据世界。有能力对汇总数据进行监控的大型组织，将不得不抵制滥用数据的诱惑。个人和公司需要在服务客户和利用客户之间，十分精确地找到一条新的界线。

联想：BI的BtoC的真正功效开始发挥，决策并不仅仅在于公司，个人也需要决策，同样设计一套很好的信息提取方案，或则社区，或则游戏，让大众成为你最终信息商业产品的懵懂贡献者，这样的成就，非BI技术不可！

P2P经济到来了
斯坦・斯托尔内克（Stan Stalnaker）
    P2P网络把传媒业搅了个天翻地覆，它使信息的流动从一对多模式转向多对多模式，个人既可以是内容的消费者，也可以是内容的创造者。这种冲击波随时会波及其他行业，产生的影响也许会更具颠覆性。在金融服务领域，人们已经感觉到了这种影响。未来，能源业受到的冲击也许会更大。接二连三袭来的P2P冲击波，预示着分布式经济时代的到来，届时消费将转变为生产，从而为个人提供源源不断的小额收入。

联想：其实，信息技术的最大功效就在于使高额的信息平民化，拿BLOG的行语来说就是如何发挥“草根”们的价值，而这种聚合力量，除了借助信息技术，还有别的方法么？

谁在跟你对抗
迈克尔・希恩（Michael Sheehan）
    高管们善于掌控市场竞争，但并不擅长应对对抗局面。当公司将对抗局面误认为是竞争局面时，就会采取一些不恰当的做法，结果导致自己遭受重挫。其实，对抗不同于竞争。企业管理者一旦学会将对抗同竞争区分开来，就能妥善处理对抗问题。此外，公司高管可以从政界领导人那里学到处理这种局面的技巧：把对手的问题当成你自己的问题，重新定义问题以便对你有利，采取转移视线的策略。

联想：关于BI的商业情报学的思考，如何把商业情报学真正的和信息技术结合起来，发挥其作用，值得思考。

专家还有啥用
迈克尔・莫布森（Michael J. Mauboussin）
    过去，我们往往都依靠专家的力量来预测未来、解决问题。如今，随着计算能力的日益增强，再加上网络对集体智慧的激发，专家的价值正在日益缩减。但这并不意味着我们就不再需要专家了，只不过公司需要改变一下利用专家的方式。有些问题，如基于规则且有明显因果关系的问题，用电脑解决更好；而在有些问题上，如或然性问题，众人的集体智慧则要胜过专家。专家们更擅长处理这样的问题：基于规则，但在寻找解决方案的过程中允许有较大的自由度。因此，公司首先要对自己的问题进行有效分类，然后寻找合适的途径来解决。

联想：专家？当网络积聚了众人的力量，并且通过简单的方法得到有价值的信息的时候，请问，专家还拿来做什么？

 

Year	Company acquired	OLAP product(s)	Price	Acquirer
2005	INEA			Cartesis
2005	SRC		$100m	Business Objects
2005	Siebel	Siebel Analytics		Oracle
2006	Geac	MPC		Golden Gate Capital (Extensity)
2006	ProClarity Corporation	ProClarity	~$50m	Microsoft
2006	Temtec	Executive Viewer	$14.5m	Applix
2006	MIS	DecisionWare (including Alea)		Infor (Golden Gate Capital)
2006	Extensity	MPC and DecisionWare		Infor (Golden Gate Capital)
2006	ALG	EPO	$56m	Business Objects
2007	Pilot Software	PilotWorks		SAP
2007	Hyperion Solutions	Essbase, Hyperion Planning, HFM, former Brio	$3.3bn	Oracle
2007	Cartesis	Cartesis Finance, Planning and Analytics	€225 (~$300m)	Business Objects
2007	OutlookSoft	OutlookSoft 5 (formerly Everest)	$375m?	SAP
2007	Applix	TM1 and Executive Viewer	$339m, $306m net	Cognos
2007	Business Objects	BO OLAP Intelligence	$6.8bn	SAP
2007	Cognos	Cognos OLAP Server	$5bn	IBM

 

　　

　　当2007年3月1日,Oracle宣布收购Hyperion,我强烈地感受到在BI软件产业正在进行格局变迁，很早那么早开始大发感言,不过我觉得现在应该是一个K时期了,我曾经狂热的追逐约瑟夫.熊彼特,不仅仅由于他的著作,更重要的是他对我观念的改变,(The Theory of Economic Development):市场经济的成功,主要不是依赖于资本的积累,而是依赖于创新,而创新则是创业精神的产物.当我还沉静在每天众多KPI的分析以及量化分析方法的研究的时候,总是有个声音在对我疑问:为什么?为什么需要去量化这些管理?为什么我要每天去面对这些大量的数据,然后把它转化成有价值的信息?

 

　　商业的进程已经在我们还未察觉的时候,经过了长久的数据积累期,表现是大量的工业企业,特别是企业中的制造加工部分,以及简单的管理实现了初步的数据整合.在这个时期里,主要是实现数据的收集,流程的规范,以及操作流程的电子化.不过今天,各个IT厂商已经开始大量的推广商业管理的电子化产品了,他们把这些产品统归到BI这个范畴里，或则再大点OLAP，不管怎么描述，都为我们提出了一个重要的议题:怎么量化管理的绩效?　那就是现在我在不断投入的的步骤:KPI方法-模型-实施.　我个人认为管理的量化时代已经来临,不仅仅是看到Oracle收购Hyperion, Siebel，SAP收购BO，IBM与PriceWater的融合，更重要的是现在的技术已经超出我们想象，发展的相当成熟和完善，而且现在关于绩效的量化标准也已经步入了成熟时期，我断言：怎么能快速的，个性的，低消耗的实现管理绩效的IT化将作为今后变革的重要看点．

 

　　不过对于习惯模糊管理的中国来说，这样的意识形态能够被接受么？或则说一个基于绩效管理的战略会很快被国人所接受么？我觉得还需要一个过程，也就是我今天所说的，其实我认为BI是一个意识形态的东西，而不完全是技术问题．我很喜欢创造，也很喜欢创新，当然我也坚信国人的创造力是无穷的．前不久，我看了一篇文章，是谈BI的本地化以及在中国的标准，其中谈到应该抛弃外国的那些KPI标准，而应该建立或则创造一套适合国人的，或则适合中国文化的绩效管理方法．我个人看后不赞同，因为其实现在说我们实施BI，与其说是在引进外国的某种先进的技术思想，不如说是我们在学习西方人理性管理思想．如果创造一套适合国人的管理系统，那不又成了一套模糊管理方法了么？因为原因很简单，公司就像国家一样，不能也不应该把全部的责任都过分的依赖一个人．应该通过一些指标或则理性的数据来支持所有的决策，而且应该避免感性犯错，这样的发展方向才是正确的，这样的公司才能够控制．

 

　　公司就像一匹俊俏的烈马，做为一个管理者必须也应该洞察（Insight）内部的一切，这样才能很好的驾驭．而这种洞察的来源，当然就是信息的有效，及时和准确．而信息的提供以及分析转换，已经有效信息的展示技术都相当的成熟了．关键问题是：高层决策者－您想看到自己公司的状况么？

 

 

For the BI (Business Intelligence) technology system to work effectively, companies address the need to have a secure computer system which can specify different levels of user access to the data 'warehouse', depending on whether the user is a junior staffer, manager, or executive. As well, a BI system needs to have sufficient data capacity, a plan for how long data will be stored (data retention). Analysts also need to set benchmark and performance targets for the system.

Business intelligence analysts have developed software tools to gather and analyze large quantities of unstructured data, such as production metrics, sales statistics, attendance reports, and customer attrition figures. Each BI vendor typically develops Business intelligence systems differently, to suit the demands of different sectors (e.g., retail companies, financial services companies, etc.).

Business intelligence software and applications includes a range of tools. Some BI applications are used to analyze performance, projects, or internal operations, such as AQL - Associative Query Logic; Scorecarding; Business activity monitoring; Business Performance Management and Performance Measurement; Business Planning; Business Process Re-engineering; Competitive Analysis; User/End-user Query and Reporting; Enterprise Management systems; Executive Information Systems (EIS); Supply Chain Management/Demand Chain Management; and Finance and Budgeting tools.

Other BI applications are used to store and analyze data, such as Data mining (DM), Data Farming, and Data warehouses; Decision Support Systems (DSS) and Forecasting; Document warehouses and Document Management; Knowledge Management; Mapping, Information visualization, and Dashboarding; Management Information Systems (MIS); Geographic Information Systems (GIS); Trend Analysis; Software as a service (SaaS) Business Intelligence offerings (On Demand) — similar to traditional BI solutions but software is hosted for customers by a provider.^[1]; Online analytical processing (OLAP) and multidimensional analysis; sometimes called "Analytics" (based on the "hypercube" or "cube"); Real time business intelligence; Statistics and Technical Data Analysis; Web Mining, Text mining and Systems intelligence.

Other BI applications are used to analyze or manage the "human" side of businesses, such as Customer Relationship Management (CRM) and Marketing tools and Human Resources applications.Web Personalization For examples of implemented business intelligence systems, see the BI screenshot collection at The Dashboard Spy 

     刚开始接触软件工程的时候，知道其中一个步骤叫做“总体设计”，做这项工作的人就叫“软件设计师”。当时觉得这个名称比软件开发工程师酷多了。到了现在，又开始流行“架构师”（Architect），这个名称听起来比软件设计师又酷了几分。
如今，如果你偶尔遇到一个年轻人，也就是二十出头、三十不到的样子，却客客气气地给你递上一张注明“数据仓库资深架构师”的名片。这个时候，你千万不要诧异。说来也不奇怪， BI在国内刚发展起来没几年，在这个领域干个四五年就足以混个资深的名头了。
不过，话说回来，拿着“资深架构师”的名头去忽悠是一回事，但架构师究竟该干什么，架构设计究竟怎么进行，如何架构一个BI系统？的确是需要认真研究一番的！

第一节：模块

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

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

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

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

第二节：需求

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

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

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

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

     首先，我们可以把这类角色再细分成两类： 一是开发设计及实施者。之所以将开发者作为系统的用户，是因为数据仓库项目应该看作一个过程，而不是产品，因此在开发阶段，其实其架构最重要的用户就是开发者，当然要为之提供便利。 二是系统管理员。系统交付之后，如何监控系统运行、发现数据质量问题、应付新的分析需求等，当然都是系统管理员的分内之事。 
     那么，对于开发实施人员，他需要进行系统部署、ETL的开发调试、质量的稽核；对于设计人员，则需要进行模型的变更、系统调优、系统一致性分析等；而系统管理员则需要监控ETL过程、监控系统运行、响应系统警报、接口数据管理等。这些都可以看作是用例。
这些用例就是架构设计的"需求"，如何满足他们，并且保持良好的体系和清晰的结构，能够易于维护且能够满足日后肯定会增加的业务需求等等，这些都是架构师们仔细斟酌的事情。
     最后，看一下分析人员的需求。举个例子来讲，某销售总监说：“我需要了解近半年来东区和西区的销售量、收入、成本对比”，这可以算是一个用例。对这个需求，架构师该如何做呢？正确做法是，在架构中不能考虑东区、西区这些业务概念，那样就太过于细致，而是应当将这种需求抽象成一种分析应用，例如 “即席查询”。如此，架构师所着重考虑的事情就是如何满足这一类需求，而非这一个需求。

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

近几年来的BI市场虽然已经上演了很多的大鱼吃小虾事件，但仍然有不少的供应商，产品套件也是琳琅满目，SAS Enterprise BI Server、Cognos BI Series、Business Objects Enterprise、Hyperion、MicroStrategy、Microsoft Reporting Services……

但是，严峻的现实是，在通往BI产品选择和标准化的路上依然布满荆棘，很少有人能够理解这些产品中有哪些差别，这些差别又会怎样影响到可用性、可管理性、成本以及最终的成功。当人们购买轿车的时候，他们知道污染、汽油价格等的影响，但是在BI工具的选择和标准化时，诸如“带状报表（banded report）”或“multipass SQL”这样的特性对不同的人就是不同的意思，取决于他是用户、BI专家还是BI厂家。

本文锁定对BI成功部署影响最大的七个主要功能领域，希望能帮助你详细了解其特征及产品区别。

查 询

首先来看查询（Query）功能，也就是怎样把数据从数据的大仓库或运作的系统中取出来。在决定哪一个标准重要之前，企业组织首先必须回答几个策略性问题：

谁来制作大多数的报表，是业务强大用户还是IT开发者？答案也许是“两者”，但是对每组用户的重要功能是截然不同的，这就迫使你或者选择多种工具（尽管可能是来自一家厂商），或者要求一部分使用者牺牲功能。

Web是制作报表的环境还是仅仅为一个发布机制？很多最初为桌面构建的BI产品仍然与Web类产品有功能差异（虽然这个差距在缩小）。

需要指出的是，由于很多现实原因，使用者需要同时查询多种数据资源，有时可能需要把两种数据显示为两种不同目标形式，如，一个消费者收入的表格和一个消费者满意度图形同时显示。另外的情形是，数据可能存储在两个不同地方，但使用者需要合并两套数据并在一个表格中进行分析。理论上说，所有的数据都已经被清洗并存储在数据仓库之中，但实际上，在多数据库的情况下可能存在不同的版本，包括个人电子数据表或部门的数据库。所以收入可能出自数据仓库，但消费者分组及产业分割可能是在 Microsoft Access数据库中。

实际产品的功能表现也不尽相同。虽然Business Objects universe只允许访问单一数据库，但个别的文件允许使用者同时访问多种数据库、存储的程序以及个人电子数据表，这给查询者制作报表提供了相当灵活性，也是Web Intelligence不具备的功能之一。Cognos ReportNet产品包通过ODBC为多数据资源服务。 然而，一个报告只能查询一个包，这给了管理者控制权但限制了使用者的灵活性。同样，Query Studio也只能显示一个表格或图表结果，但Report Studio具有更大的灵活性。Informatica的PowerAnalyzer在管理者定义数据资源之后，允许一个报告访问多种数据资源，结果只能显示一个图表。通过MicroStrategy 7.5的新Document Editor (桌面)，你可以在一个项目中包含多种查询，但项目只能访问一种关系型数据库中的数据，因为这种访问只是在格式化的文件中进行，OLAP分析或钻取(drill-down)对这种文件是不可用的。Microsoft的Reporting Services允许一个文件访问多种数据资源，显示结果可以是两个或一个。

报 表

坦白地讲，报表的声誉并不好。出自大型主机打印机的大量不鼓舞人的文件报表创造了那么多的原始数据，但很少对决策有用。把注意力放在文件报表上几乎很难付诸行动。相反，分析却很容易付诸行动，这也就是许多报告消费者努力的方向。

令人振奋的消息是报表正在改变，如同轿车从单纯的使用机器走向奢华、炫耀的工程之作一样，今天的报表已经能够服务于更敏捷的、更具有竞争性的行动。

首先，随着用户期待指数的提升，对报表工具支持复杂文件、原始数据查询以及在一页或一个报表中以多种方法展现等的需求也随之而来。例如，你可能需要在看到延期交货订单的详细表列数据的同时，在其旁边看到一个能显示未决定、延期、准时出货百分比分布的饼状图。

是否要使用带状报表（banded report）去控制报表设计，也是厂商们最近争论比较多的地方，他们的争执点是关于“怎样”，而不是“什么”的问题。从一个用户的立场，应该关注的是你是否能够拥有分组、小计以及详情等。不过，不同产品实现这些目标的方法也不同。

像MicroStrategy的Report Services使用了带状报表，需要你把小计放到报头或尾部，在主体部分是详情，图表也必须出现在报头或尾部。 像Business Objects Enterprise、Cognos ReportNet、Microsoft Reporting Services等其他BI产品，使用页面设计概念，这样你可以在任何你需要的地方放总计及详情，它们只是独立的对象，其位置你可以自由控制。概要图表也可以出现在页面上任何你需要的地方。两种方法的结果很类似，但设计方法却截然不同，带状报表结构可能对传统大型主机报表开发者更熟悉，页面设计概念则对Excel、PowerPoint或HTML开发人员更熟悉。

下面说说图表。图表的表现价值胜过千言万语。但不幸的是，很多报表开发者仍然使用传统表列数据，其实图表是最方便于分析的工具。

所有厂商都提供同样的基本图表类型：柱状、线形和饼状图，但只有少数提供map、bubble等独特的图表类型。在图表类型中，使用者需要具备控制不同图表属性的能力，如min/max刻度、标志布置、3D效果、个别线条或条棒的颜色等。

双Y轴的能力是绘制多度量器时的必备条件。例如，如果你分析随着时间推移价格对销售量的影响，你就必须要有两个Y轴。Business Objects在其桌面工具中提供这个功能，但在其Web Intelligence中并没有提供。Cognos ReportNet也有类似的局限性。

再看报表协作性。报表消费者（典型的商业业务使用者）能够与报表相结合的程度也是一个重要的衡量标准。不能提供协作性的报表只不过是使分发“哑巴”纸质报表的过程自动化而已。发现一个趋势图中的异常只是商业洞察力的第一步；能够研究这种异常才是关键性的第二步。

即使BI工具提供了一定程度的协作性，一些使用也会限制它。聪明的使用者会自动输出数据到Excel，创造多种版本的真相，这是目前一种更加危险的状况。

协作性有两方面：单独的报表协作性，跨越多种报表导航。在两种情况下，报表和OLAP钻取之间的分界线正变得越来越模糊不清。

Business Objects Web Intelligence提供了很好的单独报表协作性；Microsoft Reporting Services提供了模拟钻取(出)的一个独特大纲视图，但它缺少过滤和分组。Cognos ReportNet在单独报告协作性方面较弱，只提供了一个静态页面，但是ReportNet提供了很好的全面导航功能，允许在报告之间钻取(出)以及报告与其他应用之间的钻取（出），包括Cognos PowerPlay和Visualizer。

Informatica Power Analyzer 的导航功能非常独特。胜过从一个报告到另一个报告的钻取，Power Analyzer使用了“工作流（workflow）”的概念，使用者看到一个可选择报告的列表，而不是只能在一个静态的子报告中挑选，一个主报告可以有多种工作流，灵活地提供了更多导航。

需要指出的是，文件复杂性、图表、协作性等只是各BI厂家提供的一些主要差异性报表特性，诸如有条件格式化、相对定位以及格式纸等另外的一些特性也会影响报表设计。

信息发布

查询和报表使你把原始数据转变成能促进决策行动的强大的文件，然而，除非你已经把那些文件放到决策制定者手中，否则数据间的链条仍然是断开的。接下来就要依赖于信息发布（information delivery）功能了。

两种技术对企业信息发布有重大影响：Web和email。

过去，信息递送过程包括走向打印机、拿到打印输出，或者传达室把报告递到你手上。在20世纪90年代后期，很多公司有了企业内部网络，开始把标准报表输出到内部网上，这些报表可能是电子数据表文件或以HTML保存的静态BI报表。

今天，BI报表按照BI工具赋予的文件格式存储，拥有更多协作和更新数据的能力，Web和email也扩展了报表传递的范围，尽管当初上百用户执行BI就被认为是很大规模，今天所谓大规模已经是好几万的概念。这样，可扩展性就成为衡量信息发布功能的一个主要因素：一个报表必须到达多少使用者以及怎么样到达。

评估各厂家BI工具的可扩展性并不容易，因为不同产品扩展方式不同，仔细查看公开的基准测试结果、查看消费者指南手册、理解其架构是评估一个产品是否能按照你的期望扩展的必要步骤。

按照信息发布来评估可扩展性要求，你还必须考虑使用者怎样与报表相互作用。一种所谓的push（相对于pull）方法是，BI工具按照计划产生报表，然后通过email或无线设备等门户把这些结果推向最终使用者。乍看，push方法好像是管理可扩展性的理想方法，因为IT能够预先决定什么时候处理大量BI作业。但是，就像一个执行主管反映的，他经常被报表email所淹没，现在他通常是删除，因为他认为如果真的有问题的话，肯定会有人打电话给他。很显然，并不在于说你推出去多少个报告，而要看多少人在做决策的时候真正使用了这些报告。

而且 ，还必须考虑你强行推给用户的是一种静态PDF附件还是一个到BI报告的URL，如果是PDF，扩展性需求并不是很严重，因为PDF是预先制作好的，使用者在浏览报表的时候不会对BI应用服务器造成压力；但URL情形则需要更多的扩展性，因为使用者要访问BI应用服务器。

push方法还包含“bursting”问题，也就是拿到一个大型报告，并分解，以便不同使用者只能得到允许的或需要看到的数据，如，每一个人事主管只能看到其职工的薪酬。这种个性化无论从安全方面还是从管理信息超载方面都非常重要。

在大多情况下，bursting能减轻RDBMS（关系型数据库管理系统）的一些负荷，因为许多的人事主管并不需要运行许多的单独查询，而是，运行一个大型查询，其结果被分为多个部分。

然而，bursting的实现方法也不同，也不总是能提供这种优势。比如，在Business Objects提供的两种bursting方法中，一种就是通过Broadcast Agent Scheduler为每一组接受者运行查询，这种技术允许公司使用独立数据库登录，并具有安全性，但它会给RDBMS造成不必要的负荷。Cognos Impromptu 也使用这种方法。
图1 Business Objects 的InfoView Portal允许使用者创建
可作为dashboard使用的My InfoView,内容包括报、Web URL等.

不过，大多数的产品，包括Business Objects Broadcast Agent Publisher及Cognos ReportNet，都是使用运行一个查询、然后分裂为多个单独报表的方法，这样减少了查询对RDBMS的访问。

久经考验的pull方法是广大最终使用者喜欢的方法，然而它对IT部门和厂商提出了更多挑战。这种方法是使用者登录到BI的工具，有选择地寻找他们需要的报告。

schedule-and-pull取代schedule-and-push方法的过程将是很缓慢的。有重现信息需求的使用者可能会把查询更新的时间安排在非高峰时间，或者说，IT可能会将高使用率的报表安排为整晚更新，以便其结果能够预先缓存给使用者。schedule-and-pull的方法减少了BI应用服务器的负荷，从而让它能支持并发的查询更新以及复杂文件的产生等。

专门的BI门户能够让使用者访问标准的报表或个人报表。对于一些已经实现企业范围门户解决方案的公司来说，与Plumtree、IBM WebSphere或Microsoft Sharepoint等门户产品集成是非常重要的。根据你不同的策略，你也许：把特定的BI功能嵌入企业门户中； 从企业门户内部访问专门的BI门户；通过Web URL访问专门的门户。

好的BI门户允许使用者将门户定制到诸如My Yahoo 这样的仪表盘中，显示多种报表、Web站点、提示以及报表列表等。标准的报表通常以各种主题分组。完美的BI门户允许一个报表以多种方式分组，而不会造成同一报表的多复制本。而且越来越多的厂商允许电子数据表、PDF文件等非BI文件存储在BI仓库中，并在门户中展现。随着BI内容的增加，使用者也需要简单的方法来通过作者、关键字或其他方法来查询报表。

Excel集成

在评估BI工具套件功能的时候，人们往往很容易沉浸在逐个功能的对比中，而忽略了执行BI所要达到的商业目标。前文曾经把选择BI工具与购买轿车相比拟，在购买轿车的时候，我们很少考虑将怎么使用它或有关正确的驾驶方法等，在为“它是如此酷、敞亮、时尚”激动之中，一些最好的实践和使用往往被丢到脑后。在选择BI工具的时候，有一个特别的功能是用户非常需要的，我们这里也将直接深入研究，那就是Excel集成。

尽管Excel可能是无可争辩的最主要的BI工具，但它也是导致多种版本真相的主要原因。两个使用者同时查询一个中央数据仓库，并把数据导入Excel，一个使用者在Excel中使用一组特殊的标准过滤数据，并用一些个人的公式来计算；另一个使用者过滤数据的方法稍有不同，或许在公式中犯一个小错误。谁的电子数据表是正确的呢？结果大量的时间花费在协调多种版本之上而不是考察业务发展。在每次查询更新及产生结果报表以后都必须重复同样的流程。

尽管电子数据表存在正确性问题，但是还是有很多因素使得在BI工具选择中不能忽略Excel集成：

工具熟悉。使用者很少有时间获得数据然后去分析，通常最简单的方法就是使用他们已经熟悉的工具。

“按摩（massage）”数据的能力。“按摩”数据包括重新分类、过滤、创建公式，以及在某些情况下修理坏数据等。理论上说，所有这些都应该在BI流程的早期完成。在报表部分我们提到，能够让使用者重新分类、过滤或在本地BI工具中隐藏个人专栏的BI工具协作能力，当这种功能失效或不存在时，使用者除了把数据导入Excel外几乎没有多少选择。在Excel电子数据表中校正坏数据的巨大任务对于数据一致性来说显然是一场噩梦。然而，如果流程不能适当地从根源上修理坏数据或修改ETL错误，使用者无论如何也难以创建一个有用的报表。

较好的图表。Excel图表以及所有对比例、坐标轴、标注的控制已经成为一种事实上的基准。如果BI工具不能提供强大的图表功能，显然使用者需要把数据输出到Excel来使用其图表功能。

摘要文件（Briefing books）。Excel可以将多个工作表存储在一个工作手册（workbook）文件中。 使用者可以离线访问所有数据，这些数据可能是通过多种数据源或查询组合成的一个文件。很少有BI厂家能够很好地复制这个功能。尽管仪表盘功能提供了类似的替换选择，但通常需要网络连接。

减少许可证成本。企业已经花费了Excel的许可证费用，如果他们能够通过更好地利用Excel减少BI使用者的数量，那他们就可以节省BI许可证成本。不过，BI厂家也在逐渐加宽“使用者”的定义，一个BI使用者已经不再是某一个登录BI工具的个人，而是所有能够接到BI工具输出（包括电子数据表）的人。

既然限制Excel是不可能的，关键就是找到既提供Excel集成又能保证单一版本真相的方法。各个厂家实现这个目标的方法也不同。最差的，所谓“零支持”就是一次性输出到Excel，既没有对该输出的查账索引，也没有连接到中央的查询。所谓“良好的支持”是指，BI工具跟踪Excel电子数据表的所有权及所做变化，然后把数据表存储在BI仓库中。

Excel电子数据表可以随着新数据更新，特别是能保持与原始查询文件的连接。需要指出的是，没有任何单一特性能够保证单一版本真相，它的实现部分依赖于厂商提供的功能特性，部分依赖于你必须执行的流程。

例如，MicroStrategy的Office产品就是一个Excel插件，可以使用户查询及更新一个存在于电子数据表环境或PowerPoint和Word中的报表。当原始报表的定义或基础数据变化时，电子数据表也随之变化。同样的报表浏览可以通过Web、桌面或电子数据表来完成，这样使用者可以通过他们喜欢的界面来访问，从而也保证了单一版本真相。

把数据一次性输出到Excel是企业保持单一版本真相的最大挑战，但好像也是最普遍存在的一种现象。如果你浏览的报表并不是按照你的需求过滤或分类，你只是简单地存储数据到Excel并在那里做分析，BI团队必需事先有准备：如果很多使用者都这样工作，BI团队就必须在本地BI工具中提供更好的协作性，或修改标准报表定义。不过，如果是个别需求，那另当别论。

最后还要指出一点，在关注Excel集成时，应该注意需要哪个版本的Excel，以及跨越版本是否有功能上的差异。

OLAP

有些分析家认为OLAP（Online Analytical Processing，在线分析处理）只对小部分用户适用。但现在大家普遍认为，从断断续续的信息消费者到强大用户（power user）都能从OLAP功能的不同方面获益。不幸的是，OLAP体系结构和成本经常会阻止其广泛采用。

OLAP vs.报表

早在20世纪90年代，Essbase（当时为Arbor所拥有，现在是属于Hyperion）被看做是另类，所以Arbor雇佣关系数据库之父——E. F. Codd来澄清这一称为OLAP的新东西。Codd定义了12条准则，但以下4条最能清楚地把报表和OLAP区分开来：

1. 多维的：用户从多方位分析数值，如产品、时间、地理等。但一个报表一般都是基于单一尺度，如在某一个时间点上的产品价格列表。

2.快速：当使用者在一个维度中操纵不同的维度及等级时，OLAP意味着快速——思考的速度。如果一个使用者双击以从年度到季度钻取，为一个答案等待24分钟或24小时是不可接受的。当然，报表使用者也并不想要慢的报表，但实际中确实很多报表必须运行这么长时间。

3. 改变聚合的等级：为确保可预测的查询时间，OLAP供货商以不同方法重新聚合数据。相反，报表至少是需要细节：除了按照产品的销量外，对于特定顺序的数据，其中可能还有单独的排列项。

4. 跨纬度的计算：多维带来了复杂的计算。在OLAP中，你可能需要分析百分比贡献或市场份额，这些分析需要先做某一特定状态的销售小计，然后再计算对整个区域、国家或全球的百分比贡献。使用者可能通过许多其他维度来分析这个百分比市场份额，如实际vs.预算，今年vs.去年，或为特定的一组产品等。这些计算经常必须以特殊的顺序执行 ，并包含使用者从来没有见过的一些输入数字。但是，详细的报表经常依赖于简单的小计或报表本身显示的一些数值的计算。

不过记住一点，我们仅仅是对报表和OLAP加以区分，并不意味着使用者需要他们的分析工具和报表工具截然不同。OLAP使用者应该从多维数据中创建报表，相反，报表消费者也需要从前仅供OLAP专用的高度形象的分析 和红绿灯显示。怎么满足这些不同的需求，厂商们也已经奋斗了很多年。当你选择一种或多种BI工具时，你的工作是了解你最需要什么：OLAP，报表，还是两者。如果答案是两者都要，那么就需要仔细评估报表和OLAP的集成。

OLAP体系结构

在选择OLAP工具时，OLAP体系结构是需要理解的一个最重要的标准：它会影响很多其他单独特征以及你部署系统的能力。最近人们认为MOLAP-ROLAP-DOLAP（多维OLAP-关系型OLAP-桌面OLAP）争辩已经平息。我认为，只要厂商还提供这些不同的方法，争论就会存在。

MOLAP使用一种持久稳固的立方体结构，与关系型数据库是分离的。Hyperion Essbase、Microsoft Analysis Services、Cognos PowerPlay都是使用了这种方法。因为一个立方体包含一个预先计算好的数据子集，所以与DOLAP和ROLAP相比响应时间更快速且可以预测。MOLAP数据库传统上还具有更大程度的多维计算，比ROLAP中也更容易实现。例如，Hyperion Essbase使用一个@DESCENDANTS功能，让你将一个特定级别中的成员指向同一层次（如，一月、二月、三月并列是第一季度的下一级）。尽管一些关系数据库具有CASE功能，也可以使你在一个计算中指向这些行，但并不是所有都能做到，而且计算并不一定都是直截了当。

MOLAP的大幅下降是因为它是需要IT支持、管理、维护的另外一种数据存储。公司抱怨维护200个立方体需要很多努力，或公司拥有的是花费一个星期重新计算的设计不良的立方体，这都是很平常的。当一个维空间改变，如增加一个新的产品或改组业务单元，你可能就不得不重新计算整个MOLAP立方体。

而关系型OLAP是使用关系型表格来提供多维分析，MicroStrategy和Informatica是主要的ROLAP厂商。MicroStrategy使用RDBMS中的分区和聚合表格来提供快速查询;为实现复杂的OLAP计算，它使用了一个 multipass SQL和临时表格的结合体。

ROLAP工具没有单一立方体的限制，但却因低的响应时间而苦恼。 如果你公司没有技术型DBA来熟练调整数据库，获取一个用户钻取的结果可能需要25分钟的查询。历史上，在MicroStrategy中的一个钻取经常会触及最根本的关系表格。不过有了MicroStrategy的OLAP Services后，钻取会访问缓存，这也是对“ROLAP先天就比MOLAP慢”的有力还击。

很多MOLAP厂商使用ROLAP和MOLAP相结合的方法，这种方法被称为hybrid OLAP（HOLAP）。例如，Microsoft Analysis Services就能够使用ROLAP体系结构来对付大数据量；Hyperion Essbase也能在关系型表格中存储大量维空间。像其他ROLAP工具一样，其响应时间还是要比严格使用MOLAP慢，所以很多执行继续使用MOLAP存储来保证快速分析。

DOLAP代表桌面OLAP，是因为很多处理需要在使用者的桌面来完成。也有人把它叫做动态OLAP（dynamic OLAP），以突出微小的立方体是如何动态创建的，也许在桌面上，但大多是在中间层的应用服务器上。与MOLAP不同，这种情况IT部门不需要提前创建大型立方体，而是当使用者运行查询时动态创建立方体。相比MOLAP和ROLAP，其一个立方体中的数据量和维空间计算是有限的（尽管也可以达到GB级别）。这些立方体更适合看做是个人立方体。

DOLAP的最大好处是灵活性和维护：立方体不需要提前创建，当你公司增加一个新产品或重组部门时，这些变化也将在你更新查询的时候自动表现。不过，DOLAP工具同样也遭受与ROLAP一样的RDBMS性能的所有风险。

由于具有从多种数据源中抽取数据的能力，MOLAP工具经常被成功应用于小数据仓库的平台。这对于企业信息架构来说显然是不理想的。因此，来自多种数据源的数据最好能装入一个中央数据仓库中，然后才能用于组装MOLAP立方体。尽管，在实际中一些公司没有构建数据仓库的能力和资金，但具有数据仓库结构的MOLAP立方体确实能受益于快速的立方体创建。对Business Objects的microcube来说，一个立方体可以基于多种查询、存储的流程、XML文件及电子表格等来创建，Cognos PowerCubes和Hyperion Essbase cubes也能从多种数据源创建。

另外，对一个管理者来说，能够很轻松地设计、构建并调整OLAP平台是非常关键的。对于最终使用者来说，诸如属性分析、 假定性分析、红绿灯显示、时间周期分析等也是非常重要的。

管 理

管理方面的特性可能并不会引起商业使用者的兴趣，但却同样重要。好的部署应该既考虑到最终使用者的需求，也考虑到BI工具的管理问题。如果没有全面考虑二者，企业最终所有的无非两种结果：看似很好但需要相当的IT资源来维护的工具，或没有人使用的系统。

安全性

我承认，我憎恶BI安全。并不是说我没有看到需求，而是厌恶跟踪更多的用户ID和口令！没有什么比当一个BI使用者很高兴地访问仪表盘时却总被“不正确的口令”所折磨能更快地扼杀BI执行。一个教训是：你可能花费了大量时间来选择BI工具，但如果你没有花费足够时间计划安全性，工具早晚会被破坏及登录错误击垮。

安全可以分为两个阶段，首先是鉴定(authentication)——一用户名和口令的有效性；第二步是授权（authorization）——在鉴定以后允许其访问什么。LDAP (Lightweight Directory Access Protocol)服务承诺将多用户ID和密码问题减到最少。理论上，一个公司将拥有一台目录服务器来保存所有员工的用户名和密码。公司所有的系统，无论是网络、BI或ERP，都使用该目录服务器来鉴定。现在，还没有目录服务的清晰标准。Sun的iPlanet、Microsoft Active Directory、Novell的eDirectory 是业界比较领先的产品。BI厂商会支持其中一些或全部。

由于历史的及实际的原因，大多BI工具继续使用它们自己的鉴定机制。 如果你公司还没有实现目录服务器，你就需要这些机制；如果你已经有了目录服务器，你就需要BI工具来鉴别它。

授权比鉴定更杂乱。在授权中，你可能需要限制一些用户使用特定的业务浏览或元数据层、个别报表、软件功能以及数据等。理想状态，你需要定义角色（role）或用户组（groups of users），以便这些授权能够在组级实现，而不是直接针对上千的个人用户。这里有一个很大的挑战：即使你有一个LDAP服务器来做授权，你也不得不在BI工具中复制所有个人用户的ID来为授权服务！ 这种复制会带来风险——诸如用户ID或密码等一些东西有可能失去同步性。然而，如果你能够在目录服务器中定义组，并且BI工具能够读这些组，那还是有希望的。很明显，很多BI厂商在向这个方向靠拢。

元数据

元数据集成（Metadata integration）提供很多承诺。首先，它能减轻业务视图的管理；其次，它能给需要对每个metric的来源、转换以及计算有一致的、精确定义的业务使用者带来更大的透明。

不过，这些也仅仅是承诺。在实际中，BI基础架构中的每个组件都有自己的元数据，并为不同的目标而使用。一方面，这种情况存在是因为元数据已经被当做每个组件的“私有品”来对待，另一方面，也是因为每个组件都有自己的要素。使用BI工具的业务使用者需要业务术语，使用ETL工具的IT部门则需要知道确切的来源系统、表格名称以及数据元素的起源地。是否要赋予数据元素一个商业术语对IT用户来说并不重要。

从BI套件来看，你应该考虑你需要共享什么元数据？在哪些组件之间共享？过去，BI厂商采取不同的方法来共享数据，经常是提供专有的API。随着来自Object Management Group的CWM (Common Warehouse Metamodel)被大家接受，厂商们很快就开始提供支持。后来，Business Objects和Cognos还使用了MITI (Meta Integration Technology Inc.)提供的一种遵循CWM的元数据桥（metadata bridge）。SAS的Enterprise BI Server version 9也在元数据交换方面做了创新。这些都是为元数据交换而走出的很好一步。

影响分析

影响分析（Impact analysis），是指当你改变或删除一个数据元素的时候，能够知道哪些报表将受到影响的这样一种能力。影响分析在BI架构的不同点都有关。如果是源系统中发生改变，你怎么能够知道在业务视图以及最终的报表中什么将改变？如果是在业务视图中发生改变，这种变化是否能够自动传达到报表中？至少，管理员需要有能力识别BI套件中相互依赖的BI元素。

Business Objects的ETL工具Data Integrator，就同元数据层或universes有很好的影响分析。然而，其元数据设计工具Designer 内的影响分析却很少。MicroStrategy的影响分析工具更进一步：当你试图删除一个对象时，它立即会警告你哪些报表依赖于该对象。

使用监测

不能监测BI系统的使用，就如同在夜晚不开前灯和仪表盘驾驶汽车一样。最糟糕的情况就是你（或你的服务器）被撞坏，最好也不过你把汽油耗尽（或查询失败）。随着BI厂商越来越把目标锁定企业范围的部署，它们也开始注重提供使用监测功能。最初，厂商把BI行为记录在log文件中，很少在分析应用中使用。理想的情况应该是当数据在关系数据库中被捕捉到时，厂商提供预建报表；此外，管理员应该能决定哪些行文是要监测的，从大量的注册直到谁访问哪个目标等。

MicroStrategy通过其以服务器为中心的架构，在提供监测BI使用的工具方面一直是领导者。Business Objects也从2001年就推出了其Auditor产品，随后Cognos、Crystal、Informatica等都推出此功能。

不过需要提醒的是，数据库监测和BI监测并不相同。在数据库层面，你可能会跟踪数据库领域ORDER.QTY被访问的频度；在BI应用中，却需要知道哪些计算出的metric用户最常访问，还包括哪些标准报表、哪些展示格式以及最大负荷时间等。

BI工具架构

最后，我们来关注结构方面的一些考虑因素，以便能够结合上下文帮助你找到适合自己企业的最好BI工具。BI架构的很多方面是从厂商的演示过程中得不到的，如：是client/server还是基于Web？使用了什么OLAP方法（MOLAP、ROLAP、DOLAP）？该BI工具是否能容易地定制或嵌入到其他应用中？该套件在查询、报表、OLAP、仪表盘以及分析应用等不同工具间使用的框架（元数据、安全以及基础架构）是否是通用的？该服务是否能跨越多个服务器和平台分布？很多BI套件架构方面的不同，也许只有当你安装、部署或定制产品的时候才能清晰体会到。

SOA

由于BI已经走向Web以及企业范围部署应用，今天的BI工具都具有服务导向的架构，即SOA（Service Oriented Architecture）。SOA允许不同的BI服务去执行特定的任务，必要的时候还可以分布到多个服务器上。
图2 BI工具的SOA7:BI应用服务器可以运行在一个Web服务器上，也可以运行在一个特定的应用服务器上。

我们以三个可能的BI服务举例来说：查询、展现以及时序安排。如图2所示，查询引擎负责查询数据源，可能是一个数据仓库或 MOLAP立方体。当查询完成后，展示部件必须将查询结果转换成有意义的报表，也可能是图表和交叉表，而且还需要不同文件格式，如HTML或PDF。如果一个用户预定了某一个查询的时间，时序安排服务就会不断地监测是否到了已预定查询的执行时间，并在准确的时间把它传递给查询服务。查询、展示以及时序安排之间如何沟通，这就是诸如COM、CORBA、Web services协议等标准起作用的时候了。当然也有一些BI厂商会使用自己专有的方法来处理这些部件之间的通信。COM和CORBA是支持SOA的比较老的方法，Web services标准正处在高速发展期，其接受度和功能都在不断提升。

可扩展性架构

有趣的是，好像所有的BI工具都具有向上和向外扩展的能力：如果你添加更多强大的硬件（向上扩展），它就可以支持更多的用户；如果你添加更多服务器（向外扩展）并分布服务，它也能支持更多用户。然而，很多企业的目标是降低复杂性和成本。撇开对容错的考虑，如果所有的东西都高效地运行在一台服务器上，你就节省了硬件和管理的成本。

很不幸，目前针对BI工具还没有供对比产品用的基准测试。而且，使用和部署产品的方法也会影响其可扩展性。如，更新Business Objects全部客户机文件比更新其最新的瘦客户机文件就要更耗费资源。对MicroStrategy来说，数据仓库中聚合的表格越少以及一个报表模板中使用的过滤器越少，系统就越慢。

不管如何，你也可以根据一些特性来初步观察某一产品套件对资源的占用：OLAP体系结构、多线程的流程、查询管理器、高速缓存等。查询管理器可以使管理员防止饱和系统中的复杂及有害查询。好的BI工具都提供查询管理器，这样可以方便控制并发查询进程的数量、每一次查询返回的行的数量、以及一次查询运行的时间。理想状态，这些限制应该在每个服务器、用户组、不同任务或个别用户等不同级别中被定制。

另一种将这种服务器负荷风险减少到最小的方法是高速缓存。如果一个查询更新的请求能够通过高速缓存服务，那么并发查询进程就会减少。高速缓存还可以帮助BI架构中的其他服务，如授权和展示服务。当然缓存的重要性也是由特定工具的架构决定的。如MicroStrategy提供广泛的缓存，包括SQL、元数据甚至查询结果。管理员对指定什么获得缓存以及监测缓存是否使用都可以有良好控制。

总 结

本文的目的是帮助大家了解什么BI功能是重要的以及原因。逐个功能比较是选择BI工具的一个方法，但并不是惟一方法。如同你购买轿车的时候，也许你购买福特的原因是你想购买美国品牌，而你选择通用可能是因为你的邻居就是其经销商，或许你购买Hummer是因为你喜欢其形象。同样的无形的及策略性的考虑也会出现在选择BI套件的情形。每一个BI厂商都有一套独特的BI策略。像Business Objects、Cognos、Hyperion这些主要竞争者都追求BPM（business performance management，业务性能管理），但方法却有截然不同。

每个厂商也都有各自独特的“最佳听音点（sweet spot）”、历史起源、以及对BI范围的观点。有一些厂商已经把BI范围扩展到包括数据库、ETL工具以及分析应用等。 而有的厂商仍然坚持核心的查询、报表、OLAP三大功能。到底哪一种更好，这完全取决于你的出发点。如果你已经有了ETL工具，你是否还真正关心BI厂商是否提供一种不同版本？确实，还有一些协作性考虑，如元数据交换、安全等，但在眼下的BI市场，协作性问题对于把目光锁定在同一供货厂的BI工具的公司以及从多家厂商购买工具的公司来说都有挑战。

坦白来说，在目前BI市场，可能没有任何一家厂商在所有功能领域都显著领先。而且，最好的BI工具也并不是市场份额就能决定的，也并不在于谁先出现在这个市场上，而是看谁能够最有效地使用户实现他们的商业目标。