也聊聊金融企业运维平台低代码的事

也聊聊金融企业运维平台低代码的事

今天朋友圈转了多次陈果的《低代码，不要以比“中台”还快的速度臭大街》，以及明道云任向晖的回应《陈果说低代码快要烂大街了，我却想成为最烂的那个》。恰好前两个月试用了明道云，以及前几年在平台建设中尝试了低代码，简单梳理一下心得。

1.《低代码，不要以比“中台”还快的速度臭大街》观点

这篇文章是咨询专家陈果所写，我大概摘录文章的观点：

1）“低代码开发平台产生的初衷是提供一个鼓励员工微创新、自主开发应用程序、利用企业数字化能力的助推器；在一些流程相对简单的场景下，可以帮助企业迅速实现对这些简单场景的数字化转型。对于复杂流程和核心业务流程，低代码平台肯定不完全适合，只是实现简单、辅助流程的首选开发平台。”

2）“低代码”概念火了起来，与可视化开发、流程编排等相关的厂商都在借代码作为市场炒作点，在宣传有几个错误的引导：

“低代码可以开发企业所有软件”；（观点：低代码主要是面向企业用户的快速补充开发）“低代码是企业软件行业的革命，彻底改变企业软件行业”；（观点：低代码开发非新事物，甚至说是十年前的一个过渡性的解决方案）“低代码工具是一个独立的软件“；（观点：低代码应该是平台层面的组件，要基于云产生效果）”低代码工具谁都能用，企业内谁都可以创新应用”；（观点：企业内大面积的公民化开发的应用创新是个伪命题，开发软件是一回事，能用起来是另一回事）

3）“低代码”发展方向是两个：1、纯云；2、跨平台。

2.《陈果说低代码快要烂大街了，我却想成为最烂的那个》的观点

作为回应，低代码厂商明道云创始人任向晖写了一篇文章作为回应，或者说打个了免费私有化部署的广告。我也摘文章几个观点:

1）明道云的低代码的理念是“应用平台”（APaaS），应用平台不需要高级语言编写、不需要完整的软件角色分工，不会有IDE环境，不会有代码编译，不需要开发用户搭建应用运行环境，应用通过APaaS搭建，搭建完成后，就在APaaS上直接运行。

2）APaaS（后面尽量用APaaS代替代码）将软件开发专业过程全部通过平台来模式化实现，虽然牺牲了一定的灵活性，但提供高质量和高效率。而对于企业管理应用来说，这种灵活性的损失并不大。明道云的解决方案复制了一些传统企业管理软件的解决方案，比如BMC REMEDY的部分ITSM流程，还有其它管理系统。

3）APaaS是软件业革命。理由：国内外咨询、互联网大厂都在搞，他们都有理解问题？APaaS将不断沉淀共性、封装、共享，具备平台的强扩展性特征，与中台很吻合。

4）APaaS能解决让理解业务、熟悉业务的人快速掌握IT开发人员的技能，这个意义重大。

3. 我对“低代码”的实践过程及想法

大概是16年还在银行做运维平台规划时，我做了“低代码”的规划内容，主要是基于前后端IDE的运维开发模式（这个规划不是任总讲的APaaS这种完整无代码的解决方案）。当时这个规划的背景有几点：

1）运维团队要增强运维研发能力，让想用工具的人自己也可以开发工具，但是银行现有运维团队具备开发能力的同学少得可怜，让他们学开发，能像SRE那种50%的工程方面的投入行不通，要提供一种低门槛的开发解决方案。

2）我到当时的软件厂商了解了一下，发现一个厂商研发了大量的系统，但是现场人员大部分基于他们IDE开发，这个IDE能实现前台业务可视化、后台逻辑的处理逻辑编排。商量完，发现可以将这个后台逻辑的代码改为PYTHON，如果PYTHON是运维人员的技能的前提可行，这个IDE开发的模式技术可行。

