最近一段時間和一些同行老鐵交流的時候（當然書面的說話叫做“交換想法”），發(fā)現(xiàn)涉足“數(shù)字孿生”領域的廠商很多都在布局三維“低代碼”平臺的產品化，尤其是最近的一些頭部廠商也都陸陸續(xù)續(xù)的發(fā)布了自己家的“低代碼”平臺，當然我這里面說的“數(shù)字孿生”其實特指的就是“三維可視化”。

在GIS領域目前機會所有的數(shù)字化制圖工具都是基于規(guī)則進行配置的，在桌面制圖階段你幾乎可以毫無成本的在主流的幾個GIS平臺產品之間進行切換，因為背后的邏輯是一致的。

后面隨著網絡以及前端性能的大幅度提升，基于SaaS化的在線制圖工具開始興起，其中比較有名的就是Mpabox Studio，在此之前Mapbox是作為一個自帶數(shù)據(jù)的開發(fā)框架廣泛流行開的，但是他自己定義了一套獨特的可視化規(guī)則，后面的這個Studio也就是將他的渲染規(guī)則進行可視化，這樣開發(fā)人員可以不用寫代碼就可以進行地圖樣式的配置，同時可以導出樣式文件，這樣就大大降低開發(fā)人員的工作量，同時非開發(fā)人員也可以參與到相應的工作流中，這樣雙方就可以基于樣式文件進行工作的配合。

后面快速躥紅的Unfolded Studio其實本質上也是基于這個思路，但是在數(shù)據(jù)處理（比如它有一些Join 、Group By 的關聯(lián)操作以及豐富的數(shù)學函數(shù)表達式）以及空間分析（集成了Jupyter Notebook）上做了延伸，但是本質上還是在做可視化，因為他的口號就是“Geospatial data never looked so good”，雖然在分析上目前還是集成了一些代碼分析的工具，但是空間分析的最佳實踐已經在桌面GIS端得到了成功的應用，其實就是“ModelBuilder”這種可視化配置的形式，這也應該是在線空間分析工具發(fā)展的一個方向。

一、當前IT圈提的比較多的“低代碼”和GIS這種基于規(guī)則配置的工具產品有什么區(qū)別么？

要搞清楚這個問題，我們首先得看一下“低代碼”平臺的定義：

從維基百科的定義中，我們大概可以得到這樣兩個關鍵信息：

低代碼平臺本質上是一種集成開發(fā)環(huán)境，對于程序員而言，低代碼開發(fā)平臺的性質與IDEA、VS等代碼IDE（集成開發(fā)環(huán)境）幾乎一樣，都是服務于開發(fā)者的生產力工具。

與傳統(tǒng)代碼IDE不同的是，低代碼開發(fā)平臺提供的是更高維和易用的可視化IDE。大多數(shù)情況下，開發(fā)者并不需要使用傳統(tǒng)的手寫代碼方式進行編程，而是可以通過圖形化拖拽、參數(shù)配置等更高效的方式完成開發(fā)工作。

其實從定義就可以看出，“低代碼”和“基于規(guī)則（Rule-Based）”的軟件平臺嚴格意義上來說還是有一點區(qū)別的：

低代碼平臺本質上還是服務于開發(fā)人員，只是改變了寫代碼的方式，只是以前寫文本的方式轉換到了圖形拖拉拽以及配置的方式，但是本質上的編程邏輯是一樣的，最終的圖形化邏輯是可以直接轉化到文本代碼的，比如UE4的藍圖就是一個“低代碼”開發(fā)工具。

上面是一種比較徹底的低代碼，另外還有一些比較流行但是沒那么徹底的“低代碼”平臺，雖然目標也是做應用開發(fā)，但主要是結合SaaS進行一些微應用的定制，很類似一些在線的原型繪制工具，這種產品沒辦法支持比較深度的應用定制，更多的場景是一些輕量的微應用，比如釘釘?shù)摹耙舜睢?，主要也是一些表單定制和流程定制，但是這種工具的門檻比較低是可以是可以完全開放給沒有開發(fā)經驗的人，比如運營人員以及產品經理等等。

“基于規(guī)則”的軟件平臺更多是在一定的規(guī)則范圍內，對預設定的變量進行配置或者設定，這種工具的門檻比較低，面向的用戶也比較廣泛，平臺的能力以及門檻是和規(guī)則的復雜度是保持一致的。

