中台自被提出以来不断的有反对的声音，比如传播较广的这两篇文章 《阿里彻底拆中台了！》[https://mp.weixin.qq.com/s/DJn-CLLfG_5nMCKKXSclIg] , 《ERP已死，“中台”已凉，“低代码”称王！》[https://mp.weixin.qq.com/s/NlFRrylozbqyLk1xCORe-w]
那么中台真的是明日黄花了吗？其实不尽然。从发展的眼光看中台也在逐步地自我完善。笔者之前的文章 《中台反思：技术中台设计架构》[http://www.idealworld.group/2021/04/23/reflections-of-middle-platform-technical-architecture/] 提到了中台的演进，也提到了低代码置于中台的作用。本文我们就此进一步展开讨论。
首先我们要明白为什么很多人说中台不适合“颠覆式创新”，那是因为当前的中台多以“服务”的形式露出，完成一个业务能力需要有前台应用参与，也就是中台没有端到端的业务实现能力。所以中台的演进一定是将“去前台”视为重要的能力，通过中台即可构建完整的业务能力。
这时我们一定会想到低代码，低代码是什么？
如上图所示，低代码想解决就是简化业务实现的流程进而提升效率。市场上也有很多的低代码产品（如下图，《Gartner Magic Quadrant for Enterprise Low-Code Application Platforms》节选）：
我们可以大概将这些产品分成三大类：
-
全能型：如OutSystems，这些产品可以用于构建复杂的系统，但上手很难
-
简洁型：如轻流，这些产品上手简单，体验友好，产品及业务人员都可以轻松使用，但是场景比较受限，只能构建简单的应用
-
均衡型：比如一些产业互联网厂商开发的产品，这些产品支持二次开发，产品及业务人员构建大部分的功能，开发人员可以构建余下的功能，但几乎都需要离线开发
这些产品都有不同的适用场景，并且目前看低代码这个方向的发展势头也很强劲。但是我们也注意到近期ThoughtWorks 中国区 CTO 徐昊的观点《“行业毒瘤”低代码》[https://mp.weixin.qq.com/s/nux9xJko6N1tLTK23-ZbzA] 。从笔者的经验看非常赞同，用“虚火过旺”形容不为过。 目前低码平台最大的问题是改变了编程模型，导致开发与可视化构建存在断层，进而导致高不成低不就。
怎么理解？开发人员有对项目开发的经验范式，这是他们熟悉的，但低代码由产品或业务人员完成了大部分能力的构建，给到开发人员补充实现时却是各种DSL，或是使用自定义的XML让开发扩展能力，或是注入了一堆用于界面可视化的Schema/元数据到代码中，导致开发人员有很高的学习成本，并且很难去集成已有的能力。
那么怎么看待低代码吗？笔者认为其有不可比拟的优势，但在技术中台叠加低代码能力时我们需要把握以下几个原则：
我们要先有完善的公共能力，比如用户权限、用户触达、任务调度、规则决策等，后者为低代码提供了基础服务。同时很重要的一点是低代码能力要先实现BaaS能力，提供诸如对数据库、缓存、对象存储、MQ、日志、事务等原子化的服务。
也就是说我们可以基于中台的能力使用纯大前端技术（比如Node、RN）完成复杂应用的构建。
实现BaaS能力建设后，我们也需要考虑DevOps流程的建设，能实现从需求到开发再到测试、发布、部署、监控等应用研发全流程的构建。
有了BaaS及DevOps能力后我们还需要明确开发者优先策略，这是比较反主流的。笔者认为要先给开发者提供友好的体验，让开发者使用熟悉的编程模型，0学习成本的情况下基于我们这个低代码平台可以开发完整的复杂应用。然后我们再要考虑的是在这一前提下逐步加入可视化、拖拉拽的能力，实现界面、模型、规则、服务、逻辑等方面的编排。
所以如上图所示，一个比较完善的技术中台大体的架构应该是这样的。它实现了我们中台能力支撑的四个象限。重点是实现了DevOps流程支持应用全流程构建，实现了原子、基础等公共服务支持纯大前端代码开发完整的应用的能力，实现应用构建平台建立应用管理、开发编排、持续发布等核心能力。
最后我们还要考虑的是推广成本的问题，目前来看各个中台产品的部署使用成本很高，比如某知名的技术中台仅验证环境就需要至少500c100g。如果我们的目标是产品化不是平台化，那么必须使用创新的技术去实现服务伸缩、一键部署、代码安全等非功能需求。
本文只是抛砖引玉，泛泛地讲了一些原则，具体到实现还有很多有意思的点，如有兴趣欢迎进一步沟通、探讨。
