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