但是在現(xiàn)在的一個語義環(huán)境下，這三類其實都算作“低代碼”平臺，只是程度深淺的問題。

二、為什么現(xiàn)在數(shù)字孿生廠商都在朝著“低代碼”平臺的方向努力呢？

其實這個問題也反映了這個“三維可視化”這個方向開始從野蠻發(fā)展階段發(fā)展到成熟階段，已經進入了一個分水嶺，在這個分水嶺上廠商必須要要在方向選擇上做出抉擇是選擇“專注把三維可視化做大做強”還是選擇“切入到某個行業(yè)里面把行業(yè)做深做透”，出現(xiàn)這個分水嶺的原因在于：

可視化廠商無法提供完整的行業(yè)解決方案，可視化廠商的定位就是為各行各業(yè)提供可視化解決方案，這個東西只是加分項不是必須項，同時由于沒有很深的行業(yè)積累，所以很多可視化廠商是很難面向直接業(yè)主的，更多的還是找渠道合作，選擇和渠道綁定，借助渠道放大，但是處在食物鏈的底端必然出現(xiàn)的局面就是被上游廠商不斷壓縮利潤空間，直到無法承受。

目前很多行業(yè)廠商也具備了三維可視化能力，以前客戶做可視化是“找廠商”現(xiàn)在是客戶“選廠商”，能做的廠家實在是太多了，同時即使是有一定的門檻，一些非專業(yè)的開發(fā)公司經過這兩年的積累也掌握了相應的技術也能夠做出還不錯的效果了，以前我們說GIS比較小眾，你現(xiàn)在會發(fā)現(xiàn)大多數(shù)軟件公司自己都配備了GIS開發(fā)人員，對于核心的能力任何廠家都會選擇掌握在自己手里，而不會交到別人手里。

所以在這種狀況下，很多可視化廠商為了發(fā)展要么就是繞開渠道自己做整體方案提供商，在有限的資源條件下將某個方向的業(yè)務做深做透，要么繼續(xù)迎合渠道廠商的訴求，更大程度上讓出利潤，為他們提供標準的平臺化服務，將客單價做小，但是把量做起來。

很多廠商由于路徑依賴，自然是選擇自己最擅長的方向就是將可視化平臺化，一方面是因為過去項目的重復積累可以保證自己可以進行能力的抽象和邊界的劃定；另一方面平臺化是比項目制更好的商業(yè)模式，因為平臺化可以保證在不增加投入的情況下還能放大規(guī)模，這是最好的商業(yè)模式，在太多的個性化需求和多條線并行的情況下還想控制成本基本上是癡心妄想，營收做的很大，一到年底算賬才發(fā)現(xiàn)原來只能是忙活個熱鬧。

三、可視化做到“低代碼”是不是就夠了？

那將可視化做到“低代碼”是不是就夠了？答案顯然是不夠的，正如一個老鐵所說這玩意整下來最多就是個原型工具，做不出系統(tǒng)來。所以很多廠商也深知這一點，基本使用場景都是定位在大屏應用。

一方面這樣應用就可以拆分成“三維地圖場景 圖表”，這樣就可以限定用戶可配置的區(qū)間；另外一方面及時對于一些個性化的需求也可以通過開放API的方式進行補充，所以在這個場景下是可以邊界閉環(huán)的。

但是我這邊要說的是即使是定位在可視化方面，“低代碼”平臺還是需要具備提供“數(shù)據(jù) 軟件”一站式解決方案能力，因為可視化天生就是服務于數(shù)據(jù)的，所以在數(shù)據(jù)這個環(huán)節(jié)上也必須打通，不然這個產品在場景上只能說是做了一半，比如針對基礎的空間數(shù)據(jù)搭建、多源異構數(shù)據(jù)的導入、數(shù)據(jù)的基本處理、分析能力的接入等，同時這類平臺作深了一定是和云做緊密結合的，因為對空間以及算力的要求都提高了，當然如果你只是定位做一個“面子工程”產品就沒這個必要了。

數(shù)字孿生可視化隨著逐漸成熟到底會發(fā)展成為什么形態(tài)還需要進一步的觀察，但是目前釋放出來很明確的信號是如果在這個分水嶺上做了選擇不見得不出局，但是不做選擇的那一定是出局，同時更多的可視化廠商選擇“低代碼”平臺化這個路徑也就意味著競爭依然存在而且還會持續(xù)升級，就看最后誰能跑出來了~

來源：GIS小丸子

課程預告