從搜索指數(shù)來看，數(shù)據(jù)中臺有放緩的趨勢，而低代碼穩(wěn)步上升。

數(shù)據(jù)中臺大家都聽了不少，低代碼是什么？

簡單來說，低代碼開發(fā)平臺（LCDP）是一種可以通過圖形化拖拽和參數(shù)配置等更高效的方式，以更少的手寫代碼方式完成開發(fā)工作的軟件。

L代表的Low（我一直覺得應(yīng)該用Less）指的是少寫代碼。寫得少錯的少，可以讓一般的程序員也能完成高質(zhì)量的開發(fā)，減輕測試工作量，加快交付速度。

甚至，如果做到極致，成為無代碼開發(fā)平臺，那么業(yè)務(wù)人員就可以直接使用，將原來寫需求、需求溝通、需求分析、科技開發(fā)、測試、UAT、上線這一流程極大的簡化，涉及的相關(guān)方也極大的收縮。

低代碼并不是一個新概念，從Gartner Hype Cycle上可以看出，低代碼已經(jīng)經(jīng)歷了泡沫破裂期，進入穩(wěn)步爬升的恢復(fù)期。

中臺和低代碼平臺，在我看來其實本質(zhì)上都是希望解決同一個問題，即提供更快更好的滿足業(yè)務(wù)需要的應(yīng)用開發(fā)和數(shù)據(jù)服務(wù)能力。

物理世界的變化是飛快的，黑天鵝事件的突然降臨，熱點新聞的突發(fā)和廣泛傳播，監(jiān)管規(guī)定毫無預(yù)期的下發(fā)（通常是在周五）……

為了追上這些變化，業(yè)務(wù)和產(chǎn)品加班加點趕制了一份需求，經(jīng)過需求評估、討論、評審、修改，終于開始開發(fā)了，最快兩三個月之后，系統(tǒng)上線，市場也許已經(jīng)是另一番光景。

而數(shù)據(jù)服務(wù)就更慢了，首先要等應(yīng)用系統(tǒng)上線且穩(wěn)定，持續(xù)開展一段時間業(yè)務(wù)以后才能積累一定量的基礎(chǔ)數(shù)據(jù)，具備了利用這些數(shù)據(jù)提供服務(wù)的可能。

而實際服務(wù)的提供，還涉及到數(shù)據(jù)質(zhì)量、數(shù)據(jù)規(guī)范和標準、數(shù)據(jù)時效性等一系列問題，

于是，很自然的，我們需要一些工具或者機制，來填補這兩道鴻溝。

為了提升后臺數(shù)據(jù)采集、提供數(shù)據(jù)服務(wù)的速度，縮短業(yè)務(wù)/用戶獲得數(shù)據(jù)和服務(wù)的時間，壓縮獲得數(shù)據(jù)和服務(wù)的成本，同時使得數(shù)據(jù)服務(wù)更貼合業(yè)務(wù)需求，我們需要數(shù)據(jù)中臺；

為了提升業(yè)務(wù)應(yīng)用的開發(fā)速度，縮短業(yè)務(wù)/用戶獲得產(chǎn)品/應(yīng)用的時間，壓縮獲得產(chǎn)品/應(yīng)用的成本，同時使得產(chǎn)品/應(yīng)用更貼近業(yè)務(wù)需求，我們需要低代碼平臺。

所以，可以看出，數(shù)據(jù)中臺和低代碼平臺，本質(zhì)上要解決的是一類問題，就是提升終端用戶獲得服務(wù)和產(chǎn)品的效率，壓縮成本，貼近需求。

而這一切，都是為了能讓終端用戶，也就是業(yè)務(wù)部門，更好的應(yīng)對外部環(huán)境快速的變化，最終還是為了創(chuàng)造更多的業(yè)務(wù)價值。

為了解決這類問題，這不是我們第一次嘗試了。敏捷的開發(fā)方法也是為了縮短開發(fā)周期，提升開發(fā)效率，貼近用戶需求。

敏捷方法強調(diào)快速迭代，先交付一個最小可用產(chǎn)品（MVP），讓業(yè)務(wù)先用起來，能夠勉強應(yīng)付外部的變化，再快速迭代下一個版本。

同樣，也是為了快速的實現(xiàn)業(yè)務(wù)價值，我們采用的種種方法論和工具，都是為了這一目標。

那么企業(yè)架構(gòu)又是干什么的呢？

