申請免費試用、咨詢電話:400-8352-114
文章來源:泛普軟件
在剛剛過去的一年中,Builder.com公司一直沒有很好的解決帶有多個客戶端的主數據的管理問題,為此,根據我的經驗,針對這個問題我為他們寫了一篇文章,告訴他們如何才能實現(xiàn)主數據的最佳管理。針對這個目標,在本文中,我將檢查分析所有的實現(xiàn)進程,得到的經驗教訓、所走過的彎路以及對目標所做的修正。
在一個公司中,主數據管理系統(tǒng)(MDMS)的主要作用在于可以有一個單一的系統(tǒng)作為所有公有數據項的一個參考點。然后,在組織內的每個"客戶"系統(tǒng)就可以參考這個系統(tǒng)來管理它的關鍵數據,從而可以確保在整個應用程序套件內數據的共通性以及正確性。
通過其他應用程序來了解MDMS
我在以前的文章中指出,在公司內,實現(xiàn)這個目標的進程來的很慢,但是確實在向前推進。這主要是因為公司中存在著這樣的三類應用程序:
新創(chuàng)建的應用程序,包括內部和外部創(chuàng)建的應用程序以及一些不需要定制的應用程序。
升級的應用程序,在一個已經存在的系統(tǒng)中可能存在一個這樣的窗口,通過這個窗口可以實現(xiàn)升級工作。
遺留下來的應用程序,系統(tǒng)中沒有升級窗口,也沒有該系統(tǒng)的替代產品。
在第一種情況中,如果在系統(tǒng)分析的過程中就已經認識到這一點,那么作為這種類型項目的研發(fā)或者安裝和配置進程的一部分,就可以將其作為一個到MDMS系統(tǒng)的連接引入到MDMS系統(tǒng)中。如果沒有做這方面的連接,那么其主要原因或者部分原因通常可以歸結為沒有預算、沒有可用的資源或者沒有時間等方面。然而,如果已經考慮到了這個連接問題并且有預算的話,那么就沒有理由不讓這些新的應用程序充分利用MDMS。
在第二種情況中,作為該系統(tǒng)升級規(guī)程的一部分,是可以規(guī)劃和預算相應連接的。當然,增加這些系統(tǒng)到MDMS系統(tǒng)的連接的話,需要對這種連接的影響做大量的分析工作;例如,如果對存儲在MDMS中的一個數據項進行升級的話,那么對系統(tǒng)的影響是什么? 另外,在這種類型的項目中,資金一般是用于新的功能而不是用于改善基礎設施,因此在一個特定的升級過程中,可能不會執(zhí)行一些低優(yōu)先級的連接。
最后一種情況是遺留下來的應用程序,從連接到MDMS系統(tǒng)的角度來說,在一些大的公司中,遺留系統(tǒng)是最常見的系統(tǒng)也是處理起來最復雜的系統(tǒng)。如今,很多公司都有一個用所謂的"遺留"語言如COBOL所做的重要程序,根據DevX的一份聲明:
"世界上70%的數據都是用COBOL語言處理的,并且90%的ATM事務處理用的都是COBOL語言。如今每天在線處理的COBOL事務有300億次。500強中有492家使用了COBOL語言,包括全部的100強,而且目前在COBOL方面的投資已經超過3萬億美元。"
盡管情況如此,但是很少有程序員具有這種必要的COBOL語言的技能。這是因為很多有這種技能的程序員正處于退休的年齡。因為無論是在公司中還是在大學中,具有COBOL技能的程序員看起來遠遠沒有具有如Java或者.NET技能的程序員那樣有誘人的前景,如今具有這種技能的程序員的數量在急劇下降,如果公司沒有明智的考慮到這些問題的話,這個問題將類似于當年的Y2K問題,可能成為一件令人頭痛的事情,并且可能導致具有這種技能的程序員的大量加薪。
在有些公司中,存在著這樣的諺語"如果沒有出現(xiàn)問題就不需要修理。"并且他們將其作為另外一種常見的理由,只要這些系統(tǒng)能夠工作就不對其進行任何改進,有限的資金、資源和時間最好用在其他地方。從而使得這種類型的系統(tǒng)很難集成到新的MDMS系統(tǒng)中,但是面對這種趨勢,我的建議是:雖然這些資源仍然可以使用,但是至少應該盡量考慮到他們,當然是相對便宜的應該優(yōu)先考慮。
并行研發(fā)的問題
我們所需要解決的一個主要問題是:在一個組織內研發(fā)MDMS系統(tǒng)的同時常常會并行的有其他的研發(fā)工作。因此在規(guī)劃MDMS系統(tǒng)或者其他系統(tǒng)的行為時常常會引起一些問題。這些問題可能包含以下情景:
直到MDMS已經開始"運轉"時,MDMS系統(tǒng)也沒有得到最初規(guī)劃所需要的數據。
作為一種共有的并且是系統(tǒng)需要的數據,可當時并沒有打算將其包含在MDMS系統(tǒng)中。
在現(xiàn)存的應用程序中新識別出來的共有數據并沒有從MDMS中提取出來。
對研發(fā)團隊和MDMS團隊來說,還有其他的限制因素如預算、時間或者資源等。
在一個組織內部署MDMS系統(tǒng)將可能帶來大量增加修改工作,因為管理者總是試圖要求研發(fā)路徑和升級路徑盡可能與MDMS系統(tǒng)自身的研發(fā)路徑相符合。雖然這確實可能導致大量的令人頭痛的問題以及一些其他問題,但是總體來說還是值得的。
在我曾經合作過的幾個團隊中,他們解決這些可能潛在問題的一種方法是:一開始將他們的數據存儲在本地的一個數據庫內,然后,在一個合適的時候,或者從MDMS系統(tǒng)中將這些數據導入到這個數據庫中,或者更改連接這樣就可以直接從MDMS中加載數據。通過這種方式就可以讓本地應用程序按照自己的節(jié)奏、一條一條的將它的管理數據轉換到MDMS系統(tǒng)中,而且它們就不會受到其他活動的影響也不會受到這些活動的約束。這是因為相對而言,更改一個數據庫的連接器或者將另一個數據庫增加到數據活動腳本如EAI或者ETL或者甚至是一個SQL Server DTS包中是一件相當容易的任務。
案例研究
在我的客戶中,有一個客戶很特別,任何修改MDMS系統(tǒng)對企業(yè)運作所造成的影響他都很清楚,并且他對在最近一次內部分類繼承的更新過程中數據流過其他系統(tǒng)的速率也非常清楚。雖然只有一部分數據發(fā)生了改變,但是在真的發(fā)生了改變以后,IT部門就會開始接到需要技術支持的傳票--它們聲稱系統(tǒng)A中的數據和系統(tǒng)B并不匹配,因為在當時的情況下,只有其中的一個系統(tǒng)發(fā)生了改變,而另一個系統(tǒng)還沒有來得及改變。
然后,他們會發(fā)現(xiàn)另一個系統(tǒng)--系統(tǒng)C已經崩潰,因為系統(tǒng)C的數據庫中包含了分類繼承表和公司銷售的產品之間的關系。這些改變已經破壞了原有的連接,因而導致了系統(tǒng)出錯,并且導致系統(tǒng)C中有些數據丟失。幸運的是,系統(tǒng)在將這些已經被破壞的數據傳向其他系統(tǒng)之前就已經發(fā)現(xiàn)了問題,否則的話終端用戶有可能使用這些被破壞的數據來做任何他們想做的事情。
通過MDMS系統(tǒng)將各個系統(tǒng)連接在一起確實存在著一定的風險,這些風險又讓你懷疑是否真的值得去冒這種風險。IT團隊為此不得不投入大量的時間和資源來對系統(tǒng)C進行備份,更不用說他們讓那些終端用戶對他們失去了信心,并且終端用戶完全有可能將此作為他們工作中的一段插曲。