作為一個ERP，簡單粗暴來說可以分為平臺和業(yè)務子系統(tǒng)兩部分。ERP平臺架構(gòu)的完備性如何評估，業(yè)務子系統(tǒng)架構(gòu)的完備性如何評估，業(yè)務子系統(tǒng)功能的完備性如何評估，這都是需要講與究的。

當然，從現(xiàn)代軟件應用架構(gòu)分層角度來看，有UI層（還細分為UI展示、UI控制、UI前置后置數(shù)據(jù)處理）、業(yè)務邏輯層（還細分為服務整合、領(lǐng)域?qū)嶓w、數(shù)據(jù)持久化）、數(shù)據(jù)存儲層（還細分為數(shù)據(jù)視圖、數(shù)據(jù)存儲、數(shù)據(jù)ETL）。在這三層之間，每兩層與層之間還有接口層，做調(diào)用對接和數(shù)據(jù)傳輸用，這些層都需要專門設(shè)計。我們一是需要這樣的設(shè)計方法，二是需要把這些設(shè)計方法在日常應用子系統(tǒng)架構(gòu)設(shè)計層面落實，這就需要專門的應用架構(gòu)師，專門在業(yè)務子系統(tǒng)實現(xiàn)設(shè)計層面發(fā)力。他們既要精通實現(xiàn)設(shè)計方法，還需要對業(yè)務架構(gòu)有一定功底，才能讓做出來的實現(xiàn)設(shè)計符合業(yè)務粒度、業(yè)務演進。能有這兩方面功底的都是寶貝人才。

ERP的架構(gòu)，其本質(zhì)是為了在大層面大框架上保證ERP軟件在開發(fā)和維護演進過程中一直能在機制上底層上框架上保證質(zhì)量和維護效率。沒有專門的應用架構(gòu)和平臺架構(gòu)設(shè)計，ERP軟件就成了功能實現(xiàn)代碼的堆砌，堆個五六年就藕斷絲連按下葫蘆起了瓢了，就跟打地鼠一樣，越到后來地鼠越多越神出鬼沒，最后幾雙手都按不住了，Game Over了。

當然，ERP的應用架構(gòu)的完備性評估，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

當然，這是全視角完備性來看。但我們可以裁減性的去重點關(guān)注，以及每個時期不斷演進成熟不斷轉(zhuǎn)移關(guān)注重點。

一、在最基礎(chǔ)層面：安全、性能、數(shù)據(jù)正確、功能正確，怎么在應用架構(gòu)專業(yè)方法和流程職責機制上保證。不少ERP軟件目前還重點關(guān)注在功能是否符合客戶需要，功能是否符合設(shè)計要求。還沒有橫切面研究安全架構(gòu)，也沒有研究如何在架構(gòu)方法層面保證數(shù)據(jù)正確性。要想開展研究，就得按橫切維度，如安全，就按照ERP應用架構(gòu)一層層去分析如何在每層的框架上保證安全。當然，深入更現(xiàn)實的一個具體的功能模塊或引擎服務，也需要這個維度去定制化思考與設(shè)計。

還有一個維度也是最基礎(chǔ)層面，但很多人容易忽略它。那就是可測試。業(yè)務邏輯層怎么測、UI層怎么測、數(shù)據(jù)層怎么測。

二、做到了基礎(chǔ)層面，就進入了軟件的持續(xù)維護改進階段。可持續(xù)改進維護、可移植、可向下兼容、可對內(nèi)對外集成是關(guān)鍵切面了。這也是需要應用架構(gòu)層面專項切面來研究的。研究方法一樣，仍然是按照軟件分層來層層有專門的架構(gòu)設(shè)計。

