—

企業級IT服務作爲長期賽道，需要長周期的陪伴和資源投入。

來源  /    人月聊IT  

作者 /     何明璐   

這個周末我去參加了2021年華南CIO大會，發現基本上每年大會都有一個熱點，比如今年的熱點就是低代碼开發平台。

我們可以回顧下最近幾年的熱點變化。

17-18年：微服務

18-19年：中台

19-20年：RPA，數字化營銷

20-21年：低代碼，雲原生

就我自己的文章輸出來看，基本上也和這個大趨勢符合。比如我17年左右會更多地寫微服務架構設計和實施方面的文章，18、19年輸出了不少關於中台建設的文章。

而最近幾年關注重心則是雲原生整體解決方案和低代碼开發平台。

在IT行業，各種新興技術層出不窮，互聯網大廠的各種造詞能力也相當強大，也讓每年基本都有新熱點和新技術產生。

類似19年可能剛興起低代碼开發，而到了今年可以看到做低代碼平台的各種廠商，不論是做SaaS服務的，還是傳統ToB實施的，還是圍繞騰訊，釘釘生態的。

估計至少有上100家企業在做低代碼方面的產品。導致低代碼整個行業也處於羣雄逐鹿和混亂的局面。

在上半年，ThoughtsWork的徐昊寫了一篇文章，談到低代碼平台是行業毒瘤，首先這個看法我個人不認同，任何新事物都有其存在的價值和道理，也不可能去解決你所有的問題。而是應該在合適的時候採用最合適的方法。

低代碼平台本身是好東西，但是很多廠商將低代碼平台吹噓來無所不能，再復雜的系統和規則都能夠零代碼，拖拖拽拽就實現，這就是完全不講武德了。

所以低代碼平台不是行業毒瘤，反而是廠商競爭中的信口开河和瞎吹噓才是行業毒瘤。

回顧下中台的概念也是同樣的道理。

中台本身是一個很好的概念和思想，強調將企業共性業務能力下沉，然後形成可復用的業務能力中心提供給上層應用，讓上層應用能夠靈活敏捷的去开發。

這個思路本身沒有任何問題。

但是很多做中台的廠商，特別是很多互聯網出來創業的廠商，一味地去誇大中台的作用，給企業畫大餅，搞個中台就無所不能，企業原來已有的IT系統也要全部改一遍，去建大而全的中台能力而不是考慮如何保留企業遺留IT資產。

這些也導致了大量的中台項目最終建設失敗，或者根本沒有起到預想的效果。

這並不是中台的思路不好，而是廠商誇大宣傳最終又沒有實現最終的效果和目標，導致了用戶持續大量反噬，這不能怪用戶只能怪廠商。

再回來談微服務也是同樣的道理。

倒退個3到5年，估計很多企業也被微服務搞死過。

原因也很簡單，本身一個單體應用運行得好好的，最終被拆分爲20多個微服務，導致多個微服務間集成復雜，分布式事務失控，後續的問題排查困難，運維監控困難等一系列的問題。

這本身不是微服務思想不對，而是應用不對。

其一就是企業在沒有達到一定的IT治理管控能力的時候盲目上微服務，其二就是前期的架構建模階段對微服務拆分不合理導致拆分太細，或者拆分後的微服務間緊耦合。

微服務思想本身不應該去背這個鍋。

在去年我參加華南CIO大會的時候，RPA機器人火的一塌糊塗，聽說今年有些RPA廠商或團隊已經解散。

那么RPA機器自動化這個究竟好不好？

同樣的道理，任何一個新鮮事物的存在都有其道理。RPA機器人和自動化技術整合解決了傳統業務系統底層集成困難的問題，將重復的工作自動化掉。

這個思路沒有任何問題。一定有其應用場景和應用價值。但是要意識到的是RPA更多是一個折中方案，而不是目標方案。

爲何這樣說？

如果一個甲方企業本身有能力去做底層業務系統間的數據集成和接口集成，但是你自己偷懶不做，而是通過上層RPA的思路去解決問題。那么就是一種明顯的治標不治本的方法。

一根大樹，本身底層的多個樹根應該集成和盤錯在一起形成合力，支撐上層的枝繁葉茂。但是現在底層這個樹根間集成不做了，前面在樹枝和樹葉上拉繩子，捆线條。雖然這樣可以臨時解決問題，但是最終這個樹後面越難再發展和成長，哪天突然倒下也不是不可能。

所以當我重新思考這些火熱概念後，給出一些關鍵的思考總結如下。

微服務

重申原則，就是你在沒有明確需求的情況下不要隨意去拆分微服務。

即使你用微服務开發框架，也可以不做大的拆分。

大部分企業來說，實際業務並發量都還沒有到必須要微服務化才能夠解決問題。

其次，應用擴展優先考慮傳統單體模式下的擴展方法，類似集羣擴展，數據庫讀寫分離等。也可以採用按子組織水平擴展。

中台

如果你的企業本身已經有一定的信息化建設基礎，那么構建中台的最佳做法是對已有遺留IT系統中可復用的業務能力進行梳理，基於SOA的思路來構建一個業務服務共享中心。而不是全新去構建一個中台。

對於數據中台來講，如果沒有做細粒度的微服務拆分，數據反哺業務的問題也不需要數據中台來解決，直接在業務中台或傳統遺留業務系統裏解決即可。

因此傳統企業構建數據中台，不是追求數據服務开放並反哺業務，而是數據整合後的分析和利用，思路仍然可能是傳統的BI系統構建思路。

RPA機器人和自動化

對於RPA是一個折中方案而非目標方案。當企業面臨諸多遺留系統底層接口集成困難的場景的時候，可以採用RPA方式來解決重復工作的自動化協同問題。但是在有條件的情況下，仍然還是以底層數據和接口集成爲主而非上層的界面協同集成。

RPA不要越做越大，這個後期維護將是一個大問題。一個是核心邏輯本身不清楚，一個是底層業務系統本身也處於變更的不穩定狀態。

低代碼开發平台

在低代碼平台本身的行業標準規範，成熟度沒有達到前，企業不要將核心的業務系統放到低代碼开發平台上。

低代碼平台企業可以做一些嘗試，可以將類似OA，項目管理，運維管理等偏工單和流程類的業務系統構建在低代碼开發平台上，積累相關的實踐和應用經驗。

最後就是低代碼开發平台在選擇的時候要考慮不要被平台廠商綁架的情況，任何低代碼开發平台开發完成的應用一個基本要求就是能夠脫離低代碼平台運行，並具備足夠的高可用和擴展性要求。