数据中台才下眉头，低代码又上心头（数据中台-）

从搜索指数来看，数据中台有放缓的趋势，而低代码稳步上升。

数据中台大家都听了不少，低代码是什么？

简单来说，低代码开发平台（LCDP）是一种可以通过图形化拖拽和参数配置等更高效的方式，以更少的手写代码方式完成开发工作的软件。

L代表的Low（我一直觉得应该用Less）指的是少写代码。写得少错的少，可以让一般的程序员也能完成高质量的开发，减轻测试工作量，加快交付速度。

甚至，如果做到极致，成为无代码开发平台，那么业务人员就可以直接使用，将原来写需求、需求沟通、需求分析、科技开发、测试、UAT、上线这一流程极大的简化，涉及的相关方也极大的收缩。

低代码并不是一个新概念，从Gartner Hype Cycle上可以看出，低代码已经经历了泡沫破裂期，进入稳步爬升的恢复期。

中台和低代码平台，在我看来其实本质上都是希望解决同一个问题，即提供更快更好的满足业务需要的应用开发和数据服务能力。

物理世界的变化是飞快的，黑天鹅事件的突然降临，热点新闻的突发和广泛传播，监管规定毫无预期的下发（通常是在周五）……

为了追上这些变化，业务和产品加班加点赶制了一份需求，经过需求评估、讨论、评审、修改，终于开始开发了，最快两三个月之后，系统上线，市场也许已经是另一番光景。

而数据服务就更慢了，首先要等应用系统上线且稳定，持续开展一段时间业务以后才能积累一定量的基础数据，具备了利用这些数据提供服务的可能。

而实际服务的提供，还涉及到数据质量、数据规范和标准、数据时效性等一系列问题，

于是，很自然的，我们需要一些工具或者机制，来填补这两道鸿沟。

为了提升后台数据采集、提供数据服务的速度，缩短业务/用户获得数据和服务的时间，压缩获得数据和服务的成本，同时使得数据服务更贴合业务需求，我们需要数据中台；

为了提升业务应用的开发速度，缩短业务/用户获得产品/应用的时间，压缩获得产品/应用的成本，同时使得产品/应用更贴近业务需求，我们需要低代码平台。

所以，可以看出，数据中台和低代码平台，本质上要解决的是一类问题，就是提升终端用户获得服务和产品的效率，压缩成本，贴近需求。

而这一切，都是为了能让终端用户，也就是业务部门，更好的应对外部环境快速的变化，最终还是为了创造更多的业务价值。

为了解决这类问题，这不是我们第一次尝试了。敏捷的开发方法也是为了缩短开发周期，提升开发效率，贴近用户需求。

敏捷方法强调快速迭代，先交付一个最小可用产品（MVP），让业务先用起来，能够勉强应付外部的变化，再快速迭代下一个版本。

同样，也是为了快速的实现业务价值，我们采用的种种方法论和工具，都是为了这一目标。

那么企业架构又是干什么的呢？

企业架构（Enterprise Architecture）始于20 世纪60 年代，截至目前已有接近六十年的发展历程。作为一门关键的IT 学科领域，经过多年的发展也催生了各类广泛应用于各行业和应用场景的框架与方法论工具，例如Zachman、TOGAF、DoDAF 等，这些企业架构框架也一直作为重要的指导方法和工具，被应用于各类企业和组织的顶层IT 规划与设计。

ThoughWorks 现代企业架构白皮书

在这里，数据玩家不想探讨具体的企业架构框架，而是想说说企业架构落地的过程中，究竟解决的是什么问题。

造成产品和数据服务交付时间很长的原因，除了客观的先后顺序造成的时间差，还有一个核心原因就是IT和业务的沟通问题。

往小了说，IT和业务各自有各自的语言，难以在同一层面沟通，往大了说，IT和业务各有各的目标或KPI，没法站到对方的立场考虑问题。

而企业架构的落地过程中，要求IT和业务忘掉自己的语言，全部基于企业架构框架的独有语言来进行沟通，这样，至少保证了双方在统一体系下进行沟通，避免了不同“语言”之间的交互和理解偏差。

至于目标和KPI，则需要自顶向下的推动，由高层牵头，全体配合完成一个声势浩大的全盘重塑。

比如建行的企业架构落地过程，就是科技和业务坐在一起，按照业务领域/价值链、业务组件、活动、任务、步骤的五级建模方法论，重新梳理流程、产品、数据和用户体验等领域。

本质上，是创建了一种科技与业务能够融洽沟通的机制，从而希望从根本上，消除科技与业务的隔阂，实现产品和服务的快速交付，体现业务价值。

为什么有些方法和工具，已经存在多年，比如低代码和企业架构，现在又被大肆宣传呢？

各行业的数字化进入深水区，基础设施逐渐完善，竞争进入了白热化阶段，信息的快速流通使得客户缺乏忠诚度，用脚投票，产品极为同质化，企业按照固有思路，投入巨大成本进行产品改造优化带来的收益越来越小，用时髦的话说，内卷化越来越严重了。

迫切的需要从根本上，解决产品和服务交付速度的问题，更快的推出新产品迎合市场与用户。

这种态势下，越来越多的企业喜欢概念式创新，别人做了什么，我也要做，因为肯定有用别人才会做。

而并非每个工具和方法，都适合每个企业。

比如数据基础设施都没建好的企业，着急要做数据中台；中小机构看见大型企业实施了企业架构，也纷纷跃跃欲试，要知道，建行企业架构是一个投入了数亿，上万人的队伍，历时七年才完成的巨型工程，不是中小银行承受得起的。

数据中台才下眉头，低代码又上心头，敏捷方法还在路上，企业架构重现江湖。不管什么工具和方法，本质还是为了提升业务价值，而根据企业现状的不同，所适用的工具和方法各异。

或许，仅仅是简单的改变一下组织架构，就能解决有些企业的问题。在不确定自己适合什么工具和方法论的前提下，建议借助外脑，诊断企业现状，选择最符合企业需要的方法进行实施。