3）当时蓝鲸有了运维PaaS平台的低代码的影子，蓝鲸当时主要体现在将一些前端开发的组件代码提前写好，可以方便大家写前端时直接改代码就能用。现在5年过去了，应该更好用，最近几年没具体接触就不过多解释。

看起来，基于前后端IDE的方式，可以赋能业务运维，所以就开干了。不过后来因为一些原因离职，所以没有跟下去。但在有限时间里，也发现了一些阻碍的问题：

1）IDE的开发模式，虽然简化了开发门槛，但还是有门槛，使用人员要有一定的研发技能。

2）要推动全民运维研发，要配套完整的绩效激励，否则用户通常不会主动改变。

3）运维的工具要产生更好的效果，需要与“监管控”关联上，就要在企业中有“监管控”的接口统一管理。虽然当时我也做了这个接口的统一管理，但接口统一管理还相对滞后于IDE的低代码。

4）纯线上管理精细化的场景，ITSM能解决几个重点的场景问题，剩下的纯管理场景比较琐碎，考验场景的抽象总结能力，要有比较好的产品设计人员，这类设计人员不仅会设计，关键还需要具备以下软技能：懂管理、能驱动规程优化、会推广。可惜企业中有这种综合能力的人太少了。

后来在18年，我想在另一个具备较高水平开发能力的团队中推广这种IDE开发模式，发现另一个问题：具备较高水平的开发人员天生有排斥这种低代码开发的模式，他们对个人能力研发能力有追求，不愿意被束缚在IDE之上。

时间到了20年初，做了一年与数字化相关的项目，对IT在数字化转型中的核心价值创造：“快速响应”需求，以及数字化转型的第一步“业务（含运营）线上化”（下面两步是：线上业务化，数字化转型）的理解更为深刻。在项目中也重点关注并应用前端可配置、流程可编排的解决方案的应用。又增加了一些新的想法：

1）相比对客的业务功能，企业内部有很多协同是线下的，或者说很多企业关注了业务侧赚钱的投入大，但对于内部协同的投入不多。采用类似ITSM的ESM同样适用于企业中后台部门的协同，这此场景的线上化还属从0到1的阶段，低代码有些场景个性化需求无法解决的问题在这里瑕不掩瑜。

2）随着数字化转型思维在企业的传递，越来越多的需求出现，IT部门内不可能将主要的研发资源投到中后台管理的场景研发中，低代码在快速交付方面的优点应该能加快渗透进来。

时间到了去年10月份左右，试用了明道云。又增加了一些新想法：

1）这东西还挺好用。尤其是对于非运维生产交互的管理或协同应用，部署在测试环境后，从来没用这个系统的我，在10分钟内也可以配置一个像日报、周报、月报这样的工具。更有意思的是，除了前端、流程编排的无代码，他还提供了触发外部接口调用的等与其它系统互联的配置功能。整体的解决方案与我在19、20年努力在做但还没做好的东西很像。

2）这东西的应用，需要甲方的人有线上化、追求成长的思维。如果没有线上化思维，这东西可能打动不了金融企业的运维团队，所以要推这个产品首先得先给线上化布道。

3）在运维领域，缺挖掘需求、痛点的人。或者说，运维工具的快速交付与运维工具的好用相比，现阶段好用更加重要。这里的好用是，是场景真的能够解决痛点，使用起来更好顺滑，最好先解决场景抽象问题，再解决技术上的快速交付。

4）低代码要解决与监管控平台的关联，能够作为监管控平台能力的延伸，不能仅作为线上化的管理工具。

观点有些杂，但总的来说，应该有助于需要对运维平台做低代码的甲乙方参考。

end。

附文中两篇文章：

https://mp.weixin.qq.com/s/a-30lC77k3ZpYrsucZoWDw

https://mp.weixin.qq.com/s/8P9XKbP0CxSh7kIyLuB4Xg