從搜索指數(shù)來看，數(shù)據(jù)中臺有放緩的趨勢，而低代碼穩(wěn)步上升。
數(shù)據(jù)中臺大家都聽了不少，低代碼是什么？
簡單來說，低代碼開發(fā)平臺（LCDP）是一種可以通過圖形化拖拽和參數(shù)配置等更高效的方式，以更少的手寫代碼方式完成開發(fā)工作的軟件。
L代表的Low（我一直覺得應該用Less）指的是少寫代碼。寫得少錯的少，可以讓一般的程序員也能完成高質量的開發(fā)，減輕測試工作量，加快交付速度。
甚至，如果做到極致，成為無代碼開發(fā)平臺，那么業(yè)務人員就可以直接使用，將原來寫需求、需求溝通、需求分析、科技開發(fā)、測試、UAT、上線這一流程極大的簡化，涉及的相關方也極大的收縮。
低代碼并不是一個新概念，從Gartner Hype Cycle上可以看出，低代碼已經(jīng)經(jīng)歷了泡沫破裂期，進入穩(wěn)步爬升的恢復期。
中臺和低代碼平臺，在我看來其實本質上都是希望解決同一個問題，即提供更快更好的滿足業(yè)務需要的應用開發(fā)和數(shù)據(jù)服務能力。
物理世界的變化是飛快的，黑天鵝事件的突然降臨，熱點新聞的突發(fā)和廣泛傳播，監(jiān)管規(guī)定毫無預期的下發(fā)（通常是在周五）……
為了追上這些變化，業(yè)務和產(chǎn)品加班加點趕制了一份需求，經(jīng)過需求評估、討論、評審、修改，終于開始開發(fā)了，最快兩三個月之后，系統(tǒng)上線，市場也許已經(jīng)是另一番光景。
而數(shù)據(jù)服務就更慢了，首先要等應用系統(tǒng)上線且穩(wěn)定，持續(xù)開展一段時間業(yè)務以后才能積累一定量的基礎數(shù)據(jù)，具備了利用這些數(shù)據(jù)提供服務的可能。
而實際服務的提供，還涉及到數(shù)據(jù)質量、數(shù)據(jù)規(guī)范和標準、數(shù)據(jù)時效性等一系列問題，
于是，很自然的，我們需要一些工具或者機制，來填補這兩道鴻溝。
為了提升后臺數(shù)據(jù)采集、提供數(shù)據(jù)服務的速度，縮短業(yè)務/用戶獲得數(shù)據(jù)和服務的時間，壓縮獲得數(shù)據(jù)和服務的成本，同時使得數(shù)據(jù)服務更貼合業(yè)務需求，我們需要數(shù)據(jù)中臺；
為了提升業(yè)務應用的開發(fā)速度，縮短業(yè)務/用戶獲得產(chǎn)品/應用的時間，壓縮獲得產(chǎn)品/應用的成本，同時使得產(chǎn)品/應用更貼近業(yè)務需求，我們需要低代碼平臺。
所以，可以看出，數(shù)據(jù)中臺和低代碼平臺，本質上要解決的是一類問題，就是提升終端用戶獲得服務和產(chǎn)品的效率，壓縮成本，貼近需求。
而這一切，都是為了能讓終端用戶，也就是業(yè)務部門，更好的應對外部環(huán)境快速的變化，最終還是為了創(chuàng)造更多的業(yè)務價值。
為了解決這類問題，這不是我們第一次嘗試了。敏捷的開發(fā)方法也是為了縮短開發(fā)周期，提升開發(fā)效率，貼近用戶需求。
敏捷方法強調快速迭代，先交付一個最小可用產(chǎn)品（MVP），讓業(yè)務先用起來，能夠勉強應付外部的變化，再快速迭代下一個版本。
同樣，也是為了快速的實現(xiàn)業(yè)務價值，我們采用的種種方法論和工具，都是為了這一目標。
那么企業(yè)架構又是干什么的呢？
企業(yè)架構（Enterprise Architecture）始于20 世紀60 年代，截至目前已有接近六十年的發(fā)展歷程。作為一門關鍵的IT 學科領域，經(jīng)過多年的發(fā)展也催生了各類廣泛應用于各行業(yè)和應用場景的框架與方法論工具，例如Zachman、TOGAF、DoDAF 等，這些企業(yè)架構框架也一直作為重要的指導方法和工具，被應用于各類企業(yè)和組織的頂層IT 規(guī)劃與設計。
ThoughWorks 現(xiàn)代企業(yè)架構白皮書
在這里，數(shù)據(jù)玩家不想探討具體的企業(yè)架構框架，而是想說說企業(yè)架構落地的過程中，究竟解決的是什么問題。
造成產(chǎn)品和數(shù)據(jù)服務交付時間很長的原因，除了客觀的先后順序造成的時間差，還有一個核心原因就是IT和業(yè)務的溝通問題。
往小了說，IT和業(yè)務各自有各自的語言，難以在同一層面溝通，往大了說，IT和業(yè)務各有各的目標或KPI，沒法站到對方的立場考慮問題。
而企業(yè)架構的落地過程中，要求IT和業(yè)務忘掉自己的語言，全部基于企業(yè)架構框架的獨有語言來進行溝通，這樣，至少保證了雙方在統(tǒng)一體系下進行溝通，避免了不同“語言”之間的交互和理解偏差。
至于目標和KPI，則需要自頂向下的推動，由高層牽頭，全體配合完成一個聲勢浩大的全盤重塑。
比如建行的企業(yè)架構落地過程，就是科技和業(yè)務坐在一起，按照業(yè)務領域/價值鏈、業(yè)務組件、活動、任務、步驟的五級建模方法論，重新梳理流程、產(chǎn)品、數(shù)據(jù)和用戶體驗等領域。
本質上，是創(chuàng)建了一種科技與業(yè)務能夠融洽溝通的機制，從而希望從根本上，消除科技與業(yè)務的隔閡，實現(xiàn)產(chǎn)品和服務的快速交付，體現(xiàn)業(yè)務價值。
為什么有些方法和工具，已經(jīng)存在多年，比如低代碼和企業(yè)架構，現(xiàn)在又被大肆宣傳呢？
各行業(yè)的數(shù)字化進入深水區(qū)，基礎設施逐漸完善，競爭進入了白熱化階段，信息的快速流通使得客戶缺乏忠誠度，用腳投票，產(chǎn)品極為同質化，企業(yè)按照固有思路，投入巨大成本進行產(chǎn)品改造優(yōu)化帶來的收益越來越小，用時髦的話說，內卷化越來越嚴重了。
迫切的需要從根本上，解決產(chǎn)品和服務交付速度的問題，更快的推出新產(chǎn)品迎合市場與用戶。
這種態(tài)勢下，越來越多的企業(yè)喜歡概念式創(chuàng)新，別人做了什么，我也要做，因為肯定有用別人才會做。
而并非每個工具和方法，都適合每個企業(yè)。
比如數(shù)據(jù)基礎設施都沒建好的企業(yè)，著急要做數(shù)據(jù)中臺；中小機構看見大型企業(yè)實施了企業(yè)架構，也紛紛躍躍欲試，要知道，建行企業(yè)架構是一個投入了數(shù)億，上萬人的隊伍，歷時七年才完成的巨型工程，不是中小銀行承受得起的。
數(shù)據(jù)中臺才下眉頭，低代碼又上心頭，敏捷方法還在路上，企業(yè)架構重現(xiàn)江湖。不管什么工具和方法，本質還是為了提升業(yè)務價值，而根據(jù)企業(yè)現(xiàn)狀的不同，所適用的工具和方法各異。
或許，僅僅是簡單的改變一下組織架構，就能解決有些企業(yè)的問題。在不確定自己適合什么工具和方法論的前提下，建議借助外腦，診斷企業(yè)現(xiàn)狀，選擇最符合企業(yè)需要的方法進行實施。
版權聲明：本文內容由互聯(lián)網(wǎng)用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權/違法違規(guī)的內容， 請發(fā)送郵件至 舉報，一經(jīng)查實，本站將立刻刪除。