可持續(xù)改進維護，有兩個小分支，一個是產(chǎn)品功能和業(yè)務模型不斷演進，需要代碼可持續(xù)改進維護。如何在架構(gòu)層面保證。一個是客戶定制代碼可持續(xù)改進維護。尤其是客戶定制代碼和產(chǎn)品代碼之間的解耦離合關(guān)系，以及客戶定制代碼升級與產(chǎn)品代碼升級的相互影響關(guān)系，這兩個關(guān)系需要巧妙的應用架構(gòu)設(shè)計和實現(xiàn)設(shè)計。

可移植，一說是跨平臺的移植，如跨UI技術(shù)、跨業(yè)務邏輯開發(fā)語言技術(shù)、跨數(shù)據(jù)庫技術(shù)、跨硬件設(shè)備。二說是一個功能模塊如何可移植到其他版本或特定客戶。這也需要應用架構(gòu)研究。

可向下兼容，我們經(jīng)常會遇到業(yè)務模型本身就不兼容了，我們的代碼如何最大化的保證向下兼容，這樣代碼維護質(zhì)量和效率就高。在中國現(xiàn)狀，業(yè)務模型本身不兼容是一件比較常見的事，畢竟在快速受到各方面各路子方法或思想的沖擊，過去積累少，一下來的太多，選擇的方法和自己的現(xiàn)狀問題不匹配是很正常的。

集成，有對內(nèi)集成，如自己產(chǎn)品線的各個模塊；有對外的集成，要把其他系統(tǒng)的功能、引擎、流程、數(shù)據(jù)集成進來或輸出接口API，這也需要考究的應用架構(gòu)。

三、做完這些基礎(chǔ)層和高級層，我們就需要關(guān)注到整個協(xié)作鏈條上的關(guān)注點了。

那就是可升級，可安裝、可實施、易用性、可運維。

可升級，有四個分支：整體升級、子系統(tǒng)模塊升級、定制開發(fā)專項升級、BUG補丁升級。

可安裝，也有五個分支：演示環(huán)境安裝、測試環(huán)境安裝、生產(chǎn)環(huán)境安裝、重新安裝、災難恢復。

可實施。實施人員往往配置業(yè)務參數(shù)、初始化數(shù)據(jù)\導入數(shù)據(jù)、配置流程、配置報表和查詢。這些實施工具需要涵蓋考慮。

易用性是相對客戶而言的。很多人說ERP很復雜。但其實本質(zhì)上并不是。因為很多企業(yè)主對自己上ERP到底需要明確解決哪幾個問題，沒有顯性化的清單。對IT技術(shù)實現(xiàn)的軟件的擅長面和不擅長面更是不了解，要么把ERP當做先進管理制度的顯性產(chǎn)物來高捧看來，要么把ERP當做EXCEL或強大計算器在用。而且很多企業(yè)沒有細致的顯性化的組織崗位職責、流程、表單、報表、考核，即使有，也是現(xiàn)實和制度兩張皮。這是企業(yè)方的問題，另外在ERP開發(fā)方，也沒有按照業(yè)務場景來設(shè)計ERP，而是把各種業(yè)務場景都分析完然后整合成幾個功能模塊給客戶，就如同一把刀做N種菜，當然高不成低不就，不易用就產(chǎn)生了。對于易用性的橫切面研究，也需要一層層的按照架構(gòu)來研究，而不是只局限關(guān)注在每個具體功能的易用性。要靠架構(gòu)在框架上保證易用性，而不是在每個具體點保證易用性。這是關(guān)鍵出路。

可運維。你的軟件安裝到了客戶處，你對你的軟件使用情況和軟件運行情況了解不？這就是可運維。需要在應用架構(gòu)層面一層層考慮如何在各層增強可運維，提供可運維需要的功能和數(shù)據(jù)信息。

知道了這么多橫切面維度，我們就需要按維度和軟件分層做個二維表，看看每個維度每一層需要做些什么事，我們已經(jīng)做了哪些事，哪些事還是一片空白，哪些事還需要改進。有這樣一個大完備性清單了，我們就可以根據(jù)優(yōu)先級來分步研究、落地了。