赞同科技蒲云：关于银行业低代码平台建设的思考和探讨
2021-12-22 来源：互联网 网络编辑：编辑 阅读次关于作者
作者在银行IT领域拥有近20年从业经验，现任赞同科技股份有限公司CTO。入行即从事工具平台研发，支撑并推动公司在各线产品平台形成快速应用开发配套工具体系，构建关键竞争力要素；主持研发渠道系统中间件平台，顺应并支撑业务快速发展创新，在细分领域市场份额排名常年位居榜首；立足技术面向业务，愿与同业共同探索更进一步的价值创造。
赞同科技股份有限公司CTO 蒲云
为何要讨论低代码
银行业近些年来的IT系统升级建设，包含了很多基础设施层面的内容，例如云平台、中台、分布式、微服务架构等等。
在取得效果方面，从大势上看，是进步的，就不一一赘述了。但在有些方面上，没有取得很好效果，甚至个别地方还有所退步。比如，建设同样的服务能力，需要消耗更多的物理资源，变贵了；原本可以在秒级做到的应用开发热部署，现在改为镜像方式达到了分钟级，变慢了；原本运算资源要素集中的高性能的软件架构，转变为分离的跨越漫长多节点链路的部署架构，变复杂了。而一部分新技术的酷炫之处，其实更多地是解决了新方案自身带来的痛点。犹如从一座山峰走向另一座更高的山峰，下坡路无法完全避免。
大家可以感受到，当前的技术改造，尤其是基础设施建设，对于业务的价值输出仍然有限。
技术发展的核心目的，是为了更好更快响应业务需求，以及促进业务发展。因此在底层平台建设的基础上开拓视野，人们开始将视线转移到了应用交付领域，希望通过快速应用开发平台，尤其是低代码平台，为业务提供快捷可见的价值输出。
继“中台”之后，“低代码”俨然成了又一个企业数字化领域的一股风潮，势必带来领域内一些新的讨论实践和难以避免的争议。
银行业在企业数字化领域处于一个较为特殊的地位，信息化建设的长年积累远超一般企业的水平，业务复杂度也极具专业性，组织架构与IT系统的互动关系也更加错综复杂，因此不太适合简单将银行业从当作一般企业看待，低代码平台在银行业的建设，必须基于这个行业的特点，找准定位，用其所长，才有可能真正解决痛点，产生价值。
低代码凭什么低
代码，伴随着语言进化，一直是极为高效的信息表达方式，具有精确、缜密、灵活的特点。但是，对于非专业的普通人而言，“代码”意味着晦涩不明、难以掌握、耗时费力。因此，“低”代码，带给大家的直觉暗示则是，一目了然、轻松上手、和事半功倍。
似乎是这个道理，但又好像忽略了什么。
我们知道，一个系统的建设开发过程，其核心内容是信息表达，也就是将其复杂度进行无遗漏的覆盖和填补。
如果用更少的代码，意味着什么？要么是这个系统的信息表达减少，要么是通过其他非代码方式完成了相应的信息表达。
可见，“低代码”不是故事的全部，犹如月球的正面一般，给人以全貌的错觉。低代码的背后，是减少代码表达的交换条件。
用减少信息量来交换，可以通过复用积累物，通过组件和模板框架快速搭建，而潜在的局限性是削足适履，强迫业务适应技术，对业务不够友好。
用非代码表达方式来交换，可以通过图形化完成高阶、宏观、要点的信息建模，而潜在的局限性是以偏概全，降低专业开发人员的输出效率，对技术不够友好。
所以，思考低代码，就需要想清楚，我们到底正在准备拿什么进行交换，交换得是否合理，只有在建设的过程中全面看待问题，才可以尽量避免把低代码平台做成一个华而不实的低代码低能力的样子货。
选择低代码的两种衡量视角
再忠实的低代码拥趸也不会真的认为低代码无所不能，因为，任何事物所具备的鲜明特点恰恰是其偏性的体现。
低代码概念形成于企业数字化领域，关键因素是，众多IT资源积累薄弱的普通行业企业，缺少充足的专业开发者，自身IT人力极其有限。低代码的出现，使众多掌握业务需求的非IT专业人士，有机会参与系统定制，使长尾需求得到了更好的满足。
在这种情况下，面对众多行业，以大而化之的方式推进低代码平台建设，就会更加侧重于跨行业的普遍共性，容易形成一个横向的衡量视角。
通过这个横向的跨行业衡量视角，把应用按照生命周期与架构定位划分为：周期可达10年的基础设施应用，例如ERP系统；周期1-2年的差异化设施应用，例如CRM系统；周期小于1年的创新型应用，例如小应用、小程序。
横向视角衡量选择低代码的标准一般是，小、轻、快，即第三类应用。小，工作量本身不大，不需要大量的信息表达；轻，依赖的对接少，不需要处理复杂特殊的技术细节；快，充分发挥低代码特点，体现优势。
但是对于银行业，情况大为不同。银行业的IT积累远超一般行业，为IT建设投入的人力组织分工也更加细致全面。一个应用系统，涉及到众多部门，不同岗位角色，多种工作内容，早已不是用代码从头干到底的建设过程，而且代码工作也并不是一个很大的障碍。
因此，在银行业的低代码选择，需要增加的是纵深的衡量视角。并不是哪个应用系统是否适合选择低代码的问题，而是应用系统的哪一部分工作是否适合选择低代码。不是着眼于解决缺少代码能力而难以建设的问题，而是着眼于如何强化业务主导并促进技术快速响应业务的问题，是把低代码给谁使用以及怎样使用的问题。
银行业的应用建设痛点绝不是一般企业的代码能力不足，而是需要加强建设过程中众多部门岗位的业务同技术之间的信息转换和传递，包括让一部分信息的转换传递高效地穿透开发人工环节，直接形成最终运行系统的组成部分。
纵深视角衡量选择低代码的标准，是要更多解放业务能力，提高来自业务的信息转换传递效率，包括了：高，基于角色差异，侧重高阶信息定义，例如业务产品定义；概，基于颗粒度差异，侧重宏观信息梳理，例如业务流程梳理；本，基于形式差异，侧重本质信息抽象，例如业务模型抽象。
另外，银行业也同样存在一些小、轻、快的应用系统，并不是说来自于一般行业领域的低代码建设思维就完全不适合。
低代码的平台能力要求
基于横向与纵深两种视角，选择低代码进行应用系统建设，需要对系统的复杂度进行分析，一部分的复杂度通过同类项合并精简得到降低，减少工作量，另外一部分的复杂度需要通过非代码方式进行信息表达，让工作变容易。而最终建成完整的低代码平台，主要包含四点能力：可拿来、可定义、可落地、可管理。
可拿来，包含基础的资产库，往往凝聚了某一专业领域的长年积累，不需要所有内容从头建设，提供对应于模板组件库的能力支撑。
可定义，利用非代码的方式，将必要的流程、界面、规则、模型等信息，通过低门槛方式编辑加工，提供对应于工具体系的能力支撑。同时，定义哪些内容，何种方式定义，都体现了对该领域业务模型的理解，以及对于业务模型的组成部分进行普遍性与个性化的切割把握。
可落地，是指通过匹配的应用系统平台，提供对应于运行引擎的能力支撑。
可管理，是指通过全周期的流水线平台，提供对应于运管云平台的能力支撑。
此外，为了进一步延伸低代码平台的应用系统能力，通过加强可配置性提高对于微小业务需求变化的适配柔性，通过加强可集成性提高对遗留系统或微服务系统的整合能力。
由上可见，虽然“低代码”算是一个新概念，但真正能够把低代码有效支撑起来的，仍然是相关应用系统所属的专业领域原有的积累。而如果脱离了领域沉淀，“低代码”容易成为空中楼阁。
低代码平台的建设者基因
低代码平台的建设，脱离不了原有专业领域的积累沉淀。相似的，低代码平台的建设者，更加不可能脱离其发展成长所在领域的特征，总会携带其特色进化的基因，投入低代码建设，发挥其特有的长处优势。
兴起于面向广泛行业的企业数字化领域的低代码平台建设者，其最明显的特点是广而通。其优势是对于普遍共性问题的解决更加有经验，涉猎广泛，案例数量较多，理论水平高，但对于专业领域缺少深入积累，组件资产方面更加倾向使用者自行建设补充，所提供的低代码平台本身的定制完善服务相对有限，跨行业方法模式在专业领域的落地有待磨合和验证。
而另一类建设者，长期耕耘于某一专业领域，其中部分建设者不乏在工具平台的能力禀赋和长期产出，包括与低代码关系密切的DDD领域驱动设计也具有不少经验，其最明显的特点是专而深。其优势是对于该专业领域的沉淀更加深厚，组件模板等资产积累丰富，精通业务，脚踏实地，但是在理念推行上是跟随者，产品包装上未能强化低代码的概念，形象上不够高大上，在低代码大潮中缺少强势影响力，往往成为低代码建设的低调践行者，把事做了却默默无闻。
低代码以外的提效手段
低代码本身不是目的，而是为了用技术更快满足业务需求的提效手段。既然信息的定义表达门槛降低了，我们理应思考，为什么一定要局限在开发环节呢？
其实，就有这样的所谓“伪低代码”平台，本质就是管理系统，但也打着低代码的幌子来蹭流量。但站在满足业务需求的角度看，其价值意义没有比低代码逊色。
开发平台在进化演变，同样的，管理平台也在进化演变，两者的发展方向其实是相向而行。开发平台在降低门槛方面变得趋向业务，管理平台在提高能力方面变得趋向技术。
沿着参数管理、规则管理、流程管理的路线一步步演进，也伴随着开发运行系统的标准化建设进一步提高，管理平台将能够对越来越丰富的信息单元进行在线装配，也许这就是一种技术与业务结合的终极形态，或者是一种更高阶系统建设的原始形态。
结语
只要业务向前发展，应用系统的复杂度就会持续增加。简易总是局部短暂的，复杂才是全面永恒的。让我们对技术敬畏，更对业务敬畏，对新事物新概念保持开放心态，同时也保持独立的思考判断，不被表象迷惑，追求真实的价值创造，在投身发展的行业中，脚踏实地，跬步千里。
