作為一個ERP，簡單粗暴來說可以分為平臺和業(yè)務子系統(tǒng)兩部分。ERP平臺架構的完備性如何評估，業(yè)務子系統(tǒng)架構的完備性如何評估，業(yè)務子系統(tǒng)功能的完備性如何評估，這都是需要講與究的。
當然，從現(xiàn)代軟件應用架構分層角度來看，有UI層（還細分為UI展示、UI控制、UI前置后置數(shù)據(jù)處理）、業(yè)務邏輯層（還細分為服務整合、領域實體、數(shù)據(jù)持久化）、數(shù)據(jù)存儲層（還細分為數(shù)據(jù)視圖、數(shù)據(jù)存儲、數(shù)據(jù)ETL）。在這三層之間，每兩層與層之間還有接口層，做調(diào)用對接和數(shù)據(jù)傳輸用，這些層都需要專門設計。我們一是需要這樣的設計方法，二是需要把這些設計方法在日常應用子系統(tǒng)架構設計層面落實，這就需要專門的應用架構師，專門在業(yè)務子系統(tǒng)實現(xiàn)設計層面發(fā)力。他們既要精通實現(xiàn)設計方法，還需要對業(yè)務架構有一定功底，才能讓做出來的實現(xiàn)設計符合業(yè)務粒度、業(yè)務演進。能有這兩方面功底的都是寶貝人才。
ERP的架構，其本質(zhì)是為了在大層面大框架上保證ERP軟件在開發(fā)和維護演進過程中一直能在機制上底層上框架上保證質(zhì)量和維護效率。沒有專門的應用架構和平臺架構設計，ERP軟件就成了功能實現(xiàn)代碼的堆砌，堆個五六年就藕斷絲連按下葫蘆起了瓢了，就跟打地鼠一樣，越到后來地鼠越多越神出鬼沒，最后幾雙手都按不住了，Game Over了。
當然，ERP的應用架構的完備性評估，ISO早就有好的標準體系，這就是標準和標桿的威力。你還在自己苦苦追尋、琢磨、看書、動手，人家已經(jīng)有現(xiàn)成方法放那里了，所以不要亂摸索，尤其在計算機業(yè)，我們國內(nèi)和外國差距少說20年，太陽底下無新鮮事，先學習人家的標準，而不要自己埋頭瞎琢磨。
ISO/IEC9126是一個評估軟件質(zhì)量的通用模型，我個人也感覺是適用于ERP軟件。畢竟，ERP也只是一個軟件中的一種，它具有軟件的基本特征。
看看ISO9126怎么說：
ISO9216把軟件質(zhì)量分為六大特性27個子特性
1. 功能性
適合性suitability
準確性accuracy
保密安全性security
互操作性interoperability
功能性的依從性functionality compliance
2. 可靠性
成熟性maturity
容錯性fault tolerance
易恢復性recoverability
可靠性的依從性reliability compliance
3. 易用性
易理解性understandability
易學性learn ability
易操作性operability
吸引性attractiveness
易用性的依從性usability compliance
4. 效率
時間特性time behavīor
資源利用性resource utilization
效率的依從性efficiency compliance
5. 維護性
易分析性analyzability
易改變性changeability
穩(wěn)定性stability
易測試性testability
維護性的依從性maintainability compliance
6. 可移植性
適應性adaptability
易安裝性install ability
共存性co-existence
易替換性replace ability
可移植的依從性portability compliance
當然，這是全視角完備性來看。但我們可以裁減性的去重點關注，以及每個時期不斷演進成熟不斷轉移關注重點。
一、在最基礎層面：安全、性能、數(shù)據(jù)正確、功能正確，怎么在應用架構專業(yè)方法和流程職責機制上保證。不少ERP軟件目前還重點關注在功能是否符合客戶需要，功能是否符合設計要求。還沒有橫切面研究安全架構，也沒有研究如何在架構方法層面保證數(shù)據(jù)正確性。要想開展研究，就得按橫切維度，如安全，就按照ERP應用架構一層層去分析如何在每層的框架上保證安全。當然，深入更現(xiàn)實的一個具體的功能模塊或引擎服務，也需要這個維度去定制化思考與設計。
還有一個維度也是最基礎層面，但很多人容易忽略它。那就是可測試。業(yè)務邏輯層怎么測、UI層怎么測、數(shù)據(jù)層怎么測。
二、做到了基礎層面，就進入了軟件的持續(xù)維護改進階段。可持續(xù)改進維護、可移植、可向下兼容、可對內(nèi)對外集成是關鍵切面了。這也是需要應用架構層面專項切面來研究的。研究方法一樣，仍然是按照軟件分層來層層有專門的架構設計。
可持續(xù)改進維護，有兩個小分支，一個是產(chǎn)品功能和業(yè)務模型不斷演進，需要代碼可持續(xù)改進維護。如何在架構層面保證。一個是客戶定制代碼可持續(xù)改進維護。尤其是客戶定制代碼和產(chǎn)品代碼之間的解耦離合關系，以及客戶定制代碼升級與產(chǎn)品代碼升級的相互影響關系，這兩個關系需要巧妙的應用架構設計和實現(xiàn)設計。
可移植，一說是跨平臺的移植，如跨UI技術、跨業(yè)務邏輯開發(fā)語言技術、跨數(shù)據(jù)庫技術、跨硬件設備。二說是一個功能模塊如何可移植到其他版本或特定客戶。這也需要應用架構研究。
可向下兼容，我們經(jīng)常會遇到業(yè)務模型本身就不兼容了，我們的代碼如何最大化的保證向下兼容，這樣代碼維護質(zhì)量和效率就高。在中國現(xiàn)狀，業(yè)務模型本身不兼容是一件比較常見的事，畢竟在快速受到各方面各路子方法或思想的沖擊，過去積累少，一下來的太多，選擇的方法和自己的現(xiàn)狀問題不匹配是很正常的。
集成，有對內(nèi)集成，如自己產(chǎn)品線的各個模塊；有對外的集成，要把其他系統(tǒng)的功能、引擎、流程、數(shù)據(jù)集成進來或輸出接口API，這也需要考究的應用架構。
三、做完這些基礎層和高級層，我們就需要關注到整個協(xié)作鏈條上的關注點了。
那就是可升級，可安裝、可實施、易用性、可運維。
可升級，有四個分支：整體升級、子系統(tǒng)模塊升級、定制開發(fā)專項升級、BUG補丁升級。
可安裝，也有五個分支：演示環(huán)境安裝、測試環(huán)境安裝、生產(chǎn)環(huán)境安裝、重新安裝、災難恢復。
可實施。實施人員往往配置業(yè)務參數(shù)、初始化數(shù)據(jù)\導入數(shù)據(jù)、配置流程、配置報表和查詢。這些實施工具需要涵蓋考慮。
易用性是相對客戶而言的。很多人說ERP很復雜。但其實本質(zhì)上并不是。因為很多企業(yè)主對自己上ERP到底需要明確解決哪幾個問題，沒有顯性化的清單。對IT技術實現(xiàn)的軟件的擅長面和不擅長面更是不了解，要么把ERP當做先進管理制度的顯性產(chǎn)物來高捧看來，要么把ERP當做EXCEL或強大計算器在用。而且很多企業(yè)沒有細致的顯性化的組織崗位職責、流程、表單、報表、考核，即使有，也是現(xiàn)實和制度兩張皮。這是企業(yè)方的問題，另外在ERP開發(fā)方，也沒有按照業(yè)務場景來設計ERP，而是把各種業(yè)務場景都分析完然后整合成幾個功能模塊給客戶，就如同一把刀做N種菜，當然高不成低不就，不易用就產(chǎn)生了。對于易用性的橫切面研究，也需要一層層的按照架構來研究，而不是只局限關注在每個具體功能的易用性。要靠架構在框架上保證易用性，而不是在每個具體點保證易用性。這是關鍵出路。
可運維。你的軟件安裝到了客戶處，你對你的軟件使用情況和軟件運行情況了解不？這就是可運維。需要在應用架構層面一層層考慮如何在各層增強可運維，提供可運維需要的功能和數(shù)據(jù)信息。
知道了這么多橫切面維度，我們就需要按維度和軟件分層做個二維表，看看每個維度每一層需要做些什么事，我們已經(jīng)做了哪些事，哪些事還是一片空白，哪些事還需要改進。有這樣一個大完備性清單了，我們就可以根據(jù)優(yōu)先級來分步研究、落地了。
轉載請注明出處：拓步ERP資訊網(wǎng)http://www.lukmueng.com/
本文標題：ERP系統(tǒng)架構的完備性解析
本文網(wǎng)址：http://www.lukmueng.com/html/consultation/10820014229.html
相關文章
