企業(yè)系統(tǒng)整合解決方案20140826_第1頁
企業(yè)系統(tǒng)整合解決方案20140826_第2頁
企業(yè)系統(tǒng)整合解決方案20140826_第3頁
企業(yè)系統(tǒng)整合解決方案20140826_第4頁
企業(yè)系統(tǒng)整合解決方案20140826_第5頁
已閱讀5頁,還剩32頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、企業(yè)系統(tǒng)整合解決方案一種基于企業(yè)私有云計算技術的系統(tǒng)整合解決方案數(shù)據(jù)整合還是業(yè)務整合?系統(tǒng)整合的出發(fā)點:統(tǒng)一入口Portal?數(shù)據(jù)統(tǒng)一?統(tǒng)一決策分析?問題跟蹤?資源共享?跨系統(tǒng)業(yè)務更新(數(shù)量大小)?系統(tǒng)A系統(tǒng)B當今的企業(yè)架構項目數(shù)據(jù)OA流程數(shù)據(jù)檔案管理系統(tǒng)PDM導致重疊和不一致的企業(yè)數(shù)據(jù)項目數(shù)據(jù)標準數(shù)據(jù)產(chǎn)品數(shù)據(jù)設計數(shù)據(jù)冗余數(shù)據(jù)!設計數(shù)據(jù)冗余數(shù)據(jù)!內(nèi)部數(shù)據(jù)庫內(nèi)部數(shù)據(jù)庫內(nèi)部數(shù)據(jù)庫整合的挑戰(zhàn)數(shù)據(jù)整合數(shù)據(jù)整合 數(shù)據(jù)的冗余和沖突性 數(shù)據(jù)的歷史和可追溯性 數(shù)據(jù)的異構性 數(shù)據(jù)可能需要雙向更新 大數(shù)據(jù)量的整合挑戰(zhàn) 數(shù)據(jù)整合的實時性要求 業(yè)務整合業(yè)務整合 業(yè)務的整合依賴于數(shù)據(jù)的整合 業(yè)務整合的時間點可能非常復雜

2、 業(yè)務需求頻繁變化對整合的影響 業(yè)務協(xié)同對事務完整性的要求 傳統(tǒng)廠商的構架方式檔案管理系統(tǒng) WebSphere 統(tǒng)一接入平臺統(tǒng)一接入平臺WebSphere 流程引擎流程引擎Step1Step2Step3Step5Step6Step4企業(yè)服務總線企業(yè)服務總線數(shù)據(jù)服務總線數(shù)據(jù)服務總線傳輸協(xié)議轉(zhuǎn)換 項目管理人員工藝人員適配器適配器Web服務JCA 適配器管理人員設計工程師服務人員WebSphere WebSphere 業(yè)業(yè)務建模務建模WebSphere WebSphere 集成開發(fā)集成開發(fā)建模及開發(fā)平臺適配器統(tǒng)一身份管理OA系統(tǒng) HRHR醫(yī)療系統(tǒng)醫(yī)療系統(tǒng)生產(chǎn)管理人員生產(chǎn)管理人員PDM 管理人員管理人

3、員辦公人員辦公人員現(xiàn)有系統(tǒng)IBMIBM中間件平臺中間件平臺服務注冊、存儲管理數(shù)據(jù)倉庫商業(yè)智能消息格式轉(zhuǎn)換消息路由 企業(yè)消息處理 合作伙伴網(wǎng)關合作方配套商供應商傳統(tǒng)架構的抽象PDM檔案管理OAHRERPMES適配器工作流引擎統(tǒng)一Portal數(shù)據(jù)集市數(shù)據(jù)倉庫主數(shù)據(jù)存儲庫統(tǒng)一身份管理商業(yè)智能ETL變化數(shù)據(jù)傳統(tǒng)的整合方案年月天小時業(yè)務整合決策分析數(shù)據(jù)整合原始業(yè)務系統(tǒng)數(shù)據(jù)倉庫數(shù)據(jù)庫調(diào)度新業(yè)務系統(tǒng)管理決策系統(tǒng) 統(tǒng)一查詢系統(tǒng)解決問題的關鍵 您需要這樣一個整合數(shù)據(jù)中心 能夠與工作流引擎和原始系統(tǒng)有機的交互 能夠?qū)崟r分析結果產(chǎn)生報表和決策依據(jù) 能夠?qū)崟r處理數(shù)據(jù)的清洗問題并保存下來 因此能夠 對業(yè)務整合是有倉庫的

