ERP系統架構的完備性解析
原文地址：http://os.51cto.com/art/201206/343852.htm
作爲一個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種菜，當然高不成低不就，不易用就產生了。對於易用性的橫切面研究，也需要一層層的按照架構來研究，而不是隻侷限關注在每個具體功能的易用性。要靠架構在框架上保證易用性，而不是在每個具體點保證易用性。這是關鍵出路。
可運維。你的軟件安裝到了客戶處，你對你的軟件使用情況和軟件運行情況瞭解不？這就是可運維。需要在應用架構層面一層層考慮如何在各層增強可運維，提供可運維需要的功能和數據信息。
知道了這麼多橫切面維度，我們就需要按維度和軟件分層做個二維表，看看每個維度每一層需要做些什麼事，我們已經做了哪些事，哪些事還是一片空白，哪些事還需要改進。有這樣一個大完備性清單了，我們就可以根據優先級來分步研究、落地了。