超義Power Process Suite
強調整合及服務的價值，避免淪為眾多WorkFlow產品之一
成立將近四年的超義科技，今年以文曄科技為成功案例，獲得WorkFlow組織WfMC（The Workflow Management Coalition）及WARIA（The Workflow and Reengineering International Association）環太平洋區金獎。獲獎的原因在於整合IBM WebSphere Portal、Power Process Suite及SAP ERP系統，使管理者透過瀏覽器即可管理日常作業，企業流程執行的結果也即時反應於SAP ERP上。
BPM的完整標準，分為處理人事的事務性表單、系統整合及B2B三方面，事務性表單著重內容的呈現，Power Process Suite以Power WebForm提供表單設計及管理工具；系統整合則以Power Process BPM設計流程並以配接器與其他系統串連；另外RosettaNet模組提供企業串連合作夥伴與客戶等系統的橋樑，滿足資訊流通的需求。
提供企業對內及對外整合的解決方案
超義科技提供的商業流程解決方案，包括ERP系統、IBM Notes、B2Bi及企業入口網站等的整合解決方案。企業內部透過超義科技開發包括資料庫、檔案、FTP及SAP ERP系統等的配接器（Adapter），讓BPM成為整合企業內部資源的神經系統。
直接存取資料庫整合系統是最低階的方法，SAP等ERP系統為保障穩定性，並不開放資料庫供其他系統直接存取，透過應用程式層級整合才是最有保障的方法。因此超義科技根據廠商提供的API開發配接器，作為應用程式間溝通的橋樑。目前Oracle ERP的配接器正在建置中，隨著各種客戶導入經驗的累積，未來將提供更多系統的配接器。
在IBM Notes解決方案，超義科技的工作流程可與Notes整合。此外，透過RosettaNet模組，支援RosettaNet垂直整合標準，對外可串連合作夥伴及客戶的系統。Web化已是大勢所趨的方向，Power Process Suite同樣使用Web化的介面，可與IBM WebSphere或企業自行開發的入口網站結合，豐富入口網站的功能。
百家爭鳴的標準，逐漸走向統一的格局
目前WorkFlow及BPM相關的標準不一而足，包括WfMC制定WorkFlow的標準、W3C有Web Services相關的標準、BPMI.org提出的BPMN（Business Process Modeling Notation）是BPM標記的標準、而OASIS組織則由微軟及IBM合作推出BPEL4WS。超義科技則是遵循WfMC提供的5個介面（Interface）標準，開發Power Process Suite。
一般認為BPEL4WS標準未來將成為BPM的主流，因此超義科技逐步依BPEL4WS標準，研發流程設計工具。BPEL4WS可謂流程的標準描述方法，如果市面上的流程設計產品均遵循統一標準，工具便有了可交流的統一語言，流程可匯出至其他同類產品繼續使用。
超義科技總經理黃仕鎮反而認為：「流程標記統一的意義，會大於流程描述統一的價值。」也就是BPMN大於BPEL4WS的重要性，因為企業同時使用兩套BPM系統，且彼此匯出/匯入流程的可能性不大。而且完全遵循BPEL4WS是完美的理想，各家廠商往往會增加專屬的規格，因此破壞互通性。而B2B的應用也不見得需要BPEL4WS，藉由ebXML、RosettaNet及EDI等標準，即可建立企業與合作夥伴電子化的訊息傳遞機制。
BPMI.org制定的BPMN則類似UML（Unified Modeling Language）的概念，由於使用一致的流程圖形表示法，企業無論搭配哪一家產品，設計人員均可輕易上手，減少學習的成本。
Power Process BPM
Power Process BPM的Process Engine為主要的流程引擎，搭配Process Modeler、Process Monitor、Event Manager、Organization Editor、Work Zone Manager、Integration Manager及Rule Manager等7大管理工具協助處理商業流程。
Process Modeler用以設計及定義流程，以拖拉點選節點的方式設計流程，並可定義流程變數。流程模擬及測試機制可協助開發人員確認流程設計邏輯，減少來回修正的時間。流程各節點中的表單可選擇URL、JSP、ASP或WebForm Editor開發的表單。
以Java開發的Power Process BPM，因為採用JCOM技術，所以可搭配ASP表單。JCOM（Java-COM Bridge）是一組程式庫，可串連Java與COM，使COM元件可被Java程式使用，例如在Java程式中使用Excel工作表或VB應用程式。
Process Monitor則是視覺化的監控工具，提供流程暫停、恢復、中斷、重新啟動及執行例外工作等功能，並可依管理者需求製作報表。Event Manager可設定流程自動執行的時間與頻率，定時啟動特殊或例行流程。Organization Editor即組織管理功能，支援多重組織及角色的設定，可編輯人員的角色以分派工作。Work Zone Manager依不同的國家或工作型態，可設定不同的工作時區，跨國企業即可精確計算各地員工的工作績效。
Integration Manager負責管理串連其他系統的配接器，例如ERP系統改版時，只需更動串接ERP的節點。當流程執行出現錯誤時，也容易除錯及維護。Rule Manager則是管理商業邏輯的機制，流程判斷以具體的物件化管理，可增加重複使用性，減少維護的負擔。
Form Editor頗具特色
從流程與資料分離的概念出發，Power Process BPM與微軟的BizTalk Server類似，是流程設計與管理的工具，且可串連應用程式取得流程中需要的資訊；而Power WebForm則與InfoPath類似，是一般WorkFlow事務性表單的設計工具，提供設計及管理表單的功能。
Power WebForm包括Form Manager與Form Editor，Form Manager分為表單管理系統及表單使用者工作區兩部分，表單管理系統包含目錄管理、存取控制、查詢管理及客製表單，提供管理者管理表單與系統設定功能；表單使用者工作區包含待辦事項、經手文件、文件查詢、內部表單及資料設定功能，使用者可填寫表單、執行待辦事項或查詢歷史記錄。
一般WorkFlow產品提供的表單編輯器，多為用戶端應用程式，若是透過瀏覽器執行的編輯器，不是被Web化的操作模式限制，必須不斷重新整理網頁取得更新的內容，就是必須下載元件，拖慢執行效率。
超義科技因應微軟的InfoPath與Adobe XML/PDF Form Designer Beta版，採用資料與表單呈現方式分離的概念，整合XML標準開發Form Editor。表單只是蒐集及呈現資料的容器，表單資訊可根據使用者角色與權限，提供個人化的呈現方式。
以Object-Oriented JavaScript及DHTML DOM的技術開發而成的Form Editor，是相當具特色的設計。由於支援XML標準，可跨平臺傳遞資訊。用戶端無須下載外掛程式，即可透過瀏覽器設計Web化的表單。Form Editor的設計介面類似Word，可隨意縮放欄位大小、設定屬性及資料源，並拖拉使用附件、編輯器及日期等元件，減少程式設計的時間。
Form Editor提供預覽功能，可檢視表單呈現的樣貌。表單內容為單純的JavaScript及HTML，可直接切換檢視原始碼，原始碼即設計碼的概念，讓美工與程式設計人員可協同合作。
服務與產品的價值並重
文曄科技董事長鄭文宗表示，自從2000年開始走向國際化後，每天處理數以千張傳真的訂單資料，不但難以彙整且沒有效率，資訊系統間重複輸入資料導致曠日廢時，也增加出錯的機率。資訊流動的速度決定工作效率，當資訊流動加快，也大幅提升決策的速度。藉由SAP ERP系統與Power Process Suite的整合，輔佐決策的相關數據一併顯示，使主管決策時更具信心。
以文曄科技單一案例獲獎，雖不見得可判定Power Process Suite的功能完整，但至少代表超義科技的客製化及顧問服務品質獲得肯定。BPM與WorkFlow發展的方向已經漸趨一致，兩者的定位都不是套裝軟體，從建置、系統操作到客製化，在在都需要廠商的協助，售後服務的品質，是專案成敗的關鍵因素。
資訊業等同於服務業，企業在選擇BPM產品時，除了考量價位，更應重視服務的品質。超義科技強調產品與服務的結合才能發揮最大效益，因此成立專業服務部，與客戶建立永續的夥伴關係。
UniMarketing
以資料採礦技術分析銷售客戶的相關資訊，進而根據購物習性預測出合適的商品組合
探宇科技的UniMarketing，以資料採礦（Data Mining）技術為基礎，藉著分析資料庫、資料倉儲等各種資料來源，產生產品差異化行銷分析，而且提供預測客戶購買行為的套裝功能。
UniMarketing的參考客戶以金融保險和百貨零售業為主，金融商品銷售需要掌握客戶的風險評估、信用評等、資產與貢獻度，以及利率額度分析；百貨零售業者應用的理由是販賣品項繁多，需要策畫特賣活動，寄送DM通知顧客，吸引人潮到賣場購物，需要準確的會員管理。
UniMarketing的分析流程
UniMarketing以Java開發，使用主從式架構，使用者透過網路連線，至伺服器端操作UniMarketing分析系統，也可以根據企業需求調整成應用伺服器的延伸架構，在資料分析前，須先匯入相關資料，轉換成具有資料綱要（Data Schema）的DSC檔，如果要進行有關購物習性的協銷分析和序銷分析，資料源需要再次轉換成二進位格式的BTF檔，以及用來對照產品代號、名稱的MAP檔。UniMarketing在用戶端程式的使用者介面，提供客戶價值和購物習性兩種分析資料準備的功能，作為系統資料分析的基礎。
資料匯入系統後，根據預設參數，會重新定義資料，區分出過濾欄位、新增欄位、資料取樣等系統欄位，產生成DSC格式的純文字資料物件，執行分析處理後，系統會建構對應的資料模型，將結果以圖表呈現。資料模型出爐後，接著可以進一步預測未來後續的新進資料將會歸屬的分類。
由於每一次分析處理的資料準備，需要的檔案通常包括資料源、DSC檔、BTF檔、MAP檔，因此分析處理以專案檔的方式囊括這些資料檔，方便管理，這些資料檔根據屬性不同，又分成系統資料共用區和使用者個人區，系統共用區是全體使用者共享的，擁有管理權限的人才能修改或新匯入資料到這個區域；使用者個人區的資料只能供登入使用者存取與管理，其他使用者無法檢視。與其他商業智慧系統相比，資料呈現與共享的權限控管方面相當有限，只有一般、進階和管理員3種，無法依照部門或群組控管資料權限，使用者少時，或許不需要控管得太仔細，如果應用在使用者眾多的大型企業，就會很需要與階層職務相關的資料或應用程式權限功能。
資料處理作業
外部資料匯入分成純文字檔和資料庫兩種處理方式，純文字檔的資料需要一定順序的排列，才能夠轉換成有意義的資料；資料庫的存取透過ODBC取得資料源連結，匯入功能可以支援資料表相互參照（Join）的處理，轉換成SQL指令執行，習慣SQL指令的使用者，可以在SQL視窗直接鍵入指令，執行資料庫處理。
匯入資料後，要進行資料準備，轉換成系統需要的各式檔案，UniMarketing特別提供「漏失值處理」的功能，在轉換過程中根據預先設定的資料值，自動補登錄，以便提高資料採礦的有效性。
分析作業的速度取決於資料量與處理能力，初期幾次使用之後，就可以確定例行的處理作業，UniMarketing的作業管理員提供分析工作排程與管理功能，即使想臨時中斷分析作業，可以從作業管理員中停止或暫停該項工作。
分析作業
分析作業設定時，除了初步呈現匯入後的資料，可以增加衍生欄位，增加資料呈現的彈性，並且支援記錄篩選的設定，只呈現使用者需要的區間資料或取樣資料。衍生欄位是指將某些欄位配合運算式或常數做特殊需求的處理，例如我們可以設定薪資除以小孩數目等於消費能力的公式，以便自動產生消費能力這個原先資料表沒有的欄位；記錄篩選可以設定區間資料，透過設定大於、小於等判斷式篩選特定欄位的資料。
客戶行為分析管理包括分群、行為與貢獻度分析，UniMarketing採用群集化（clustering）和分類（classification）的方法分析。分群可以將每一群的特徵整理後，根據這些屬性（例如性別、職業、居住地區）的密集程度，進行分群，歸納出現後，使得現有顧客與潛在顧客所屬的族群，能夠以聚焦的方式浮現，便於企業研擬相關行銷策略。行為分析會採用目標式客戶區隔分析法，記錄特定的消費習性（例如有些顧客特別熱中折價券、來店禮、高價精品），之後將客戶區隔（segmentation），以決策樹方式展開這些區隔，建立模型，操作者可以很清楚地看到每一群對象隨著階層的累積而持續遞增的各項特徵。貢獻度用量化屬性（例如消費金額與次數）作為分析目標，也採用目標區隔方式，用決策樹歸結出哪一群客戶的貢獻價值最高，提供操作者檢視推論分析出的資料因素。
購物習性分析可分成協銷（association）和序銷（sequential）的規則分析。商業智慧廠商經常會引用威名百貨（Wal-Mart）的例子，購物籃分析（market basket analysis）能夠找到顧客在週末同時購買啤酒與尿布的關聯性，這個例子正好也充分說明協銷和序銷的重要性。協銷是從相同時間的購物明細資料中，找出關聯程度最高的商品組合，適用在交叉銷售（Cross Selling）；序銷則可以長期分析顧客在不同時間購買產品的先後關係，會應用在向上銷售（Up Selling），目的也是找出關聯程度高的商品組合。
客戶價值分析UniMarketing提供期間、頻率、金額、客戶忠誠度（Customer Loyalty Value）的分析，以圖表方式呈現客戶流失的原因、來店頻率、累計消費金額，推算出顧客的忠誠度。期間分析透過計算客戶最後一次來店時間距離現在時間的長短，分出等級，企業可視顧客來店的周期區分顧客價值。頻率分析，是來店次數另一種計算方式，頻率越高，可能代表顧客的認同與滿意越高，假如發現顧客來店頻率明顯降低，能夠立即研擬對策，開始著手發現問題的根源。忠誠度會使用RFM數值法進行運算，RFM是指前次購物時間（Recency）、購物頻率（Frequency）、購買金額（Monetary）。
預測分析上述所有的分析作業背後皆會產生預測模型，根據預測的信賴度，可以只檢視信賴度高的分析結果。資料隨著每天的營運不斷增長，UniMarketing讓新進的資料也能用來驗證預測模型的準確度，在客戶行為分析預測的功能，提供Gain Chart、Lift Chart和Effect Gain三種圖表的檢視，作為參考。
目前的商業智慧絕大多數屬於歷史資料的分析，關於資料採礦領域的延伸，以資料分析技術為主的產品，也不一定熟悉各行業專屬領域的需求，UniMarketing的長處，在於功能很固定，而且具有與金融保險、百貨零售業者合作的經驗，操作上雖然不夠直覺，經過適當的教育訓練之後，可以很快上手，對中小型的金融與零售業相當適合。
Symantec AntiVirus升級之路
每年的4、5月，是許多軟體廠商推出新版本的時間，有人會立即將產品升級，有人會等幾個月後才有所行動，也有人無動於衷。希望藉由iThome的親身經驗，能協助你做出最佳的判斷。
從iThome電腦報周刊創刊之後，我們就建置防毒伺服器，由於它一直都很正常的運作，沒有出過什麼事（當機、中毒、系統毀損），所以我們也就抱持著「以不變應萬應」的想法，讓它陪伴我們至今。直到今年初，Symantec的LiveUpdate漏洞被發現，讓iThome重新檢視防毒架構。
該不該升級？
許多IT主管都是以不變應萬應，隨著事件發生而作出應變，但這樣的方式似乎弊多如利，倒不如先做好事前的預防工作，才能減少事後的修補工作。雖然廠商推出新版本是基於商業考量，但其中仍有不錯的部分，值得我們選購與升級。
以下是iThome此次升級Symantec AntiVirus 8.1的幾項考量因素：
成本：iThome原先是購買Norton AntiVirus 7.6企業版（7.x之前稱為Norton AntiVirus，8.0以後更名為Symantec AntiVirus），也是企業授權用戶，產品升級是權利之一，也不需要再花費額外的成本，若企業單買產品或未買升級授權，即可能要再支付一定的費用。另外，產品的軟硬體需求或許會提高，在升級前必須先更新軟硬體，也要額外付出成本。
新增功能：這應該是許多企業升級時的主要考量，以Symantec AntiVirus 8.x版為例，它跟原先7.x的架構相同，但支援更多的作業平臺、病毒碼採用累進式更新、掃描時間縮短、主動稽核網路、可針對不同部門設定不同的防護政策……。
在病毒碼方面，之前每天必須下載完整的病毒碼，但8.x版則是使用累進式更新，每天只要下載16kB的病毒碼即可，無形中減少許多網路負責擔。針對不同部門設定不同的防護政策也是不錯的功能，以iThome為例，雖然所有人都是由MIS負責設定，但技術編輯在測試時需要暫時關閉防毒系統，此功能可針對不同的群組（部門、使用者）制定不同的防護政策。
修補漏洞：許多新版本的應用程式是用來修補漏洞，像LiveUpdate 2.0、WinZip 9.0等，會消除原先的弱點或漏洞，雖然Symantec AntiVirus並沒有LiveUpdate的漏洞，但我們是從它開始升級計畫。有需要的使用者可到Symantec網站下載LiveUpdate 2.0中文版。
風險：有沒有風險存在？廠商給的答案是沒有，但我們在測試時就遇到一個狀況，因為Symantec AntiVirus 8.0的一個bug，執行排程掃描時，它會讓用戶端的處理器使用率高達99%，如果IT人員一時不察，那後果可想而知。另外，企業所使用的應用程式也可能與防毒系統相衝突，可能原因是使用相同的通訊埠或記憶體區塊，特別是本土廠商和企業自行開發的應用程式。所以，除了拿最新的版本進行測試，在升級前一定要先做好備份工作。
專家指導：專家一出手，便知有沒有。這次我們請到Symantec技術顧問林育民及銳傑科技系統工程部經理廖竣生，指導我們如何規畫系統架構、進行版本升級，並解答疑問。專家除了有較多的資源，經驗也比較豐富，能解決你所遭遇到的問題，例如上述的Symantec Antivirus 8.0問題，林育民只花了1分鐘就找到答案。
輕鬆升級無負擔
經過評估後，我們也開始著手準備系統升級。典型的Symantec AntiVirus有6個安裝步驟，從擬定安裝計畫、安裝Symantec System Center與主控臺元件、安裝Symantec AntiVirus伺服器、安裝Symantec AntiVirus用戶端、安裝Symantec隔離所及安裝Symantec AntiVirus Quarantine Console，最後兩項非必要。這些都可在Symantec網站找到。
銳傑科技提供幾個Symantec AntiVirus升級安裝的注意事項：
1.先了解企業內的作業系統及網路架構，並確認用戶端的系統需求符合要求。在升級前，管理者必須先檢查軟硬體是否合乎系統需求，特別是一些較舊的作業系統，不但作業系統廠商早已不支援，新的應用程式也可能無法支援，以Symantec AntiVirus 8.1為例，用戶端已經不支援Windows 95平臺。還好的是，Symantec AntiVirus 8.1能夠向下相容7.x版的用戶端，如果用戶端無法安裝8.x版，可以安裝7.6版，再由8.1版伺服器控管。
2.確認Windows NT/2000/XP/2003的使用者具備本機管理員權限。
3.防毒伺服器避免與郵件伺服器和資料庫伺服器安裝在同一臺機器上。因為郵件伺服器（Exchange和Notes）會接收到病毒信，可能會與防毒系統產生衝突；資料庫主機則有可能與Symantec AntiVirus本身的資料庫相衝突。
4.防毒伺服器避免安裝兩片（含）以上的網路卡。
5.防毒伺服器最好設定固定IP，並能透過DNS解析該伺服器，以方便用戶端由外部或跨網域連結。
6.若由Norton AntiVirus 7.x升級時，建議先移除再安裝Symantec AntiVirus 8.x，以便後續的管理。
7.在安裝防毒軟體時，有一個重要的注意事項，那就是關掉所有的程式，特別是Office軟體。
除了以上的注意事項，我們考量到幾個問題，經過專家的解答後，提出來與你分享：
原機升級或新機升級：由於iThome的員工人數並不多，所以廖竣生建議原機升級即可，但若企業的規模較大，或有擴編的打算，則要考量原先的伺服器是否能夠負擔。Symantec System Center、主控臺元件及Symantec AntiVirus伺服器可以安裝在同一臺伺服器上。
用戶端升級：如果要到每一臺機器前執行安裝，那MIS人員可能會抓狂。Symantec AntiVirus有5種用戶端安裝方式，包括Login Script、Web Install、Symantec System Center派送、Packager派送（MSI 2.0）及光碟安裝，除了最後一種，其他的方式都可以從遠端進行安裝。廖竣生表示，Login Script是最快也最簡單的安裝方式。如果該用戶已經安裝個人版防毒軟體，最好先手動移除再安裝用戶端軟體。
所佔硬碟空間與系統資源：通常新的應用程式會佔用較多的硬碟空間與系統資源，但由於8.x版的病毒碼處理方式不同，所以佔的硬碟空間反而比較少，林育民表示，7.x版約佔50MB、8.x版約34.6MB（拿掉Windows 3.1版的程式碼），即將上市的9.0版則只佔18.2MB；在系統資源方面，管理者可從主控臺調整，系統預設的掃描優先權是3，最高則為13，如果制定得過高，可能會影響到系統的整體效能。
備分與還原：新版本的功能增加，設定選項也越來越複雜，建議做好系統備分工作，以方便日後的還原。目前系統設定只能採用手動備份與還原，由使用者手動備分系統的機碼。
專業的顧問服務價值不斐
林育民表示，Symantec完整的防毒系統導入過程包含5個階段，從最初的評估環境、規畫、移除既有的解決方案、測試安裝（Pilot Test，在企業的真實環境進行測試）、執行及教育訓練。但原廠的顧問服務價格較高，臺灣大多由合作夥伴提供顧問諮詢服務，所以，iThome是向銳傑購買產品及授權，並提供相關的售後服務。
銳傑在協助企業進行建置時，也是遵循Symantec的規範，包括系統架構說明、安裝平臺確認、測試方式與移除方式、測試行程規畫及測試注意事項等內容。安裝過程約需1天，測試與訓練約7~14天。最後，在兩位專家的協助之下，iThome順利升級到Symantec AntiVirus 8.1。
後記
在iThome 3年的時間，筆者收到無數的病毒信，開過無數病毒檔，但從沒有感染過病毒，這完全歸功於防毒系統（把駭客工具隔離除外），但有些人未遵守公司的安全政策，可就沒這麼幸運了。
防毒仍是企業最大的困擾之一，加上病毒和蠕蟲發病的時間越來越短，除了制訂良好的安全政策，還要經過良好的規畫與建置，才能發揮防毒系統的最大功效。
SOA面面觀
SOA不是新的概念，卻因為Web Services的出現，舊瓶裝新酒而成了當紅炸子雞。然而，用得好，不如用得巧，雖然Web Services是平價的解決方案，卻不是萬靈丹，用對地方才能發揮SOA的效益。若盲目地「為Web Services而Web Services」的話，可有排頭吃了。
近兩年來SOA（Service-Oriented Architecture；服務導向的架構）是被資訊產業喊得震天價響的當紅炸子雞，事實上，SOA並不是新的概念，早在十幾年前DCOM及CORBA規格中的ORBs（Object Request Brokers）即SOA的應用。Gartner預計，到2006年將有超過 60%的企業，會考慮以SOA作為建立關鍵業務應用的基本原則。SOA及SODA（Service-Oriented Development of Application；服務導向的軟體開發模式）在未來幾年將逐漸成為主流。
Web之所以大行其道，鬆散藕合是關鍵
網際網路最初是為了分享學術及科學上的研究成果，第一份HTML網頁是由單純的文字與超連結組成，不久之後，內含圖形與其他多媒體資料的能力，很快地就被加到視覺化的Web身上。瀏覽器讓網際網路在短短幾年間，成為橫跨全球的資料庫。
然而，對企業而言，重要的商業資訊都儲存於資料庫而非文件中，隨著時間的演進，維護大量的靜態HTML網頁，將成為繁瑣的任務。因此CGI、ASP、JSP等動態網頁技術應運而生，網站成了資料查詢、線上交易等服務的提供者，開始執行應用程式的任務。當任務變得愈來愈重要，便出現新一代的中介軟體－應用伺服器，介於前端表現層及後端資訊系統之間，兼顧安全性、穩定性、可用性、延展性及效能等各方面要求，擔任執行商業邏輯的角色。
網際網路之所以成功，BEA技術經理蕭百齡認為：「遵循開放標準，帶來鬆散藕合（Loose Coupling）的模式是最重要的關鍵。」然而網路的應用必須依賴瀏覽器，又顯得被僵化地限制，因此人們開始思考更中立的方式，讓消費端可自行決定如何處理及呈現服務端所提供的資訊。
XML就是在這樣的時空背景下產生的技術，目的在於提供一個精準描述資料的機制，以彌補HTML太過著重資料呈現的特質。Web Services讓服務端提供的資訊，除了瀏覽器外，手機、IA家電、其他伺服器上的服務，甚至辦公室文書軟體都成了潛在的資訊消費者。
業務導向的組裝式系統
傳統應用導向開發的軟體，試圖在各個領域提供解決方案，產生ERP、CRM、SCM及PLM等，獨立、訊息不交流且難以整合的系統。然而量身訂作自行建置的成本過高，因此企業多選擇套裝的解決方案，再自行加以客製化。然而由於套裝系統的架構僵硬，缺乏變動的彈性，往往是使用者屈就系統功能，而非系統配合使用者的習慣，這也是導入系統時，容易遭遇使用者因習慣改變而反彈的原因。
「開發即整合，整合即開發」是SOA的新思維，顛覆傳統應用導向的思維，強調的「服務」是以業務為主軸，提供各項資訊基本應用功能，以拉近資訊系統與業務之間的距離，而著眼於貫穿資訊孤島，提供可排列組合的各項服務。
將系統功能模組轉換成各種服務後，透過BPM橫向貫穿ERP、CRM、SCM及PLM等，企業對內和對外各種系統，串連服務成為請採購等各類商業流程。未來業務需求或商業流程改變時，將保有調整的最佳彈性。
SODA也確保應用系統以先天即能互相整合的方式來設計，讓企業所開發的新應用系統能輕易地與其他系統整合，迅速藉由新的或現有的「服務」來建立組合式的應用系統，並賦予因應未來整合所需要的彈性。
臺灣IBM公司軟體事業處商業整合產品專員董俊賢說明：「SOA類似硬體IC的概念，再透過流程串連各種服務，組合成解決方案。」過去軟體設計無法實現IC模組的概念，是因為各家使用專屬的技術及規格，使得模組受到特定技術的箝制；而今在開放標準下，整合不再是夢想。
Services未必是Web 「Services」
要建構有效的SOA，必須先清楚了解「Service」這個專有名詞的意義，Service是一個定義明確且獨立運作的功能，且與其他Services的內容及狀態沒有相依性。
董俊賢強調：「SOA是架構性的概念，不能窄化SOA的定義，Services指的並不一定是Web Services。」Services是物件導向的延伸，過去SmallTalk、CORBA到後來微軟的DCOM及J2EE的EJB和JavaBean等都是SOA的應用。由於使用專屬的語言，所以無法互通，直到Web Services的出現，才露出整合的曙光。
DCOM是微軟執行遠端呼叫的專屬機制，雖然與Web Services同樣是跨語言的技術，卻僅支援Visual C++、Visual Basic及C#等語言，受到微軟平臺的綑綁，便限制了應用範圍。最新的.NET Remoting也是.NET平臺SOA的應用，但也僅限於.NET平臺。
事實上，CORBA與Web Services類似，擁有跨平臺及程式語言能力，且成熟度較高，但必須付出較高的學習成本。CORBA仰賴IDL解譯資料，但一般人難以理解IDL的內容，開發人員必須學習IDL，困難度因而成為阻礙發展的金箍咒，影響市場的接受度。相較之下Web Services的XML可讀性高，且多數開發Web Services的工具均可自動產生WSDL。再加上CORBA的架構必須在每個用戶端安裝IDL的解譯器，所以只適合企業內部網路的應用。
SOA大放異彩的原因，與XML及Web Services的成熟有絕對的關係，由於遵循開放標準，而帶來鬆散藕合的架構，SOA的架構將不再受到特定技術或產品緊密的綑綁。
BPM是串連服務的神經系統
在SOA的架構中，BPM（Business Process Management；企業流程管理）扮演串連各種服務形成企業流程或資訊流的角色，也可說是流程管理的解決方案，由流程模型建置、流程分析、流程模擬、流程執行、流程監控及流程管理等功能組成。但實現BPM未必需要搭配BPM產品，董俊賢強調：「BPM這個專有名詞，是為解決整合的問題而提出的概念，並非產品。」傳統以紙本傳遞，或土法煉鋼撰寫程式的方法，也是BPM的作法。套裝化BPM產品的目的，是為減少撰寫程式的負擔，並降低維護與管理的成本。
BPM若要成為SOA架構中，串連服務的神經系統，除了要支援Web Services，及提供連接既有系統的配接器之外，還必須使用相同的標準，BPM產品才有互通的可能。在戰國時代百家爭鳴的標準中，OASIS的BPEL是大家認為比較可能成為主流的標準。
不過企業仍然存有疑慮，即使各家BPM產品都支援BPEL，然而會不會上演類似J2EE的情況，在標準之外加入專屬的規格，因而破壞了相容性。蕭百齡表示：「各廠商或許有提供額外加值的功能，但最基本的相容性可以透過認證，確保跨BPM產品對 BPEL 格式匯出/匯入的相容性。」這就類似現在WS-I推的Basic Profile觀念，只要遵循指導方針，即可以產業標準為基礎，開發及建置具互通性的BPEL格式。
另一個擔憂是使用BPEL與合作夥伴串接流程，會不會洩露內部流程？事實上，只要遵循建置B2B流程的最佳實作，訂定Public和Private Processes，內部與外部的介面是完全隔開的。
SOA的好處
開發軟體時，建置健全的服務層，將帶來更好的投資報酬率。每個Service對應到明確的商業領域，當系統產生新的需求時，只需開發新的元件提供額外的服務。由於各項服務擁有明確的獨立性，所以其生命周期很有可能比最初的系統還長久。
SOA的Services位置必須透明，應用程式將Services以目錄管理，在執行階段才動態結合在一起。這樣的特性促使更好的延展性，因為負載平衡機制可在不知道Services用戶端的情況下，轉送要求到多個Instance。也因為這樣的透明度，可以在多臺伺服器的Instance建立相同的Services，如果部分網路或某臺伺服器出現問題，使用者的要求可重新指派到其他伺服器的Services，使得系統擁有更好的穩定性。
既然Services存放位置的透明度是SOA的特性，程式可攜性即可實現。用戶端無需在意服務的所在地點，因此企業可彈性地移動服務到不同的地方，甚至提供合作夥伴或客戶使用。
SOA促使應用程式分為多層式的架構，每一層都有專門的技術，開發人員將專業分工，負責應用程式不同部分。企業得利於不再過度仰賴高成本的獨門人才，可使用經驗較少的大眾人才。
以單一或主從架構建置系統，安全機制一般由前端處理，企業甚至沒有導入資料庫的安全控管機制，因為管理多重的安全機制太過困難。而一個服務可能提供多個應用程式使用，因此有獨立完整的安全機制，應用程式將有用戶端及服務端的雙重認證，可強化安全性。
Services有公開的介面可方便執行單元測試，開發人員可使用工具製作測試案例，以確認Services的獨立性可被任何應用程式使用。除錯是軟體考古學中相當困難的任務，藉由將商業邏輯集中於Services層，系統的可維護性將大幅提升，因為開發人員將更容易找到及更正錯誤的部分。
完整的測試通常意謂著更少的缺失及更好的品質。開發人員將逐漸建構一系列有用Services，企業將了解這些Services是可再利用資產，可以各種方式組裝，新的應用程式將因此而更快被開發出來。
程式碼的再利用是最常被討論的議題，然而由於程式語言及平臺的不相容，一直很難達成這個理想。元件及Services比較容易被再利用，開發人員不需要再煩惱編譯器的版本、平臺或其他可能影響的因素。
多層式的架構也代表可獨立作業，只要在專案開始時建立好介面溝通的契約，各層的開發人員可同時進行自各的開發工作，縮短開發時程。
.NET與Java在SOA方面的表現
微軟在Windows Server 2003上市的同時，也結合.NET Framework、IIS 6.0及Visual Studio .NET提出「應用伺服器」的解決方案。Visual Studio .NET是相當方便的Web Services開發工具，並強調獨門的C#及VB.NET語法簡捷且API完整，可強化開發導入的速度。在未來以Web Services為基礎開發的Longhorn作業系統，搭配.NET的Whitehorse及Indigo新套件，將提供更有效率的Web Services開發環境。
BEA WebLogic 8.1以應用伺服器為基礎平臺，結合Portal伺服器提供更好的使用者經驗；資料的彙整與管理也是重要的問題，Liquid Data是EII（Enterprise Information Integration；企業資料整合）解決方案，企業可透過標準XML查詢資料；企業內部與外部合作夥伴應用程式的整合，可透過BEA Integration Framework，以BPM、B2Bi及EAI解決方案完成。
過去WebLogic必須搭配Borland JBuilder，才能開發Web Services。WebLogic Workshop則是所有解決方案共同的開發平臺，自從前年推出第一代以來，被許多分析機構評為最簡單的Web Services開發工具。BEA認為J2EE就像DOS一樣，很重要卻也很枯燥，微軟的Windows作業系統之所以起飛的原因，就是因為高階圖形化的介面。不是每個人都需要學DOS，也不是每個人都需要了解艱澀難懂的J2EE，WorkShop即提供簡單容易使用的圖形使用者介面，即使一般使用者，也可利用WorkShop開發Web Services、設計Portal及組裝流程。
IBM則基於SOA整個架構，針對企業在資源整合方面，提出ESB （Enterprise Services Bus）架構，以提供企業在導入SOA架構時方便管理及提升效率的基礎架構。 在ESB下提供企業內部或外部不論在企業流程、資料或系統，透過企業入口網站、B2B或 Web Services加以整合。
IBM從2003年起開始將其相關的產品都加以提升支援ESB架構。在基於J2EE 架構WebSphere應用伺服器建構解決方案，MQ及WBI Borkers負責BPM的部分，再搭配入口網站伺服器、Web Services應用機制、WebSphere Business Integration為流程整合、DB2 Information Integrator是即時異質資料庫整合機制，及WebShpere Business Integration Adapters為B2B的配接器。
對於企業既有的系統，Siebel、SAP及Oracle等ERP系統目前都已支援Web Services，多數應用伺服器及BPM工具均提供配接器（Adapter），至於自行開發的系統，由於開發工具普遍支援Web Services，只要有繼續維護，都可透過工具將元件轉換成Web Services。
SOA對EDI與EAI的影響
過去企業透過EDI（Electronic Data Interchange；電子資料交換），運用協定的標準與資料格式，經電子化傳遞方式，與合作夥伴及客戶交換訊息。以EAI（Enterprise Application Integration）整合內部的系統，減少重複輸入的機會。當SOA出現後，對EDI及EAI會造成什麼樣的衝擊？
蕭百齡認為：「SOA 的精髓不是在取代什麼，而是要整合。」既有的EDI、EAI方式，及大型主機或ERP系統會繼續存在，但可以整合在SOA的架構之下。SOA可說是解決EAI課題的新方法，可取代舊式做法，而改以開放標準的Web services為溝通協定。董俊賢也表示:「SOA只是實作EDI及EAI的一種新的作法。」
臺灣微軟.NET顧問經理李啟後表示：「以SOA的架構串連企業應用程式，相較於傳統EAI的技術，是比較經濟的作法。」隨著時間的演進，SOA所帶來的好處與價值，將超越傳統EAI投資。BEA則認為：「SOA是EAI的進一步應用，若一開始就考慮SOA，未來就沒有整合的問題，而是彈性組裝的系統。」傳統EAI整合各自獨立的系統難度高，往往需要藉助顧問服務，導致成本太高。SOA可減少建置與維護的門檻，降低專業工匠的需求，提高效率並降低成本。
不過，Borland資深產品經理李匡正分析：「SOA很有機會取代傳統EDI的作法，但在EAI方面SOA並不是萬靈丹。」過去EDI建置的成本太高，無法普及到下游的廠商；而SOA是平價的EDI，且內建支援的開發工具較多，所以很有機會取代EDI。不過EAI屬於企業內部的資訊整合，是相當專業的領域，雖然SOA是低成本的EAI解決方案，但由於Web Services效能較差，除非是時效性要求不嚴苛的系統，否則Web Services的SOA架構不見得是最佳的解決方案。
SOA的關鍵原則
Web Services雖是最新SOA架構應用的實作，但正確的設計觀念與周詳的導入規畫才是SOA的關鍵。掌握使用Web Services的技巧，才能發揮潛在的價值，否則將適得其反。蕭百齡表示：「在實作和設計上必須把握關鍵原則：鬆散藕合和正確的顆粒大小。」
鬆散藕合白話文的意思就是立場中立，Web Services是異質系統溝通的介面，為避免被專屬技術緊密綑綁，或單方面調整時會衝擊雙方的溝通，介面要越中立越好。此外，中立的介面也進一步提升重複使用的機率，讓資源可以共享，增加開發的價值。
顆粒大小也是抽象的概念，SOA強調業務導向，與過去設計函式（Function）或方法（Method）小顆粒的作法不同，在設計上XML傳遞的資料內容，應朝向設計業務上有意義的單元。
由於適用Web Services的範圍、介面的長相及所謂顆粒大小的問題，是一門學問，而企業對SOA及Web Services的應用，目前並沒有清楚的概念與足夠的實際經驗，為避免「為Web Services而Web Services」，企業可能會尋求顧問服務。不過蕭百齡認為：「採用SOA架構，中大型企業會得利最多。」所以企業應不假外求，培養內部的建築師，組成專業的規畫團隊與業務單位充分溝通，才能有效降低專案失敗的機率。
用對地方才能發揮效益
根據Gartner Group的調查分析，J2EE將逐漸取代CORBA，這不代表CORBA就此消失，因為J2EE的規格中包含CORBA的架構，所以也可以說J2EE延續CORBA的應用；COM及COM+將逐漸由.NET取代，而.NET及J2EE的互通即透過Web Services。事實上，CORBA、DCOM也均有存在的價值，未來將存在於企業內部；Web Services則善長網際網路的溝通。
SOA舊瓶裝新酒，在近兩年成為當紅的技術名詞，無非是與Web Services的崛起有關，雖然Web Services目前仍不算成熟，不過以其公開標準、跨平臺、成本低廉及鬆散藕合的特性，將是促成SOA引領風騷的主因。
李啟後表示:「臺灣敏感的經濟型態，隨著全球趨勢脈動，企業特別需要SOA的架構，以因應靈活變動的需求。」企業的資訊系統需要更靈活的架構，以因應瞬息萬變的需求，才能發揮展現IT的價值。
不過，一窩蜂的趕流行，可能勞民傷財也不見得有好的效果。Web Services不是萬靈丹，用在對的地方才能發揮真正的效益，蕭百齡認為：「單一系統或語言的溝通，Web Services不見得是最好的候選人；跨企業、系統或程式語言的交流，Web Services便是優先考量。」當然企業也不能忽略效能問題，效能要求嚴苛的系統，可考慮其他解決方案。
ERP市場山雨欲來風滿樓？
和本土和外商亦敵亦友，微軟商用軟體吹皺一池春水，重兵群集中小企業，下半年戰火開打
面對微軟商用軟體ERP和CRM即將到來的威脅，多數本土商用軟體業者皆嚴陣以待，外商的態度雖老神在在，穩坐中大型市場寶座，從過去微軟在各應用軟體領域的「成功經驗」，以及市場資源的豐沛，大家也不得不擔心微軟從中小企業向上攻的可能性。多數業者認為，微軟商用軟體對臺灣市場會產生非常大的衝擊。
通用型ERP緊張，漢康老神在在
企業資源規畫（Enerprise Resource Planning，簡稱ERP）由物料管理（MRP）、生產、行銷、財務、人力資源等模組組成，已經是企業必備的資料處理系統之一，歷經20多年的發展，只要有其中一項產品就可稱為ERP廠商的數量多達數十家，產品重複性相當高，由於臺灣市場較小，每個ERP公司規模都不大。
漢康總經理吳金城指出，ERP可粗分成兩大類型，一種是依照行業別生態開發的解決方案，另外一種為適用於各種產業的通用型ERP，多數廠商開發的產品屬於後者。這類產品普及速度快，能獲取較高的利潤，但能提供的客製化程度低，客戶滿意度相對也不高。「微軟招牌太大，對市場影響一定很大，尤其是提供通用型ERP的廠商。」
吳金城說：「4到5年前，我們開始針對特定行業，深入研究和開發該行業別中不同類別的業務項目和流程，包括鞋業、紡織業、PCB光電、金屬加工、機械等。因此面對的市場競爭壓力較小，有特定的客源，收入來源也穩定，但不像通用型ERP以量取勝。」
ERP逐漸成熟，近幾年無論在技術或市場面新陳代謝速度緩慢，才有ERP已死之說。鉅茂專案經理呂婉玲說，這兩年ERP市場都起不來，微軟能入注新的想法，引進微軟的ERP或CRM產品，對臺灣商用軟體市場生態會有正面的刺激，尤其在功能和服務方面注入新氣象，可帶來新的商機。
ERP客戶家數居冠的鼎新則仍在觀察市場變化，對此並未做進一步回應。面對即將到來的殺戮戰場，鼎新日前進行組織調整，改過去產品別之分，依照產業別分成製造業、流通買賣業、金融及服務業、政府等部門。去年成績逆勢成長，表現超越前年，主要收入來自從ERP轉型到ERP II的整合服務市場。
昔日伙伴可能是今日敵人
思愛普和微軟原本是最佳的合作伙伴，然而，微軟併購位於歐洲的Great Plains和Navision，企圖將其商用軟體市場策略改從歐洲打回美國，讓這位德國商用軟體大廠心生戒心。除了針對中小企業流程需求的軟體外，Navision也提供大型製造業ERP方案，其產品在歐洲佔有率為3％，思愛普為37％，兩者相差甚鉅，但微軟的力量則不可小覷。
目前思愛普尚未在臺灣推中小企業套裝軟體SAP Business One，尚在評估是否今年推出。思愛普的Business One和微軟Navision ERP在歐洲中小企業市場正面廝殺。
思愛普解決方案服務伙伴之一、東捷資訊事業營運中心執行副總蔡正忠說，微軟看的是營業額1到5億元的企業，思愛普目標為營業額5到15億元的大型企業，需要嚴謹的客製工程，因應外在環境的變化。東捷以營運東元集團ERP的經驗，成為思愛普導入服務業務的合作伙伴，今年目標拿下非東元集團客戶6到8個。
和其他競爭產品的差異，蔡忠正指出，思愛普商用軟體架在業務流程平臺上，開發出來的ERP、CRM或SCM為業務導向的解決方案，其他競爭廠商的產品為功能導向的架構，修改彈性小，新的應用在既有軟體上疊床架屋，系統會相當複雜。「多數本土廠商和競爭對手的客戶都會面臨類似的問題，尤其是有多角貿易或兩岸三地運籌需求的企業。」
整合學問大，家家有本難唸的經
對於微軟的商用軟體強調功能多樣和快速導入的特點，甲骨文加值服務商前進國際總經理簡添勇認為：「拼100片和拼1000片，不是只有10倍的差距，每個模組之間的連動性和階層是次方的差距。整合學問大，大家解決的問題都不一樣。」他認為微軟的產品對本土ERP廠商影響較大，尚未影響到中大型企業這一塊。
除了平臺的客製化彈性外，顧問扮演專案成敗的關鍵角色。簡添勇強調：「顧問事業要長長久久，做10到15年才能和其他競爭者拉大距離。」他認為，今年ERP市場會比去年熱，而大者恆大的態勢會更明顯。
臺灣廠商西進潮將持續進行。和其他廠商一樣，漢康和前進國際都在考慮和大陸當地廠商合資，陸資企業才有機會拓展內陸市場。簡添勇說：「延續前幾年的西進潮，兩岸三地的整合系統需求升高。多數本土廠商的系統多因此受到侷限，汰換或升級的客戶不少。」
另外，因為仁科和J.D. Edwards正在進行組織合併，臺灣仁科總經理莊英俊對此不便發言。
目前Navision解決方案的導入服務是由港商瀚思資訊提供，臺灣微軟從去年也開始走訪伙伴和客戶端，查探民情。由於ERP市場幾近飽和，多數微軟合作廠商看到CRM的商機。另外，微軟認為，本土廠商5到6年前開發的產品，也慢慢要轉到.NET平臺，由於轉換成本高，多半影響更新意願。微軟承諾，以該平臺為基礎，將給予伙伴相關的技術服務和訓練，而合作伙伴專注於行業別的產業知識。
微軟和本土伙伴唇齒相依
微軟去年商用軟體收入有6億美元，到2010年目標100億美元，MIC資深分析師周樹林說，微軟進軍商用軟體市場的企圖，從2年前其併購Great Plains、Navision等廠商就可以看出端倪。然而，商用軟體和當地產業應用有密切相關，其中財會等模組也需要大量的本土化工程，微軟必須和本土加值經銷商（VAR）或顧問服務提供者合作，才會有機會。
根據MIC調查，2003年臺灣IT服務市場規模約1429億元，預估2004年達1500億元，將比去年成長5％，其中資訊安全解決方案佔比例仍是第一，去年成長率為28％，預估今年成長率達27％，電子商業應用成長幅度達12％。
大型企業自行建置比例高
根據MIC的調查，臺灣大型企業自行建置的比例偏高，若以家數來看，以鼎新平臺為基礎的比例最高，第二為甲骨文，第三才為思愛普，SCM排行第一也是鼎新，第二名才是i2，第三名是思愛普。而今年商用軟體市場的明星產品將是商業智慧，受訪的大企業中多數是採用微軟的BI，第二名為甲骨文，再者為IBM。
其中，有三分之一的企業自行開發ERP，自行開發SCM的企業比例高達54.3％，自行開發CRM的更高，比例為62.2％。周樹林指出，基於客製化需求、集團效益和資安考量，大企業寧願讓自己的資訊部門，擔任導入應用軟體的工作。
相較於全球大環境呈現衰退的數字，周樹林說，臺灣企業對於IT的投資仍非常積極，尤其是ERP或CRM等系統，若以2003年臺灣一千大企業來看，ERP普及率幾乎達飽和程度，其中有3成為自行開發；一千大企業中導入CRM的比例約68％，銷售排行前三名為Siebel、甲骨文和思愛普，預估到2006年普及率將高達77％。
除了ERP和CRM外，微軟還有支援企業營運面的工具軟體，包括SQL Server的線上分析程序（OLAP）、商業智慧（BI）工具等，這些產品強調簡單易用和價格低廉，受到不少企業歡迎，「微軟企業端產品整合起來的資源是相當驚人的。」周樹林強調：「現在微軟攻中小企業市場，其實距離中大型企業市場就不遠了。」
資料倉儲的類型
資料倉儲通常用作資料採礦、商業智慧，能夠包山包海，也可以處理單一主題
近年來企業e化已經不限於關心流程是否順暢，交易記錄完整儲存等單一系統的議題，往往更在意異質資訊系統間的整合，如何有效彙整與呈現資料，對企業營運效率的影響越來越具體。資料倉儲（Data Warehouse）的概念，即是引用倉庫儲存的概念，不僅儲存實體的原物料與成品，在資訊系統上也能夠將抽象的檔案資料統整，而且轉換成實體的資料倉儲。
資料庫、資料倉儲、資料倉儲系統的區別
資料倉儲是儲存大量資料的資料庫，與資料庫卻不盡然相同。資料庫儲存的資料與營運（Operation）相關，資料倉儲會在資料累積一段時間後，再整理、移轉至另一個資料系統中作資料分析。資料倉儲通常指的是儲存整合後資料的資料庫，資料倉儲系統則泛指整個決策輔助系統，包括系統的軟硬體、資料與報表。
「資料倉儲」這個名詞在西元1990年由Bill Inmon所創造出來的，因此被喻為資料倉儲之父，在「What is a Data Warehouse」書中，他認為資料倉儲的資料收集，有4種特性：主題導向的（subject-oriented）、經過整合的（integrated）、依循時間變動的（time-variant）、不會流失的（non-volatile），根據這些特性，使資料倉儲能夠將資料提供給決策管理系統進行處理。另一位資料倉儲的代表性人物Ralph Kimball，在「The Data Warehouse Toolkit」一書中認為，資料倉儲是一種經過結構化，可以查詢和分析的交易資料副本。
「主題導向」是說資料倉儲可以集中與特定主題相關的資訊，而不只是公司目前的營運資訊；「經過整合」是指存放在資料倉儲的資料是從不同的來源合併，並且維持一貫有條理；「依循時間變動」說明資料倉儲以特定的時間點辨識儲存的資料；「不會流失」則是表示資料倉儲中的資料只會持續增加，不會被移除，這能夠使管理階層得到企業商務持續性的觀察。
資料倉儲的類型
資料倉儲可分成企業資料倉儲（EDW）、操作型資料商店（Operational Data Store）和資料市集（Data Mart）。有的人又認為資料倉儲除了企業資料倉儲和資料市集外，還可以加上虛擬資料倉儲（Virtual Data Warehouse）、混合式倉儲（Hybrid Data Warehouse）。
企業資料倉儲。企業資料倉儲包含整個企業的資訊，由數個主題組成，例如客戶、產品、業務等面向，能夠用在決策支援，有即時資訊，也有彙總過的資訊。
操作型資料商店。「操作」，是相對於資料倉儲的資訊性而言，ODS提供明細資料，特別是經過統整的近期資料，能夠供應即時報表的需求，作業型資料商店只能分析很近期內的資料，無法分析較長期的歷史資料。Bill Inmon在1995年發表的「The Operational Data Store」他認為ODS的資料集合是主題導向的、經過整合的，不過與資料倉儲不同之處在於，ODS的資料會流失，以當下的數值為主，不含歷史與累計資料，而且ODS資料能夠做到即時的整合性蒐集。ODS根據資料同步更新的頻率，將資料的轉送與儲存時程也有等級之分。
資料市集。與資料倉儲的定義大致相同，資料倉儲涵蓋整個公司的資料與人員，而資料市集只包含特定範圍的資料，而且使用者會鎖定某一個工作群組的人員。一組資料市集可以組成一個企業資料倉儲，反之亦然。假設一個公司採取數個資料超市同時存在的模式，在定義相同維度的資料時發生歧異的狀況，將會使資料市集變成資料孤島（Data Island）。資料孤島對企業整體而言有很大的問題，整合的功用只限於部門群組，無法擴及整體資訊的統合，跨部門的資料分析無法進行，不同工作屬性無法連結的狀況下，如果有不同的跨部門資料分析，以往資料市集架構只能繼續以疊床架屋的方式累加，無法整合。
現今資料倉儲的建置，仍以資料市集開始居多，因為資料市集採用的維度模式比起個體關係模式容易理解，而且分析速度較快，不過仍應視企業與使用者的需求而定。
虛擬資料倉儲。企業直接使用現有營運的資料庫，並輔助一些中介工具，進行有效資料處理，建構較快速，成功的機會高，可做到即時資料分析。
混合式資料倉儲。資料市集如果以虛擬資料倉儲的方式表現，就變成混合式資料倉儲。需要的儲存空間比起企業資料倉儲少，由於資料已經儲存在一個經過正規化的資料環境，資料重組的過程會比透過應用程式讀取執行中的資料來得簡單，而且也不會影響執行中的資料庫。混合式資料倉儲也能夠應付資料市集遭遇到的資料孤島現象，透過虛擬的方式能夠彈性對應不同的需求。
資料倉儲的好處
資料倉儲可以做到跨資料來源的整合，使不同資料庫的資料彼此對應連結。資訊系統的建置，固然解決了資料定時產出與立即儲存的需求，一旦企業想要從資訊系統擷取經過整合後的各式統計資訊，立即面臨到資料來源不同的問題，無法跨系統同時存取，並且無法進一步自動化加工處理分析，資料倉儲可以視為提取資料的單一窗口，透過資訊系統自動化的轉換，以減少人工交換檔案出錯的可能性。
資料倉儲的發展，初期的僅需要總合資料的檢視，之後每一筆交易資料也開始保留在資料倉儲，以便分析客層與產品之間的關係。目前除了儲存總合資料和交易資料，也保留明細資料，分析顧客的購物。
這樣的歷史進程說明，企業過去只是想知道總營業額，現在則更關切顧客如何在交易流程做出選擇。
資料倉儲常會與資料採礦、商業智慧相提並論，當運用在行銷業務時，可以用來了解顧客習性，讓企業能夠預測顧客行為，以便進行適合的促銷；在企業內部，資料倉儲可以用在內部營運情形的評估，讓高階主管從具體的資料證據，找出營運狀況不佳的癥結點。
技術新知 -Samba 3.0增強網路整合管理功能
在Unix平臺上享有盛名的Samba於去年陸續推出3.0.x系列，能夠有效整合多種異質平臺的檔案共享功能，並增強企業內部網路的管理功能。Samba伺服器是許多儲存廠商在建置時的選擇，除了可以有效降低開發成本外，操作介面簡易，功能強大是頗受青睞的原因。
Samba 3.0系列依然保有這些優勢，並且加入了許多新功能，可作為AD網域的備分網域控制器（BDC）是其中最受人矚目的功能。
在之前的版本中，Samba伺服器雖然可以作為主要網域控制器或加入AD網域，但不是必須更改網路架構，就是沒有足夠的權限可以管理，必須重新建立帳號密碼才能使用。
3.0改版之後，就可藉由LDAP協定，向主要網域控制器（PDC）送出確認帳號密碼的要求，有效地整合網路環境，解決在同一網域中還需要多組帳號密碼的煩惱；除了可以融入Windows網路環境外，3.0還可以備分PDC中的帳號密碼，避免因為各種突發原因無法連線PDC而造成網域失常的問題。
以往Samba伺服器最讓人難以親近的就是管理複雜度，所有的設定檔都必須藉由文字介面完成，對現在的管理人員而言，是相當費時且複雜的事情，在3.0版中，搭配了新的SWAT，可以更快速且簡單地設定完成。
我們使用FreeBSD 5.1作業系統安裝Samba 3.0.1，並安裝相關套件，讓Samba伺服器可與AD網域整合，另外以一臺Windows Server 2003作為主要網域控制器。
安裝完Samba伺服器之後，網域中並不會馬上出現這臺伺服器，必須使用具備網域管理員權限的帳號加入該臺伺服器，才能順利讓伺服器登入網域，並且備份所有AD中的帳號資料。就整體架構而言，只有初次使用時較為麻煩，之後的設定就會相當簡易。
就網域管理而言，Samba的介面親和力不如Windows，但Samba的控管能力較好，可說是各佔勝場；在檔案伺服器這項主要功能而言，Windows Server 2003的效能就較佔劣勢，或許經過調校過的Windows Storage Server 2003就會有不同的效能表現了。