4、調(diào)度中心 對數(shù)據(jù)整合是能跨系統(tǒng)清洗、實時整合的倉庫 對決策分析是基于原始數(shù)據(jù)實時報表、分析、探索 而最重要的是,以上三者基于同一個倉庫MioEdge的整合方案原始業(yè)務系統(tǒng)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)對象對象對象對象對象數(shù)據(jù)規(guī)則自清洗、自關聯(lián)、自整合對象樹對象樹對象樹對象樹對象樹對象樹業(yè)務操作自動監(jiān)控的ESB數(shù)據(jù)數(shù)據(jù)業(yè)務操作對象對象對象對象數(shù)據(jù)數(shù)據(jù)業(yè)務操作業(yè)務操作決策分析業(yè)務創(chuàng)新即席查詢?yōu)槭裁磦鹘y(tǒng)廠商不這么干? 在大系統(tǒng)、大數(shù)據(jù)整合的背景下,構建這樣一個核心的倉庫是極具挑戰(zhàn)的任務 數(shù)據(jù)量和數(shù)據(jù)關聯(lián)的復雜性成為瓶頸,從而無法構建這樣實時處理的倉庫 沒有這樣的自清洗、自關聯(lián)的技術支撐 用分布式的方法沒法解決

5、業(yè)務的事務性保障,用集中式的方法沒法解決數(shù)據(jù)的性能挑戰(zhàn) 落后的關系型數(shù)據(jù)庫技術造成的束縛現(xiàn)代IT架構引擎支撐模式大規(guī)模并行即席查詢大規(guī)模并行即席查詢分析型應用分析型應用商務智能商務智能企業(yè)應用企業(yè)應用( (PDMPDM/ERP/ERP)外部外部數(shù)據(jù)數(shù)據(jù)( (供應商供應商) )數(shù)據(jù)可視化數(shù)據(jù)可視化關系性數(shù)據(jù)分析關系性數(shù)據(jù)分析 整合主數(shù)據(jù)系統(tǒng)與傳統(tǒng)整合方案相比做做得更多得更多傳統(tǒng)方案傳統(tǒng)方案MioEdgeMioEdge跨系統(tǒng)清洗跨系統(tǒng)復合合并即席分析應用級災備問題追蹤復雜協(xié)同數(shù)據(jù)質(zhì)量分析歷史數(shù)據(jù)追溯做得更好做得更好傳統(tǒng)方案傳統(tǒng)方案MioEdgeMioEdge查詢速度更快(亞秒)分析速度更快(x70

6、)數(shù)據(jù)準確性100%硬件投入20%開發(fā)周期大大提升需求變更響應時間20%ESB選配支持數(shù)據(jù)量TB級PB級大數(shù)據(jù)平滑擴展共享資源云類型云類型特點特點軟件服務云(SaaS)以整體成型應用軟件為服務平臺,不能勝任企業(yè)整合的復雜定制化需求平臺服務云(PaaS)集成化的云應用平臺,完美勝任企業(yè)整合的數(shù)據(jù)服務能力和應用管理能力要求硬件服務云(SaaS)僅考慮硬件設備的資源使用,不能提供統(tǒng)一的數(shù)據(jù)服務和應用管理能力云計算平臺選型基于云計算的解決方案 云計算本質(zhì)上是一種分布式解決方案,可以用合理的成本非常好的解決整合系統(tǒng)的性能壓力問題 云計算技術可以很好地利用系統(tǒng)資源并平滑過渡,完美適應系統(tǒng)整合的復雜性增長

7、然而不是所有的云技術都能解決好數(shù)據(jù)整合和業(yè)務整合的問題,這其中包括自清洗、自關聯(lián)、事務性保障以及安全和伸縮性等一系列問題廠商廠商是否具備是否具備PaaSPaaS提供能力提供能力廠商廠商是否具備是否具備PaaSPaaS提供能力提供能力AmazonYesMendixYesAppianMicrosoftYesApprendaMIOsoftMIOsoftYesYesAT&TOracleCaspioOutSystemsCloudBeesYesOrangeScape TechnologiesCordysYesPegasystesdotCloudRackspaceYesEngine YardYesS

8、APGoGridYesSYesGoogleYesServoyInformaticaSoftLayerYesIntuitTibcoIBMYesTier 3JoyentVerizon TerremarkYesLongJumpWorkXpress數(shù)據(jù)來源:Forrest , 數(shù)據(jù)來源:Forrest , 事務擴展私有云安全敏捷 Rapid developYYYYYMIOsoft的MIOedge平臺在安全、可靠的前提下,可為企業(yè)整合搭建專屬的私有云架構,提供靈、變、快、統(tǒng)、智、慧的智能平臺,是目前世界上最為先進、首屈一指的云平臺選擇權威評測機構的結論Gartner (2014 Q1)Gartner (

9、2014 Q1)MioEdge專注于大數(shù)據(jù)管理、數(shù)據(jù)集成、關聯(lián)性數(shù)據(jù)分析,同時支持平行式進程處理和內(nèi)存計算,在絕大多數(shù)aPaaS競爭者中脫穎而出。就事務級關聯(lián)性企業(yè)數(shù)據(jù)計算領域來說,是絕對的市場領先者開發(fā)工具的生產(chǎn)效率非常高,易于學習和使用,對業(yè)務應用和分析可以做到圖形化設計、高效開發(fā)、平行式內(nèi)存計算、同時支持事務型/分析型應用,支持公有云/私有云或混合方式,可在web或手機端展示Forrest (2013 Q2)Forrest (2013 Q2)MioEdge是目前世界上唯一一款能在大數(shù)據(jù)級別進行面向?qū)ο蠼:吞幚淼南到y(tǒng)你也許從未聽說過MioSoft這家公司,但是這家公司提供了一個非常強勁的