企業(yè)架構(gòu)（Enterprise Architecture）始于20 世紀60 年代，截至目前已有接近六十年的發(fā)展歷程。作為一門關(guān)鍵的IT 學(xué)科領(lǐng)域，經(jīng)過多年的發(fā)展也催生了各類廣泛應(yīng)用于各行業(yè)和應(yīng)用場景的框架與方法論工具，例如Zachman、TOGAF、DoDAF 等，這些企業(yè)架構(gòu)框架也一直作為重要的指導(dǎo)方法和工具，被應(yīng)用于各類企業(yè)和組織的頂層IT 規(guī)劃與設(shè)計。

ThoughWorks 現(xiàn)代企業(yè)架構(gòu)白皮書

在這里，數(shù)據(jù)玩家不想探討具體的企業(yè)架構(gòu)框架，而是想說說企業(yè)架構(gòu)落地的過程中，究竟解決的是什么問題。

造成產(chǎn)品和數(shù)據(jù)服務(wù)交付時間很長的原因，除了客觀的先后順序造成的時間差，還有一個核心原因就是IT和業(yè)務(wù)的溝通問題。

往小了說，IT和業(yè)務(wù)各自有各自的語言，難以在同一層面溝通，往大了說，IT和業(yè)務(wù)各有各的目標或KPI，沒法站到對方的立場考慮問題。

而企業(yè)架構(gòu)的落地過程中，要求IT和業(yè)務(wù)忘掉自己的語言，全部基于企業(yè)架構(gòu)框架的獨有語言來進行溝通，這樣，至少保證了雙方在統(tǒng)一體系下進行溝通，避免了不同“語言”之間的交互和理解偏差。

至于目標和KPI，則需要自頂向下的推動，由高層牽頭，全體配合完成一個聲勢浩大的全盤重塑。

比如建行的企業(yè)架構(gòu)落地過程，就是科技和業(yè)務(wù)坐在一起，按照業(yè)務(wù)領(lǐng)域/價值鏈、業(yè)務(wù)組件、活動、任務(wù)、步驟的五級建模方法論，重新梳理流程、產(chǎn)品、數(shù)據(jù)和用戶體驗等領(lǐng)域。

本質(zhì)上，是創(chuàng)建了一種科技與業(yè)務(wù)能夠融洽溝通的機制，從而希望從根本上，消除科技與業(yè)務(wù)的隔閡，實現(xiàn)產(chǎn)品和服務(wù)的快速交付，體現(xiàn)業(yè)務(wù)價值。

為什么有些方法和工具，已經(jīng)存在多年，比如低代碼和企業(yè)架構(gòu)，現(xiàn)在又被大肆宣傳呢？

各行業(yè)的數(shù)字化進入深水區(qū)，基礎(chǔ)設(shè)施逐漸完善，競爭進入了白熱化階段，信息的快速流通使得客戶缺乏忠誠度，用腳投票，產(chǎn)品極為同質(zhì)化，企業(yè)按照固有思路，投入巨大成本進行產(chǎn)品改造優(yōu)化帶來的收益越來越小，用時髦的話說，內(nèi)卷化越來越嚴重了。

迫切的需要從根本上，解決產(chǎn)品和服務(wù)交付速度的問題，更快的推出新產(chǎn)品迎合市場與用戶。

這種態(tài)勢下，越來越多的企業(yè)喜歡概念式創(chuàng)新，別人做了什么，我也要做，因為肯定有用別人才會做。

而并非每個工具和方法，都適合每個企業(yè)。

比如數(shù)據(jù)基礎(chǔ)設(shè)施都沒建好的企業(yè)，著急要做數(shù)據(jù)中臺；中小機構(gòu)看見大型企業(yè)實施了企業(yè)架構(gòu)，也紛紛躍躍欲試，要知道，建行企業(yè)架構(gòu)是一個投入了數(shù)億，上萬人的隊伍，歷時七年才完成的巨型工程，不是中小銀行承受得起的。

數(shù)據(jù)中臺才下眉頭，低代碼又上心頭，敏捷方法還在路上，企業(yè)架構(gòu)重現(xiàn)江湖。不管什么工具和方法，本質(zhì)還是為了提升業(yè)務(wù)價值，而根據(jù)企業(yè)現(xiàn)狀的不同，所適用的工具和方法各異。

或許，僅僅是簡單的改變一下組織架構(gòu)，就能解決有些企業(yè)的問題。在不確定自己適合什么工具和方法論的前提下，建議借助外腦，診斷企業(yè)現(xiàn)狀，選擇最符合企業(yè)需要的方法進行實施。