企業IT架構的近十年，對很多從業人來說是困惑的十年，伴隨著企業數字化轉型火熱的10年，企業IT架構的方向似乎在互聯網巨頭身上看到了曙光，卻又在實踐中跌落神壇。理念的璀璨，實踐的黯淡，最早在企業實踐互聯網技術的CIO或CTO們，是否還保留著心中的白月光，亦或是早已迷失，無奈回到最初的起點。
數字化轉型這一概念最早在2012年由國際商業機器公司（IBM）提出，它強調了應用數字技術重塑客戶價值主張和增強客戶交互與協作的重要性。此後，數字化轉型逐漸從企業（組織）層面上升爲國家戰略。在中國真正數字化轉型的元年，我認爲是在2015年。標志性的事件就是阿裏巴巴提出中台概念，它從組織架構、業務架構、IT架構多個維度對企業産生了影響，激發了企業的CXO對“敏捷響應，低成本的快速創新”的熱情。在IT架構方面，受中台架構的理念影響，企業已經不滿足從單個領域的需求出發，開始思考如何一站式、一體化、一套標准的方式去踐行。阿裏在推動新一代企業IT架構的思潮，有著積極的意義，但遺憾的是它在過程中沒有真正起到作用，更多的是從商業收益角度出發。下圖是當時比較流行的企業IT架構發展趨勢圖。
作爲身處這個飛速發展時代的親曆者，筆者有著深切感受和思考。在2008-2015期間，我在阿裏巴巴淘系和天貓做核心交易鏈路和導購鏈路的架構，後面是菜鳥網絡的總架構師，可以說我完整的經曆了互聯網架構的完整演進過程，知其然也能知其所以然。在2017-2019年初，在阿裏雲負責中台對外輸出工作，積累了大型企業的IT服務經驗，對企業數字化轉型有了深度思考。2019年至今一直從事企業數字化轉型領域關于企業IT架構方面創業。本文我會分享自己的一些關于“新一代企業IT架構”發展的思考，期待對大家有一定啓發。
在2015年前，因爲互聯網高速的發展，企業數字化轉型的需求或痛點實際上已經積累到了一定程度。當時中台僅僅只是一個概念，根本沒有任何技術標准可言，卻非常的火，只能說當時企業IT架構面對數字化的挑戰時確實苦無良方。經過2016年阿裏對中台鋪天蓋地的宣傳後，2017-2019間引來國內企業IT架構中台化改造的頂峰。伴隨這個瘋狂的過程，不管阿裏內部還是外部都開始有質疑聲音出現。
其實在2016年時就有迹象，因爲阿裏作爲一家生態公司，基本上是帶著合作夥伴來給企業交付，基本上都做得不好，甚至失敗。但非常輕易地把原因直接歸結于“由于夥伴對互聯網技術的理解和能力”。
因此在2017年，阿裏成立了原生交付團隊，希望能夠樹立一些標杆案例。我和公司的核心成員也都來自于這個團隊。17-18年做下來，我發現阿裏也做不好，但這次做不好的原因不是技術不行或項目上不了線，而是上線以後預期的效果沒有達到，其本質是企業的IT組織能力無法駕馭複雜的互聯網中台架構。當無法駕馭的時候，所謂的目標“敏捷響應，快速創新”就無從說起了。結果客戶會反饋以下三類問題：
不是說敏捷響應嗎？爲什麽改個需求這麽慢，不但時間更長，付出的成本也更高了？不是說能力中心嗎？當引入新供應商或有新場景開發的時候，爲什麽前期做的能力中心不能支撐了？不是說性能好嗎？爲什麽我投入的物理資源更多了？關于這三個問題我們都能很容易找到原因：
第一個原因是因爲中台架構需要一定的技術能力和經驗才能有效地應用，就像一個只會騎自行車的人給他一輛汽車或者飛機，他也不能駕馭它們。微服務對研發、調試、運維的各個方面要求都有一定提升了，但企業的IT技術能力卻沒有跟上。
第二個原因是因爲能力中心是一種面向業務的能力組織方式，它將不同的業務能力抽象出來，以服務的形式對內提供。然而，由于業務場景的差異，不同的業務需要的能力也會不同，因此能力中心需要不斷叠代和升級。對于新引入的供應商或新場景開發，需要根據實際情況對能力中心進行定制化和擴展化，但誰來負責呢？新項目的供應商還是客戶自己？
第三個原因是因爲中台架構采用微服務來解決單點瓶頸問題，提高系統性能和可用性，但是在初始階段，投入的資源可能會更多。每個模塊至少需要兩個實例來保障高可用性，因此物理資源的投入量可能會比以前更多。
原因找到了，但是方案在哪裏？在巨大的利益面前，軟件廠家都選擇忽悠，雲廠商選擇縱容，一起開始極限耍流氓。
雲廠商在這個模式下不但賣出了更多的雲資源，同時賣出了配套的運維工具。縱容軟件廠商告訴企業：“中台是持續演進和快速叠代的過程，因此企業需要組建中台架構團隊來實現，而他們則通過中台項目落地將中台建設方法論傳授給企業。”這句話的前半部分是正確的，因爲我們之前提到企業需要具備敏捷響應業務的能力，即應變能力，因爲應變是不斷變化的。然而，後半部分是不正確的，因爲今天的企業已經有能力組建團隊的話，那麽這些中台軟件公司到底有什麽用呢？企業真的缺少方法論嗎？
這種行爲基本上算是在向企業收取智商稅，都在欺詐，因爲很多企業根本找不到足夠懂互聯網架構的人才。明白流氓在哪裏了嗎？這些流氓公司賺了很多錢，最後責怪企業無法招到人才，這是企業的責任。
二、2020年至今，是新一代企業IT架構，逐漸去除“中台崇拜”跌入谷底的過程，是進入理性反思尋找方向的過程。在逐漸去除“中台崇拜”和進入理性反思尋找方向的過程中，發生了有兩個標志性事件，以及一個趨勢逐漸形成。
第一個標志性的事件是：2020年1月18日一篇36氪出的文章【中台，我信了你的邪】，其中大量描述了中台項目失敗導致CIO離職、背鍋的現象。1月18日在當時也被戲稱“中台”曆史上最“困難”的一天。面對這篇文章的論點，有悲觀的，也有樂觀的。我屬于樂觀派，我一直認爲“敏捷響應，低成本的快速創新”，一定是企業數字化轉型的核心訴求。但支持該目標的新一代企業IT架構，肯定不是照搬照抄互聯網大廠的經驗。
第二個標志性的事件是：2023年5月9日一篇國外的文章【從微服務轉爲單體架構、成本降低 90%】，該文章的意義在于，激勵從業人員敢于反思當下主流技術的不足，同時它揭開新一代企業IT架構應該如何應對企業數字化轉型時預期與現狀的矛盾，客戶在數字化轉型的項目時，對未來的預期非常高，因爲這個時代有太多一夜成名的企業，當一個國民品牌的産生的時間從20-30年變成現在的2-3年。那麽性能的擴展性，就是IT架構不得不考慮的事情。所以在我們思考新一代企業IT架構時，能否更進一步，即能滿足客戶對未來的發展預期，有兼顧當下的成本效應。
一個趨勢逐漸形成，不論從輿論、實踐，企業逐漸開始去除“中台崇拜”，回歸對目標的思考。如何做到“敏捷響應，低成本的快速創新”，呈現出了不同的方式。我們來看看現在企業IT構架的幾種方式，從中總結經驗找到適合數字化時代的新一代企業IT架構。主要包括受中台影響深遠的盲從派、觀望的保守派，以及獨立思考派。
他們基本上是頭痛醫頭的典範。套裝軟件不合適，咱們就外挂系統。每個外挂系統都要跟套裝軟件集成或者外挂系統之間集成，導致接口混亂重複開發，就搞個集成平台對接口進行資産化、規範化、標准化管理。主數據在各個系統中不一致，則構建一個主數據平台統一主數據管理入口，通過主數據平台進行數據的管理與分發。既然稱之爲保守派，只是緩解了部分管理問題，但無法解決企業對“敏捷響應，低成本快速創新”的訴求。以及一些根本的弊端無法得到根治。
每個外挂系統，自成一體。系統企業接手很困難，特別現在每個外挂系統都是基于互聯網架構，但各自又因爲技術標准、數據標准不一致，形成了互聯網式的煙囪，導致接手和運維難度相對傳統的單體應用要更大。應用之間數據割裂，相同數據需要多次同步，保存多份。無形中加大成本。一個業務流程可能涉及多個供應商開發，每個應用只能依賴原有供應商，但凡有個別供應商反應不及時，影響整體效率。（2）激進盲從派他們認爲企業碰到的問題跟互聯網在架構演進過程中碰到的問題非常類似，基本照搬照抄互聯網架構。這裏還是拿阿裏舉例子。
(圖阿裏架構變遷史)
在2009年，淘寶上線了五彩石項目，這標志著淘寶從單體應用向服務化應用的時代邁出了一步。那麽，淘寶爲什麽要開發五彩石項目呢？因爲當時淘寶面臨兩個非常嚴峻的問題，一個是性能問題，數據庫連接不足，數據庫成爲了瓶頸；另一個是效率問題，當時淘寶有百余個研發人員，但核心系統只有一套測試、預發、線上環境，導致研發需求排隊等待。在開始五彩石項目之前，淘寶還做了千島湖項目，用來驗證服務化架構的可行性，將用戶中心獨立出來。隨後，淘寶開啓了五彩石項目，目標是通過增加人力來提升效率，通過增加機器來提升性能。
隨著淘寶的業務發展，他們又面臨了一個問題：各個服務之間有很多重複的建設，效率低下。爲了解決這個問題，淘寶開始從服務化轉向平台化，並創立了“共享業務事業部”，將重複建設的公共業務分配給這個事業部，以避免成本浪費。這些公共業務包括商品平台、交易平台和結算平台等。平台化的目標是規避服務化沒有規劃導致的重複建設問題。
但是隨著業務的快速發展，淘寶變成了一個擁有幾十個事業部的巨型企業，而這帶來了新的問題：效率問題。例如，如果需要在一個業務線上做出改動，需要與十幾個平台進行溝通，這是非常低效的。同時，對于一個平台來說，需要面對來自不同事業部的需求，這需要平台研發人員具備理解和抽象所有業務線需求的能力，這讓平台研發人員感覺回到了單體應用時代，所有的需求都要排隊，即使增加人力也無法提高效率。這個問題主要表現在交易平台上。
爲了解決這個問題，淘寶提出了中台的概念，中台是在一套規範下建立的，讓具有專業技能的團隊自主決策業務系統發展的平台。中台的目標是弱化平台的業務特性，提供通用能力。簡而言之，就是將“共享業務”中的“業務”兩個字去掉，只提供通用能力的平台
我們將每個階段的核心目標總結爲一句話：
從單體到服務：通過增加人員和機器來提高效率和性能；從服務化到平台化：解決服務化階段因缺乏規劃而導致的重複建設問題；平台化到中台化：在一套規範下，讓各業務團隊自行決定業務系統發展，適用于多個業務線或多個場景應用的獨立發展。類似地，在企業數字化轉型過程中，也面臨著類似的問題：
隨著企業業務在線化，對系統性能和穩定性提出了更高的要求，但由于內部系統之間的割裂，導致很多重複建設。因此，我們需要進行服務化和平台化；在數字化時代還沒有出現一個供應商能夠解決企業所有的商業場景問題，所以需要多個供應商共同參與。我們可以將供應商類比爲各業務線，在一套規範下讓供應商或業務線自行決定業務系統的發展。然而，阿裏的中台架構方案並不能直接照搬到企業中。因爲阿裏的中台架構采用了平台共建模式，即讓業務線基于平台設計的規範共同開發。這本質上還是平台主導模式，對企業來說曆史包袱較大。在企業中，讓不同背景的研發一起共建交易或商品平台是非常複雜的事情。平台化已經足夠複雜，再加上共建會導致企業架構的負載過重，這對企業來說就不再是賦能，而是“內耗”。
同樣只要我們稍加思考，企業面臨的效率問題跟互聯網面臨的效率問題也是有本質區別的。
企業因爲IT組織能力無法與數字化轉型的速度匹配，缺乏足夠的人才支持。企業需要尋找工具和技術來降低開發難度，同時提高個人開發效率。阿裏擁有衆多優秀的人才，需要解決團隊協作和知識共享的問題，即協同開發的效率。（3）獨立思考派1.發掘訴求的本質根源
隨著互聯網的發展不斷推動企業業務在線化，我們發現數字化時代，企業在以下三個層面發生了質的變化：
首先，從競爭環境來看，企業競爭已經超越了單一企業的範疇，轉變爲整個價值鏈網絡的競爭。這意味著企業不再僅僅關注自身的發展，而是需要與上下遊夥伴緊密合作，共同應對市場競爭。
其次，在業務建設內容方面，企業不再局限于內部管理，而是更加注重業務在線化和生態在線化（協同）。這種轉變旨在支持現有業務的發展，並爲企業未來的業務創新賦能。同時，這種轉變也能夠將企業內部的變化實時地反映到整個價值鏈網絡中，促進整個生態系統的協同發展。
最後，從技術變革的角度來看，對技術提出了更高的要求。特別是在需求響應速度、用戶體驗、系統極限承載力以及智能化等方面的提升，以應對市場的快速變化和持續創新的需求。可以看出對研發人員的需求量大幅增加，同時對他們的要求也變得更加嚴格和高標准。
因此，在數字化轉型過程中，企業需要綜合考慮全鏈路業務解決方案的成熟度以及數字化場景的快速變化和持續創新訴求。只有這樣，企業才能在激烈的市場競爭中立于不敗之地，實現可持續發展。
2.思考問題的解法
在這裏也分享下筆者的思考，而且這些思考跟獨立思考派溝通完以後，有著不默而合的默契。在2017年-2018年在做中台對外交付項目的時候，覺察到了兩個核心問題：
絕大部份企業的IT組織能力無法駕馭複雜的互聯網架構。中台概念推動新一代企業IT架構的思潮，有著積極的意義，但遺憾的是它在過程中無法真正起到作用。作爲軟件公司，這類項目實施落地對人員要求極高，根本無法複制。當時之所以會面臨困境，我主要有三個方面的反思：
我們不應該依托于提升研發人員的能力，而是降低互聯網架構的門檻。我們不應該只是輸出中台方法論，而是把方法論固化到技術平台中去。我們不應該只能服務大企業，而是真正賦能不同IT組織能力的企業，讓它們都具備持續創新的能力。企業需要構建，適應“數字化場景的快速變化和持續創新訴求”的數字化底座，它必須囊括技術標准、數據標准、應用標准，這些標准不應該只是停留在方法論層面，而是固化到平台中，以平台特征能力的方式提供支持，做到跟單一研發人員無關。
技術標准：滿未來軟件特性，同時所有特性由平台自動提供，跟單一研發人員能力無關。不改變研發人員習慣的前提下，提升研發人員的效率，降低研發難度。能夠讓專業研發與公民研發共同參與，專業研發專注核心業務平台的研發與叠代，公民研發可以參與臨時性或者應急需求的開發。數據標准：建立XX集團數據標准，提供開箱即用的業務數據庫。同時提供上層業務層基于標准數據的擴展能力。應用標准：通過前端交互規範建立應用集成門戶，和體驗一致的交互標准。同時建立應用管理運維規範。三、新一代企業IT架構應關注哪些特性在數字化時代，在新一代企業IT架構領域都關注哪些特征，而這些特征又應與具體研發人員的個體能力無關。我將從在軟件工程、架構與技術的組合應用上，給出我的思考，這裏主要介紹特征與用途。
先做個名稱解釋，下文中涉及“標品”、“升級”、“擴展邏輯”，這是站在軟件公司角度出發描述的，如果是企業內部可以把標品理解爲特定業務應用平台，升級則是業務應用平台的正常規劃叠代，擴展邏輯理解爲脫離平台發展的臨時性需求。
（1）可逆計算
（可逆計算在應用上的特征圖）
調查發現企業研發至少有40%的精力在跟各條業務線的團隊在評審項目需求，判斷需求是否合理。而且業務線對需求完善時間要求緊，每天盯著研發進度，經常問“這個需求什麽時候支持，我們等著用”。導致産研部門的研發抱怨産品節奏亂，無法按照自身節奏進行叠代，被項目推著走，沒有時間思考，人手不足，加班多，工作壓力大……
該特性很好的規避了研發因爲時間緊迫，寫的一些臨時代碼腐蝕核心業務系統。它需要做到不論從數據模型、業務邏輯、交互展示都能有擴展能力，並且這些擴展能力與個體研發無關才行。它同時所描述的也是一個具備差量計算能力的軟件架構模式，它允許用戶通過添加或移除擴展包來定制標准應用，同時保持應用的可逆性和獨立性。這種架構模式的核心優勢在于其靈活性和可維護性，使得應用的定制和恢複變得簡單而高效。
（2）專業研發與公民研發共同參與
（專業研發與公民研發共同參與在應用上的特征圖）
它所描述是在應用開發的整個生命周期中，專業研發專注在標品的長期規劃與叠代，當出現臨時性的需求或者應急性的輔助場景則由非專業人士進行即公民研發方式進行。這種模式下，專業研發可以按照規劃有節奏的叠代産品，做更高級的事情，不至于忙于應對臨時性的事務沒有深度思考，更加避免了因爲臨時代碼堆積導致産品從內部腐化。同時利用獨立的擴展邏輯包和無代碼方式解決了業務的緊迫感，畢竟業務需求的合理性是很難爭論出高低的。它在第一個特性基礎上讓研發效能進一步得到釋放。
它本質是：在專業研發在以低代碼的方式下實現應用，並通過無代碼的方式，快速擴展邏輯功能和創建輔助性應用。整個過程無縫銜接，我們給他取個名字專業名稱叫：“低無一體”。它大大降低了技術門檻，使得專業和非專業的研發人員都能參與到應用擴展和定制中來。此外，它還提高了業務響應能力，使得企業能夠更快速地適應市場變化和客戶需求。
（3）基于平台級別的AOP能力出現反向集成
（反向集成在應用上的特征圖）
平台級別的AOP（面向切面編程）能力允許開發者在應用程序的特定點“切入”額外的邏輯，而無需修改原有的業務代碼。這種能力特別適用于橫向追加平台邏輯，即在多個不同服務或功能點插入通用的處理邏輯，如日志記錄、權限檢查、審計、多租戶、多語言等。過往在微服務架構中，這些能力都需要業務系統各自主動去對接，有了平台級別的AOP能力，則這些通用能力可以反向爲所有業務系統增加特性能力，無需業務系統研發感知。這種現象我們稱之爲“反向集成”，能讓業務研發更加專注在業務研發本身，不需要關心與業務無關的通用功能上。
AOP的核心思想是將這些橫切關注點（cross-cutting concerns）從業務邏輯中分離出來，使得業務代碼更加清晰和專注于其核心功能。在平台級別的AOP中，標准化協議是實現這一能力的關鍵。平台具備統一的入口和擴展能力是非常重要的，因爲它允許開發者在不修改現有代碼的情況下添加新功能或修改現有功能的行爲。這種能力對于快速響應業務需求變化、減少維護成本和提高代碼質量都是非常有益的。
（4）應用研發與部署無關
應用研發與部署無關的理念確實爲現代軟件架構帶來了顯著的優勢，它使得研發團隊能夠專注于業務邏輯和功能實現，而無需擔心具體的部署細節。這種分離帶來了靈活性、效率以及成本效益的多重提升。
首先，應該可分可合的能力使得系統能夠靈活應對業務量的變化。在業務量小的時候，可以采用單體部署的方式，簡化部署流程，降低初期成本。隨著業務量的增長，系統可以平滑地過渡到分布式部署，通過拆分微服務來提高系統的處理能力和擴展性。這種靈活性確保了系統既能滿足未來發展的需要，又能兼顧當下的成本效益。
其次，應用級別擴容的能力使得系統性能不再受限。通過增加微服務實例或調整資源配置，系統可以按需進行擴容，從而確保在業務高峰期或突發流量下仍能保持穩定的性能。這種按需擴容的方式不僅提高了系統的可靠性，還降低了運維成本。
四、引入CDM層讓數據標准不在是文檔這裏我們借鑒微軟的CDM理念，CDM這個概念最早是2016年微軟宣布“以Dynamics 365的形式改造其CRM和ERP”戰略時提出的。微軟給它的定義是“用于存儲和管理業務實體的業務數據庫，而且是開箱即用的”。CDM不僅僅提供標准實體，它還允許用戶建立個性化的實體，用戶可以擴展標准實體也可以增加和標准實體相關的新實體。
CDM可能並不性感，但絕對是非常必要的。它成爲了微軟的很多産品的基礎，是構建了無數業務領域的原型。同時微軟也期望它能成爲快速實現數據交換和遷移的標准，這個有點像菜鳥網絡推出的奇門，讓所有TMS、OMS、WMS都基于一套數據接口API進行互通，一套標准是爲了解決一個行業問題，而不是具體某一個企業一個集團的問題。 我們發現CDM的理念跟我們想要的“企業級的數據標准”是非常吻合的。但是我們也不能照搬照抄，雖然微軟的CDM很好的解決了數據割裂問題，但就模型來說就夠大家喝一壺了，模型庫非常龐大而且複雜，學習成本巨高。
（1）數字化時代軟件會産生新的技術流派我們知道傳統軟件的設計理念：側重在模型對業務支撐全面性上。優點體現爲配置豐富，缺點模型設計過于複雜，剛開始有前瞻性，但在理解、維護都非常困難，隨著業務發展系統原先的設計逐漸腐化，異常笨重。 而新一代的企業IT架構的CDM設計理念：側重在簡單、靈活、統一上，體現爲在上層應用開發時，每一業務領域保持獨立，模型簡單易懂，並結合未來軟件特征中提到的低代碼開發機制進行快速開發，靈活應對業務變化。 所以我更想說新一代的企業IT架構中描述的CDM是在微軟CDM的原有基礎上，與互聯網架構結合，利用低代碼開發平台特性形成新的工程化建議。它不以“把模型抽象到極致，支撐所有業務可能性”爲目標，而是抽象80%通用的設計，保持模型簡單可複用，來解決數據割裂問題，並保持業務線獨立自主，快速創新的能力。
引入CDM以後系統工程結構會有什麽變化，跟大家認知的互聯網架構有什麽區別。
原本上層的業務線系統，需要調用各個業務平台提供的功能，增加CDM以後也就是我們右的圖，每個業務線就像一個獨立右邊。看上去複雜了，其實對業務線來說更加簡單了。
互聯網整體平台化帶來的問題：
1.業務線每次業務調整都需要給各個平台提需求
2.業務平台研發需要了解所有業務線的知識再做設計，對研發要求非常高
3.各個業務域的不同需求相互影響包括系統穩定性、研發對需求響應的及時性
結合低代碼特性提出的新工程建議：
1.一些通用性模塊繼續以平台化的方式存在，能力完全複用。
2.業務線自建業務平台，保持業務線的獨立性和敏捷性
3.業務線以CDM爲原型，保證核心數據不割裂，形成一致的數據規範
互聯網整體平台化
引入CDM層的新工程
該示例中CDM的商品域不僅僅提供標准實體，保證各個業務系統的對商品的通用需求、簡單易懂，在業務産品中如全渠道運營、B2B交易等系統以此爲基礎建立屬于自身個性化的實體，可以擴展標准實體也可以增加和標准實體相關的新實體。
帶來的好處：
1.通過多種繼承方式，繼承後的模型可擴展模型本身、模型行爲等，從而解決業務獨立性問題。
2.通過CDM層統一數據模型，從而解決多應用數據割裂問題
Gartner的預測：到2024年，所有應用程序開發活動當中的65%將通過低代碼的方式完成。低代碼在細分領域的差異化需求將被重構，複雜、核心業務場景的個性化叠代特性對低代碼需求越來越高。在前文提到，“技術變革的角度來看，對技術提出了更高的要求。特別是在需求響應速度、用戶體驗、系統極限承載力以及智能化等方面的提升，以應對市場的快速變化和持續創新的需求。可以看出對研發人員的需求量大幅增加，同時對他們的要求也變得更加嚴格和高標准”。那麽低代碼是解決該問題的核心手段，數字化化時代低代碼應該具備應對複雜多變的場景能力。
要打造新一代企業IT架構，至少需要從四個維度在展開：
第一層：是以低代碼研發平台爲基礎輸出互聯網架構下的軟件快速開發標准，在這一層我們需要封裝互聯網的高並發、大數據的能力，並且針對這些跟業務無關的基礎功能提供標准化實現，讓上層的應用研發專注在業務本身上。在這次一層讓所有的技術標准都固化到研發平台，我們關注的特性都由低代碼研發平台去承接，從而做到與個體能力無關。
第二層：是通用數據模型層，如果第一層輸出的技術標准，那麽這一層輸出的是數據標准的實現方式。滿足不同軟件基于一套數據標准的擴展能力。
第三層：是業務應用層，在這層我們要支持內外部共同參與。
第四層：是無代碼設計器以及應用市場，由非專業人士進行即公民研發利用無代碼設計器來滿足臨時性的需求或者應急性的輔助場景。應用市場上管理會包括所有自建、第三方、以及無代碼應用。
總結來說新一代企業IT架構，需要開放式地讓企業自身以及不同的軟件供應商共同參與，遵循相同技術、數據規範，打造一體化無需集成的企業級各類軟件。
（1）技術路徑選擇，诠釋低代碼新模式我們不會與其他無代碼平台進行比較，因爲它們不能解決業務複雜性的問題。相反，我們將重點介紹三種不同的低代碼平台模式。
第一種模式是最基礎的低代碼平台，也被稱爲代碼生成器。它通過預定義應用程序模板和必要的配置生成代碼，簡化了工程搭建並提供了一些基礎邏輯。雖然在信息化時代內部流程標准化方面較爲適合，但在數字化時代外部協同業務在線的情況下就不那麽合適了。因爲這種模式不能減少研發難度和提高效率，也無法體現敏捷叠代快速創新的優勢。
第二種模式是經典的低代碼平台，以元數據爲基礎，以模型爲驅動。當無法滿足需要時，通過特定方式將代碼以插件的形式注入平台，作爲低代碼平台的內置邏輯，供設計器使用。它的優點在于降低了研發門檻，當無法滿足需求時才需要編寫代碼。它可以實現企業內部的複雜流程和複雜邏輯，但其性能和工程管理存在局限性。性能問題使其不適合處理互聯網化的在線業務，而工程管理問題則使其不適合處理快速變化的業務。這也是許多研發人員反對低代碼的核心原因之一，因爲研發人員變成了輔助角色，而軟件工程是一門需要技術能力的學科，讓沒有技術能力的人主導是違反常理的。對于産研來說，産品需要叠代規劃，需要多人協作，需要工程化管理。
第三種模式是由數式Oinone提出的基于互聯網架構的低代碼平台，它采用無一體的設計。首先，數式Oinone屏蔽了互聯網架構帶來的複雜性。其次，同樣以元數據爲基礎，以模型爲驅動，但是元數據的生成方式有兩種：一種是使用無代碼設計器（與經典低代碼相同），另一種是通過代碼來描述元數據。通過使用代碼來描述元數據，可以無縫地與代碼銜接，並在不改變研發習慣的情況下降低門檻、提高效率，並進行工程化管理。
最後總結來說：低無一體不僅僅是指兩種模式的結合，還包括兩種模式的融合應用方式。具體來說，這種融合應用方式可以分爲兩種情況：
當開發核心産品時，主要采用低代碼開發，無代碼設計器作爲輔助。這種方式可以提高開發效率和代碼質量，同時保證産品的快速叠代和升級。當需要滿足個性化或非産品支持的需求時，主要采用無代碼設計器，低代碼作爲輔助。這種方式可以快速地滿足客戶需求，並且避免對産品的核心代碼産生影響。簡單來說，低代碼模式適用于産品的叠代升級，而無代碼設計器則適用于滿足個性化和非産品支撐的額外需求。低代碼和無代碼模式在整個軟件生命周期中都有各自的價值，在不同場景下可以相互融合，發揮最大的優勢。
（2）新一代企業IT架構，落地選型方式1.新一代企業IT架構的供應商應該具備以下核心能力：