10、PaaS平臺,能夠處理海量大數(shù)據(jù)集,并進行數(shù)據(jù)遷移或整合等各種任務。MioEdge簡直是為大數(shù)據(jù)的快速開發(fā)而生成功案例數(shù)據(jù)整合案例Blohm + Voss成功案例:Blohm + Voss Blohm+Voss船廠成立于1872年,至今已有130年的歷史,是一家專門建造80米以上的超級游艇和軍用艦艇的設計和生產(chǎn)商,船廠位于德國。自成立以來,Blohm+Voss船廠已經(jīng)生產(chǎn)了各種船艇達970多艘。成功案例:Blohm + Voss 案例背景:客戶自2012年引進了SAP的系統(tǒng)對整個船廠進行設計、生產(chǎn)和規(guī)劃的管理改造。SAP試圖建立一個主數(shù)據(jù)系統(tǒng),整合原有的一些老系統(tǒng),形成完整的管理系統(tǒng) 然而,到

11、了2014年,客戶逐漸發(fā)現(xiàn)使用過程中的諸多問題:有重復生產(chǎn)的訂單、一些原材料過度耗費、訂單不能按期完成、成品與設計有差異 根據(jù)客戶的經(jīng)驗推斷,這些問題的產(chǎn)生可能是系統(tǒng)間交互出現(xiàn)的問題,也可能來自執(zhí)行人員的問題。但從SAP的系統(tǒng)中無法找到這些問題的原因,也不能進行有效的跟蹤。SAP的系統(tǒng)中并沒有現(xiàn)成的解決方式,如果要他們定制開發(fā)的話,時間在半年以上,而成本則高昂的令客戶無法接受成功案例:Blohm + Voss MIOsoft為客戶提供了定制的解決方案,將客戶的所有數(shù)據(jù)重新整合導入了MioEdge平臺系統(tǒng)中。通過對客戶系統(tǒng)和業(yè)務的梳理,建立了一套完整的對象關系模型(大樹),所有相關的數(shù)據(jù)都邏輯化

12、地組織到了這個模型上 MIOsoft在此基礎上,圖形化地為客戶解決和展示了: 哪些訂單在執(zhí)行過程中有延期或提前的問題? 項目規(guī)劃和分解執(zhí)行之間的時間差異是怎樣的? 哪些部件的設計單被執(zhí)行了多次,為什么? 所有訂單、規(guī)劃、設計和執(zhí)行過程的圖形展示 哪些設計要件沒有出現(xiàn)在項目規(guī)劃圖中? 哪些原材料用到了哪些訂單中? 哪些訂單使用了規(guī)劃外或數(shù)量超額的原材料? 差量計算技術 如果一個設計或規(guī)劃發(fā)生變化了,原始系統(tǒng)沒法只發(fā)出這個變化的部分 原始系統(tǒng)只能發(fā)送客戶完整的設計或規(guī)劃給 MIOsoft的“轉(zhuǎn)換器” “轉(zhuǎn)換器”需要根據(jù)數(shù)據(jù)識別,是否存在需要變化的需求,如果有,是哪部分發(fā)生變化,并對應到相應的訂單和

