近幾年來的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工具也並不是市場份額就能決定的，也並不在於誰先出現在這個市場上，而是看誰能夠最有效地使用戶實現他們的商業目標。
