低代码平台的分类定位，以及需要购买实施服务吗？

　　问：购买ERP需要实施服务吗？
　　回答  ：需要
　　问：购买Visual Studio需要实施服务吗？
　　回答：  不需要实施，但需要支持服务
　　问：购买低代码平台需要实施服务吗？
　　回答：[黑线]
　　作者与不少企业CIO沟通过，他们往往在决定选购低代码平台的时候，非常看重低代码厂商的实施团队，甚至会要求 本地而且原厂 的实施团队提供服务。要解答这个现象，要从两个维度来拆解：
　　1、低代码平台自身的能力和定位。
　　2、甲方如何定位低代码平台。
　　一、低代码平台的定位
　　看到这标题，很多低代码行业从业者都会脱口而出＂aPaaS＂、＂中台＂、＂数字化转型＂等等。这类概念输出我们先抛开不谈，作者认为低代码按照其使用方式来分类，只有三类：
　　（1）加速开发的可视化IDE： 这类低代码平台，对开发人员吸引力强，而且所能够应用的复杂度高，代表厂商是Outsystems、Mendix（国内的很多厂商已经在Copy ing）。这类平台私有化、SaaS模式均支持，可以实现专业开发团队分工，内置的建模工具、界面设计、逻辑构建、部署工具、运维后台均提供独立的用户界面，并具有断点调试、版本管理、插件扩展等特性。
　　（2）快速建模的搭建工具： 这里作者没有写平台，而写的是工具，这类低代码平台能够快速地搭建表单、流程，并配有集成工具，但是由于其平台自身局限性，无法构建复杂应用。对于甲方也确实能够解决个性化的业务问题，并且在其框架流程内，应用搭建速度提升飞快。此类工具厂商会不断地迭代增加其工具属性，例如添加API组件。这类工具，经常以saas的形式对外售卖输出，其特点是具有逻辑能力的非专业开发在也可以构建出不错的应用出来。
　　*作者观点：这类工具才是中国厂商的主战场，因为我们更擅长＂用户体验＂以及模式创新，而对于专业开发工具的构建则底蕴不足。但，仍希望国产厂商努力加油，做出中国自己的开发工具出来。
　　（3）方便应用开发的脚手架： 为什么说有些＂低代码平台＂只是脚手架？这类平台往往具有快速进行表单、流程等模块的快速构建能力，但是由于其往往对企业进行私有化输出，所以往往会开放全部或者至少是用于二次开发的代码，企业基于该脚手架，可以开发出更多的场景。但是，由于其二次开发特性，开发者往往不能遵循最佳时间进行应用服务构建，并且必然会面对平台持续性升级的问题，特别是前端，由于前端工程性问题，无法实现类似于后端的插件式扩展构建。此类低代码平台，在无数次的迭代过程中，逐渐沦为脚手架或者是一个框架。
　　看到了吗？不同类型的代码，适用的人群和门槛完全不同。
　　二、甲方对低代码平台的定位
　　甲方该如何定位低代码平台呢，其实看到了低代码的分类后，也就知道了甲方会如何购买（这里我们抛开预算不谈）以及使用低代码平台。甲方应该根据实际的需要，实际的情况决定，到底应该购买哪一类低代码平台。
　　但实际上，作者在实际工作中也发现了众多甲方甚至是乙方自身对于低代码平台理解的误区：
　　（1）低代码平台既可以让不懂代码的人使用，也可以供专业开发者来进行复杂应用构建： 这里作者冒昧地武断一句，这种想法非常不切实际而且也不正确。供专业开发人员使用的低代码平台只有可能把其中的某几个模块暴露出来供非专业开发人员使用，比如UI界面设计，可以让UI/UE来拖拽使用。如果一个低代码平台主打简单、易用，那么其自身的开放性和扩展性是有很大限制的。
　　（2）低代码平台会让开发人员失业： 这个想法非常普遍，但实际上要辩证地来看这个问题，如果一个开发人员可以被低代码平台替换掉，其实更应该自省自己是不是每天都在重复的做CRUD。
　　（3）低代码平台可以做中台、实现数字化转型： 低代码平台只是工具，要想转型，要想优化业务还是要靠人的脑子，靠咨询公司。
　　再回到问题中来，低代码平台需要实施服务吗？显而易见，如果购买的是专业级别的IDE，那么你更应该考虑的是技术支持服务。对于其他的业务需求，或者是想要引入上述第二三种低代码平台，实施服务就看自己公司的实际需求吧。