13、原料上去靈活性 在整個開發(fā)期間,需求規(guī)范不斷變化,更新了多個版本 規(guī)范變化從93頁增長到136頁(+50%) 由于大量相關性的新規(guī)則引入,整合復雜性顯著增加1 MonthsVersion 1.5Version 1.0成功案例:Blohm + Voss 利用MIOsoft提供的整合方案,客戶建立了真正完整的、面向?qū)ο蟮闹鲾?shù)據(jù)系統(tǒng)。 數(shù)據(jù)之間的關聯(lián)性、約束性得到了極好的保證和展示。即使在千萬級別甚至更大的數(shù)據(jù)量級,也能非常容易和直觀地發(fā)現(xiàn)問題、定位問題。 系統(tǒng)保證了客戶從規(guī)劃、設計、生產(chǎn)、裝配等所有環(huán)節(jié)的一致性、精確性、可追溯性成功案例業(yè)務整合案例德國電信項目客戶背景 德國電信是歐洲領先的電信運營

14、商 有超過 240,000 員工 大約40,000,000 客戶 2005年銷售額為596億歐元新舊商業(yè)客戶合同系統(tǒng)間數(shù)據(jù)移植 背景:某歐洲電信運營巨頭開發(fā)了全新架構的商業(yè)客戶合同系統(tǒng),在MioSoft接手這個項目之前嘗試了多年在該新舊系統(tǒng)間的數(shù)據(jù)移植,未果。 難度: 新舊系統(tǒng)間完全不同架構(兩邊完全不同形狀的沙漏,每粒沙子和若干別的沙子有千絲萬縷的聯(lián)系) 近十層的Hierarchie 結構(客戶、帳單、合同,子合同、更新合同版本、產(chǎn)品配置參數(shù)) 逾四百個表格,每個表格幾十個屬性 全國22個區(qū)域劃分,每個區(qū)域的數(shù)據(jù)移植控制在4個小時之內(nèi) 項目的復雜性要求永久數(shù)據(jù)存儲案例:集團并購后的數(shù)據(jù)整合

15、背景:40億條客戶、帳單、合同、產(chǎn)品數(shù)據(jù)在集團固網(wǎng)、互聯(lián)網(wǎng)、移動業(yè)務并購之后的集成分析。 任務:每月進行數(shù)據(jù)質(zhì)量分析。 效果: 收入保障 加速訂單處理進程 提高集團內(nèi)整體IT流程鏈的自動準確性 難度: 數(shù)據(jù)量大,時間緊迫面臨的挑戰(zhàn) 合同轉(zhuǎn)換一般是N:M型的 一條合同可能產(chǎn)生多條計費事務(也支持無更新) 多條合同可能會合并產(chǎn)生一條計費事務(新產(chǎn)品定義) 一條響應可能需花費10天的時間,并需將其對應到N:M的相關合同上 非常大的數(shù)量集 基礎存儲合同1億條 每天新增100,000到500,000條 為實現(xiàn)差量計算需實現(xiàn)數(shù)據(jù)永久性存儲德國電信MCCR項目 海量數(shù)據(jù)的強大處理能力系統(tǒng)描述系統(tǒng)描述數(shù)據(jù)數(shù)據(jù)

16、記錄記錄存儲存儲空間空間數(shù)據(jù)數(shù)據(jù)模型模型硬件硬件花費花費加載加載時間時間集團內(nèi)集團內(nèi)6 6個主要個主要系統(tǒng)系統(tǒng)6個重要功能系統(tǒng),其中有些系統(tǒng)包含逾20個地域分散子系統(tǒng)共65億當中一個系統(tǒng)要求高達323TB1:n1億歐元每個系統(tǒng)平均2周,共12周MioSoftMioSoft系統(tǒng)系統(tǒng)1個系統(tǒng)65億 21TB更復雜 m:n50萬歐元3天系統(tǒng)的安全與可靠性系統(tǒng)安全性 可以保證安全的配置有 專線專網(wǎng) 私有云 日志審核與報警 系統(tǒng)授權管理和平臺授權管理 私有數(shù)據(jù)庫結構和接口 數(shù)據(jù)加密 異地災備平臺可靠性 在支撐CRM和Billing的電信級項目中,系統(tǒng)可靠性達到99.96%,經(jīng)Gartner評比,達到世界最高可用性系統(tǒng)標準 Several hundred paying enterprise customers (although not all using the public cloud version of the suite); the use of MIOsoft-controlled colocated data centers in multiple geogr

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論