数字孪生厂商下一个战场「低代码」~

最近一段时间和一些同行老铁交流的时候（当然书面的说话叫做“交换想法”），发现涉足“数字孪生”领域的厂商很多都在布局三维“低代码”平台的产品化，尤其是最近的一些头部厂商也都陆陆续续的发布了自己家的“低代码”平台，当然我这里面说的“数字孪生”其实特指的就是“三维可视化”。

在GIS领域目前机会所有的数字化制图工具都是基于规则进行配置的，在桌面制图阶段你几乎可以毫无成本的在主流的几个GIS平台产品之间进行切换，因为背后的逻辑是一致的。

后面随着网络以及前端性能的大幅度提升，基于SaaS化的在线制图工具开始兴起，其中比较有名的就是Mpabox Studio，在此之前Mapbox是作为一个自带数据的开发框架广泛流行开的，但是他自己定义了一套独特的可视化规则，后面的这个Studio也就是将他的渲染规则进行可视化，这样开发人员可以不用写代码就可以进行地图样式的配置，同时可以导出样式文件，这样就大大降低开发人员的工作量，同时非开发人员也可以参与到相应的工作流中，这样双方就可以基于样式文件进行工作的配合。

后面快速蹿红的Unfolded Studio其实本质上也是基于这个思路，但是在数据处理（比如它有一些Join 、Group By 的关联操作以及丰富的数学函数表达式）以及空间分析（集成了Jupyter Notebook）上做了延伸，但是本质上还是在做可视化，因为他的口号就是“Geospatial data never looked so good”，虽然在分析上目前还是集成了一些代码分析的工具，但是空间分析的最佳实践已经在桌面GIS端得到了成功的应用，其实就是“ModelBuilder”这种可视化配置的形式，这也应该是在线空间分析工具发展的一个方向。

要搞清楚这个问题，我们首先得看一下“低代码”平台的定义：

从维基 百科的定义中，我们大概可以得到这样两个关键信息：

1. 低代码平台本质上是一种集成开发环境，对于程序员而言，低代码开发平台的性质与IDEA、VS等代码IDE（集成开发环境）几乎一样，都是服务于开发者的生产力工具。

2. 与传统代码IDE不同的是，低代码开发平台提供的是更高维和易用的可视化IDE。大多数情况下，开发者并不需要使用传统的手写代码方式进行编程，而是可以通过图形化拖拽、参数配置等更高效的方式完成开发工作。

其实从定义就可以看出，“低代码”和“基于规则（Rule-Based）”的软件平台严格意义上来说还是有一点区别的：

• 低代码平台本质上还是服务于开发人员，只是改变了写代码的方式，只是以前写文本的方式转换到了图形拖拉拽以及配置的方式，但是本质上的编程逻辑是一样的，最终的图形化逻辑是可以直接转化到文本代码的，比如UE4的蓝图就是一个“低代码”开发工具。

• 上面是一种比较彻底的低代码，另外还有一些比较流行但是没那么彻底的“低代码”平台，虽然目标也是做应用开发，但主要是结合SaaS进行一些微应用的定制，很类似一些在线的原型绘制工具，这种产品没办法支持比较深度的应用定制，更多的场景是一些轻量的微应用，比如钉钉的“宜搭”，主要也是一些表单定制和流程定制，但是这种工具的门槛比较低是可以是可以完全开放给没有开发经验的人，比如运营人员以及产品经理等等。

• “基于规则”的软件平台更多是在一定的规则范围内，对预设定的变量进行配置或者设定，这种工具的门槛比较低，面向的用户也比较广泛，平台的能力以及门槛是和规则的复杂度是保持一致的。

但是在现在的一个语义环境下，这三类其实都算作“低代码”平台，只是程度深浅的问题。

其实这个问题也反映了这个“三维可视化”这个方向开始从野蛮发展阶段发展到成熟阶段，已经进入了一个分水岭，在这个分水岭上厂商必须要要在方向选择上做出抉择是选择“专注把三维可视化做大做强”还是选择“切入到某个行业里面把行业做深做透”，出现这个分水岭的原因在于：

1. 可视化厂商无法提供完整的行业解决方案，可视化厂商的定位就是为各行各业提供可视化解决方案，这个东西只是加分项不是必须项，同时由于没有很深的行业积累，所以很多可视化厂商是很难面向直接业主的，更多的还是找渠道合作，选择和渠道绑定，借助渠道放大，但是处在食物链的底端必然出现的局面就是被上游厂商不断压缩利润空间，直到无法承受。

   
   

2. 目前很多行业厂商也具备了三维可视化能力，以前客户做可视化是“找厂商”现在是客户“选厂商”，能做的厂家实在是太多了，同时即使是有一定的门槛，一些非专业的开发公司经过这两年的积累也掌握了相应的技术也能够做出还不错的效果了，以前我们说GIS比较小众，你现在会发现大多数软件公司自己都配备了GIS开发人员，对于核心的能力任何厂家都会选择掌握在自己手里，而不会交到别人手里。

   
   

所以在这种状况下，很多可视化厂商为了发展要么就是绕开渠道自己做整体方案提供商，在有限的资源条件下将某个方向的业务做深做透，要么继续迎合渠道厂商的诉求，更大程度上让出利润，为他们提供标准的平台化服务，将客单价做小，但是把量做起来。

很多厂商由于路径依赖，自然是选择自己最擅长的方向就是将可视化平台化，一方面是因为过去项目的重复积累可以保证自己可以进行能力的抽象和边界的划定；另一方面平台化是比项目制更好的商业模式，因为平台化可以保证在不增加投入的情况下还能放大规模，这是最好的商业模式，在太多的个性化需求和多条线并行的情况下还想控制成本基本上是痴心妄想，营收做的很大，一到年底算账才发现原来只能是忙活个热闹。

那将可视化做到“低代码”是不是就够了？答案显然是不够的，正如一个老铁所说这玩意整下来最多就是个原型工具，做不出系统来。所以很多厂商也深知这一点，基本使用场景都是定位在大屏应用。

一方面这样应用就可以拆分成“三维地图场景 图表”，这样就可以限定用户可配置的区间；另外一方面及时对于一些个性化的需求也可以通过开放API的方式进行补充，所以在这个场景下是可以边界闭环的。

但是我这边要说的是即使是定位在可视化方面，“低代码”平台还是需要具备提供“数据 软件”一站式解决方案能力，因为可视化天生就是服务于数据的，所以在数据这个环节上也必须打通，不然这个产品在场景上只能说是做了一半，比如针对基础的空间数据搭建、多源异构数据的导入、数据的基本处理、分析能力的接入等，同时这类平台作深了一定是和云做紧密结合的，因为对空间以及算力的要求都提高了，当然如果你只是定位做一个“面子工程”产品就没这个必要了。

数字孪生可视化随着逐渐成熟到底会发展成为什么形态还需要进一步的观察，但是目前释放出来很明确的信号是如果在这个分水岭上做了选择不见得不出局，但是不做选择的那一定是出局，同时更多的可视化厂商选择“低代码”平台化这个路径也就意味着竞争依然存在而且还会持续升级，就看最后谁能跑出来了~