以下文章來源于信息化與數字化 ，作者沈旸
來源：信息化與數字化
導讀：熟悉SAP ERP的同學可以從后往前看，有精彩的歷史故事。
“開源”對企業應用和生態有什么樣的影響？
在Github上瀏覽開源軟件，會發現那些最火的項目大多數屬于基礎架構層面，而應用層的開源軟件，特別火的很少。大家可以在www.ossinsight.io里找到各類開源項目的統計數據，查看各個領域里最流行的開源軟件的排名和趨勢。
為什么好的開源軟件多是基礎架構層？
像操作系統、數據庫、Web中間件這樣，使用量都是以“億”為單位的，工程師在這里寫下的代碼發揮的杠桿作用最高，基礎架構軟件工程師可以為了情懷而寫下優美的代碼。基礎架構層的軟件面向機器世界，而機器世界的約束邊界多屬于已知的邊界，在已知的邊界里尋找最優解會更容易、更清晰，一個領域發展到最后，可能只會剩下幾個最好的產品。等下一個技術變革或者商業格局劇變的時候，才會出現新的發展窗口期。例如最近幾年中國開源軟件快速發展，出現了像TiDB、TDengine這樣的優秀產品。
基礎架構層的軟件是面向機器世界的，而應用軟件是面向組織社會的。機器世界的規則在全世界都是通用的，產品優劣很容易評判。而應用是面向人和社會的，規則在不同的國家、不同的地區、不同的文化和不同的組織之間都有非常大的差異。在應用軟件層，經常要面臨大量的定制化開發和需求變動，并不是最貴最流行的軟件就會適用你的場景。文無第一，武無第二，跟基礎軟件和應用軟件的比較很類似。也有言論稱，信息化是面向人的，數字化是面向機器的，如果從這個角度來看的話，做好信息化比做好數字化可要難多了。
應用軟件的使用量很難達到基礎軟件那樣的規模，大家寫下的代碼可能很快就被修改或者棄用，所以應用軟件比較難吸引優秀的工程師全身心投入。因此，大家可能會好奇，在應用領域里，開源能夠起到什么樣的作用。今天就以SAP的經典ERP軟件為例，一個三十年基本沒怎么變化的架構體系，聊一下"開源"對企業應用的影響。
SAP ERP軟件歷史
SAP ERP軟件是世界上最普及的企業級應用。1972年，SAP R/1開始投放市場；1979年，SAP發布了SAP R/2；1992年，從SAP R/2進階到SAP R/3，奠定了后面幾十年的框架，其中R3的技術底座SAP kernel幾乎是所有SAP產品的基礎。
今天ERP經常被一些新的概念產品批評為“封閉”或者是“不夠敏捷”。不過專業的SAP咨詢顧問和實施顧問可能會有不同的感受。在私有部署軟件的年代，相對于其他平臺，SAP的ERP是最開放的平臺之一，因為開放性其產品成為了全世界企業管理軟件里最廣泛的低代碼定制化開發平臺，不同的行業不同國家的客戶的管理理念都能夠在系統里實現。可以毫不夸張地說，在私有部署年代的大型企業應用里，SAP的ERP軟件幾乎是無敵的存在。
標準化與定制化的矛盾
今天很多軟件廠商還在糾結于產品標準化和定制化之間的矛盾，既希望推出標準產品，又垂涎大客戶的定制大單。一旦遇上大型定制化項目，大量產品研發人員會陷入到定制化的深坑里，客戶的定制版本在未來升級時，也會有很大的隱患。如果面對成千上萬個定制化的軟件項目，交付成本和維護成本將陷入規模不經濟的陷阱，影響企業的進一步擴張。因此一個初創的產品團隊對那種財大氣粗但是定制要求多的客戶，真是又愛又恨。
檢驗一個產品標準化程度高低的一個有效方法是，這個產品是否可以由獨立第三方甚至客戶自己來實施。因為第三方團隊與產品企業打交道的時候，因為溝通成本和商務成本會損失一定的效率，如果在初期的時候發現產品的標準化程度可以平衡這一部分損失的效率，在后期就可以做到有效的大規模擴張了。
SAP的第三方生態
在ERP領域里有一個廣為流傳的“五倍法則”。比如用100萬來購買軟件，那么項目上線的總預算要規劃在500萬或者更多，其中的400萬要花在管理咨詢、業務咨詢和實施服務上，此外上線后可能還有運維和內部團隊的其他成本。一個大型的ERP項目上線，一般先有波士頓咨詢、麥肯錫這樣的管理咨詢公司從高層戰略開始分析規劃，然后由IBM、埃森哲、德勤這樣的咨詢和實施團隊來做具體的業務拆解和實施。
一個SAP的ERP項目上線，完全可以由第三方的合作伙伴獨立完成。許多第三方服務商的專業程度，在自己的擅長領域里經常超過原廠的水平，比如在Gartner象限里SAP的原廠實施能力并不是排第一。SAP原廠的實施顧問團隊規模并不大，一般會負責戰略客戶、新產品的項目，或者負責大型項目中的新產品模塊咨詢、項目監理、項目顧問等角色。在2020年SAP生態圈里，有超過100萬的咨詢顧問和實施顧問，規模遠超SAP原廠的團隊。
私有部署時代，大型企業應用的痛點
在今天SaaS軟件已經變得很普及，大家可能已經習慣了SaaS軟件的許多優點，如敏捷、統一性、產品快速迭代、維護簡單、廠商可以在線重現并解決問題等。十年前SAP的ERP主要是在私有部署的環境下，我曾在SAP參與過全球上百家世界500強企業的短期項目，也同第三方合作伙伴參與過上億美元的長周期項目。在全球范圍的多個國家、多個行業的私有部署環境下，做定制化開發會碰到哪些困難呢？
國際化的政策復雜度
例如在美國，每個州的稅收規則不同，針對不同的家庭和企業條件的稅收政策也不同，每年還會有新的財稅政策調整。美國的個稅是先預估一個個人的年度平均稅率，然后每個月扣除額度差不多，第二年的4月15號之前重新計算年度收入應稅金額，多退少補，退稅政策非常復雜。而中國在2019年12月31日公布了一個新的個稅政策，個稅扣除從首月開始，逐漸增多，年底再重新計算，多退少補。每個國家的政策差別很大，而且可能會發生突然的改變。
這樣的政策變化也需要系統里的管理和業務規則有相應的改變，但是一個軟件產品公司，不可能在一天的時間內迅速理解各個國家的政策，并打上升級的補丁。很多時候，需要依靠本土的咨詢和實施合作伙伴在第一時間內給出本土化的臨時解決方案，經過驗證后，SAP再推出正式的補丁。
復雜的業務邏輯
每個大型企業的業務和管理規則都有獨特的地方，自身的ERP業務系統有大量的定制化開發的代碼，不同的模塊和組件之間的邏輯關系也非常復雜。給這些客戶做實施顧問，往往需要非常強的行業背景，熟悉業務配置和讀懂業務代碼邏輯，但不具備專業的開發能力。比如下圖是油氣行業的解決方案演化過程，里面有非常多的專業的業務設計。
復雜業務系統發生錯誤，并不一定是由于軟件的技術平臺造成的，可能是因為定制化的配置和業務代碼出現的邏輯錯誤。在這種情況下，如果不能夠深度了解客戶的業務，可能連重現問題都很困難。這些問題往往只能先由客戶的內部顧問或者第三方服務團隊來重現，甚至是找到問題和解決方案。
數據安全的問題
客戶因為數據的安全顧慮，不方便原廠和第三方來協助在生產系統上進行直接的測試，例如上市公司的合并報表系統。假設一個大型上市公司的財務合并報表出現了數據不一致，這樣的數據如果直接暴露給軟件廠商和外部顧問，風險極大。大型上市公司的ERP團隊需要有很強的技術和業務能力，內部團隊先來做初步定位，用模擬數據來重現問題，最后把模擬場景交給第三方團隊或者原廠來做技術支撐。
什么樣的技術架構可以解決這些痛點？
上一個章節描述的這些私有部署環境下的痛點，幾乎每個軟件廠商都會碰到，尤其是規模稍微大一些的時候。那么SAP的ERP是怎么平衡這個問題的呢？很多文章有不同的解釋，比如架構體系設計的超前，原廠克制自身的咨詢實施團隊的擴張，抓住了歐美全球化擴張的時間窗口期等。
不過，我最近幾年接觸了比較多的開源產品和團隊，對之前接觸過的SAP項目和生態有了一些不同視角的理解，今天就來講一講開源對SAP生態的影響。
大家可以看到，解決這些痛點離不開第三方合作伙伴和客戶自身團隊的技術能力，這些能力的建設很大程度要歸功于SAP的ABAP開發語言。SAP的ABAP開發平臺，雖然不是開源的協議，但是所有的業務代碼對客戶和合作伙伴都是開放可見的。獨立的業務和技術顧問可以通過開發平臺的各種工具，跟蹤調試重現系統的問題；厲害的顧問在給原廠提問題工單的時候，甚至還附上問題的解決方案。
ABAP語言是一種神秘而古老的語言，比現在常用的Python/ target=_blank class=infotextkey>Python和JAVA都要古老。ABAP作為一種面向特定應用的編程語言，最早在20世紀80年代開發，ABAP編程語言最早用于開發SAP R/3平臺，客戶也可以用ABAP編程開發自定義的報表和界面。到2000年后，SAP的核心ERP系統里的基本功能幾乎都是用ABAP編程語言來實現的。
閉源的Kernel基礎層和開源的ABAP應用層
以SAP的經典ERP產品在2005年前后發行的版本ECC6.0為例，從技術上來講，其主要可以分為客戶端展示層、應用層和數據庫層，它是一個典型的前后端一體的框架。而它的應用層也分為三層：面向前端交互的邏輯層，面向應用的ABAP層以及跟數據庫、操作系統、系統管理等打交道的BASIS層。其中BASIS層的內核（Kernel）是由C語言編寫的，Kernel是SAP系統的基礎技術平臺。Kernel向下面對特定的操作系統、數據庫，向上架構起ABAP運行平臺。大家可以看到，Kernel面向機器層，幾乎不需要定制化，并且對性能有要求，是C語言編寫，屬于不開放的代碼模塊；而應用層是ABAP語言編寫的，面向業務定制化多，屬于開放的代碼模塊。
所有的ABAP程序都駐留在SAP數據庫里，不像Java或者C++程序那樣存儲在單獨的地方。從這個角度上來看，SAP的系統更像是一個基于數據庫層面的應用操作系統，實現了代碼、數據庫和應用的很好的整合。當你在SAP的系統里查看代碼的時候，系統從REPOSRC等數據庫表中讀取源代碼，然后調用產生動態的代碼并運行。如果源代碼改變了或者數據庫結構發生了改變，下次運行的時候就會自動生成新的代碼。ABAP作為一種開放的腳本語言，解決了很多應用上的難題，例如熱更新、版本管理等。
傳統的軟件設計里，代碼、編譯后的應用和數據是分離的，但是在SAP的ERP里，這三種對象很好地組合在一起。另外一個實現了數據、代碼和應用的統一的應用，應該是以太坊的智能合約，不過以太坊每秒的交易吞吐量不到50。
因為ABAP業務層代碼的開放，第三方的服務商可以發揮自己的聰明才智提供各種解決方案，ERP平臺里的各種BUG、問題可以在客戶或者合作伙伴那兒找到并解決，充分發揮生態的力量。如果一個應用系統是封閉的，那么創新和問題的解決都只能依賴廠商，生態參與的力度和專業性也會跟原廠有很大的差異度。但是原廠很難以自己的資源來覆蓋那么多國家和行業的不同客戶，很容易出現管理上的“規模不經濟效應”。整個SAP的ERP生態圈可以看成是一個開放的社區，大家一起建設，來對抗大型應用軟件的復雜度。
架構的優缺點討論
歷史上SAP內部也有很多關于ABAP架構和Java架構的爭議，也有非常精彩的故事。
在2000年互聯網泡沫巔峰時期，PC客戶端交互為主的ERP企業軟件受到互聯網的網頁端應用的挑戰，經常被互聯網的競爭對手發出“ERP已死”的言論沖擊。2001年4月，SAP以4億美元收購了以色列技術天才夏嘉曦（Shai Agassi）創立的TopTier，收購后的TopTier更名為SAP Portals，一個以Java技術框架為主的門戶網站產品。2002年4月，加入SAP才一年，夏嘉曦成為SAP全球執行董事會里最年輕、也是第一位非德國籍的成員，負責SAP的產品和技術團隊，他也是SAP歷史上第一次任命的CTO，一度被認為是最有潛力的CEO接班人。在那段時間里，SAP的未來架構設計一直在ABAP和Java之間搖擺。不過在2007年，由于SAP全球首席執行官孔翰寧的任期延長至2009年，希望能接CEO位置的夏嘉曦不打算等待聯席CEO的位置，在他2007年從SAP離職后，ABAP的架構又成了SAP主要的方向。
現在復盤來看，夏嘉曦的離職結束了SAP在架構方向上的搖擺。Java當時主要是IBM、Sun和Oracle主導的技術，后來在2009年，Oracle通過收購Sun公司獲得了Java技術的主導權，假如SAP此時還在搖擺中，那么很可能會陷入被動。在面向全球的復雜的私有部署企業軟件里，ABAP可能是當時最合適和最可靠的架構引擎。
個人認為，SAP 經典ERP的架構有如下優缺點：
優點：
1.應用中的Basis層面向機器層，容易找到最優解，無需定制化，不用開放代碼，結構穩定。閉源的Kernel層可以保障軟件的商業價值得到支付，例如許可管理等。
2.應用中的ABAP層面向企業業務，可以由第三方完成各種定制化開發，利于生態發展，能夠很好地適應國際化和各行業的復雜應用定制，鼓勵第三方和自由顧問的創新以及解決問題的主動性。
3.代碼、應用和數據一體，支持代碼熱更新、運行時動態調試等，系統升級容易。開發測試生產體系完善，不需要復雜的Devops體系，不需要額外的IDE、Git、Github、Profiling工具，統一集成在一個技術平臺里。
4.壽命長的應用代碼可維護性好，很多ABAP應用運行了幾十年還可以繼續發揮作用，接手的團隊也很容易處理。
5.復雜的系統問題很容易跟蹤和解決，有非常好的體系化的工具和方法論，客戶的各種需求和問題會及時反饋到產品里，積累成最佳實踐。
6.分層設計優秀，數據、代碼、配置，開發和業務容易實現統一，大部分需求可以靠業務顧問通過配置完成，積累最佳實踐逐漸迭代成一個偏向業務的低代碼平臺。
7.系統設計嚴謹，大部分修改都會留下痕跡，深得第三方審計機構的信賴。
缺點：
1.ABAP腳本語言在性能上不及Java和C語言，比如同樣一個Loop循環要慢很多倍，這樣的架構設計確實不適合互聯網行業所需要的高并發高性能。一些對性能要求高的應用需要調用外界的專業程序或者是數據庫的Procedure來加速。
2.原廠開發的代碼過于透明，一些質量不佳的代碼容易被吐槽。（還好我之前寫過的一點注釋是用英文名留下的）
3.大部分生態合作伙伴只能靠服務來賺取利潤，很難靠在ABAP平臺上發布第三方的獨立應用來賺取利潤，畢竟ABAP代碼是透明可見的，跟現在SaaS平臺流行的應用商店模式有很大的區別。當年可能有些咨詢公司會通過復制一套代碼或者配置用于客戶不同省份的分公司來賺取多份利潤，在信息透明的今天，很難這樣操作了。有產品想法的服務商最終可能會做自己獨立的產品線，比如漢得。
4.技術架構自成體系，ERP開發工程師的供應有限，高質量的ERP開發需要懂得業務，門檻也比普通的應用開發工程師高，如果有一個敏捷跨技術棧的需求，或則是沒想清楚的業務需求，實現起來成本會比較高。
因為Kernel和ABAP這樣的封閉和開放架構設計，SAP的ERP系統有著非常鮮明的優缺點。不過針對企業應用這個領域，總體來講還是優點多于缺點。
總結和展望
在私有部署的時代，基礎和應用的分層架構的設計使得SAP的ERP產品保持常年的競爭優勢，并且在多個國家多個行業逐漸積累最佳實踐。雖然最近十年企業的ERP軟件也受到互聯網產品、云計算和SaaS產品的沖擊，基于ABAP的架構上建立的護城河也被新的技術挑戰。但是ERP的場景畢竟跟互聯網的場景不同，偏企業內部應用的ERP軟件因為企業的員工數量有限（即使是大型企業用戶一般也少于10萬人），基本上不會碰到應用和數據庫的架構瓶頸問題。
分布式數據庫的技術團隊可能會覺得區塊鏈的性能不能滿足高并發高性能的要求，但是很少有人會去挑戰比特幣和以太坊的架構設計。SAP的經典ERP架構持續了三十多年基本沒怎么改變，針對適應它的場景，競爭對手還并不多。即使是跟SaaS軟件相比，SAP的經典ERP架構目前還是能保證非常靈活的定制化。今天很多互聯網公司號稱用"中臺"取代大部分行業的ERP，很多時候只是在用不同的場景在做牛頭不對馬嘴的混淆，架構設計都是在做取舍，很難有完美的架構。
當然，我個人還是對未來的ERP架構有一些期待——
1.能夠支持開源的分布式數據庫，降低使用成本，進一步增強系統高可用性。
2.能夠與未來的數字貨幣體系相結合，可以把資源管理的體系變成價值管理的體系。
3.能把面向企業內部管理的ERP和企業外部的應用、資源更緊密地結合起來，比如企業上下游。
4.架構適應應用商店，第三方應用能夠有商業上的收獲，進一步擴大生態圈。
