這個周末我去參加了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，項目管理，運維管理等偏工單和流程類的業務系統構建在低代碼開發平臺上，積累相關的實踐和應用經驗。
最后就是低代碼開發平臺在選擇的時候要考慮不要被平臺廠商綁架的情況，任何低代碼開發平臺開發完成的應用一個基本要求就是能夠脫離低代碼平臺運行，并具備足夠的高可用和擴展性要求。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。