3. 低代码阵营分两条路
低代码这个概念一出来,市场上就冒出了各种形态的'低代码平台',有的像Excel加工作流,有的像可视化开发环境。很多人纠结于功能对比,但真正决定选型的,是这些平台想解决的根本问题不一样——你到底是想快速出活,还是想让系统能长期改下去?
Forrester 把低代码平台分成了两类:
- 面向业务开发者(LCDP for Business Developers)
- 面向专业开发者(LCDP for Professional Developers)
注意,这里的'业务'和'专业'不是指写代码的技能高低,而是他们在组织里的角色和负责的边界不同。这种差异,直接带来了两种完全不同的价值取向。
3.1 面向业务开发者:图个快,别算长远账
这类平台通常就是表单驱动,把数据和逻辑揉在一起,衍生自 ERP、OA 里的可配置技术,用起来像在实施成品软件。市场上常叫它'无代码'。
业务开发者是谁?他们不归IT管,但自己动手给团队做个小系统用,类似 Gartner 说的平民开发者。在公司里,他们往往是流程负责人、业务负责人或者运营负责人。他们门儿清业务规则,但对长期技术维护既没责任也没动力。
所以,这类平台的出发点不是'构建一个可以不断演进的软件系统',而是用最短路径把明确的业务目标变成能用的工具。在业务部门看来,软件价值就是:
- 当下问题解决了没?
- 能不能快速支撑一个管理动作?
- 短期内有没有看得见的效果?
说白了,这类平台的价值就是压低一次性投入成本和沟通摩擦,迅速出成果。
但问题是,一旦这些工具开始要跨部门协同、规则越搞越复杂、数据被反复引用时,隐性成本就冒头了:配置乱成了麻,治理跟不上;应用一大堆,数据互相不认;看起来产出很多'应用',整体却越来越难维护。这不是平台不行,而是它生来就是为了压住显性成本,追求短期成果最大化,不负责长期演进。
3.2 面向专业开发者:把变化的长期成本算进来
与上面那类相反,面向专业开发者的低代码平台把数据和逻辑拆开,是模型驱动的,源于可视化开发技术的演进,有明确的开发态和运行态之分。通常被叫作'狭义低代码'。
这一类平台的价值起点不是更快交付某个应用,而是当你需要持续改动时,系统不至于乱掉。专业开发者不是技术多高超,而是因为他们向IT部门汇报,有动力也有责任让系统稳定、可扩展、安全、可维护。他们承担的,是系统负责人和技术治理者的角色。所以,他们衡量软件价值的天平,自然偏向成本:
- 每次业务变化,改动成本是不是可控?
- 系统越做越大,复杂度是不是线性增长?
- 换人接手,系统还理得清楚吗?
所以这类平台不试图隐藏复杂性,而是用适度的工程抽象,把通用中间件和规范内建进去,把重复出现的结构固化为模型和约束,让变化的影响范围落到可控边界内。
它存在的目的不是消灭代码,而是降低长期变化的成本,持续提升IT团队的产出能力。通过重构生产方式,让系统在持续变化中还能保持结构稳定,支撑真正的可持续演进。
代价呢,就是对企业提出了更高的前置要求,我把它概括成四个前提。
前提一:开发者必须愿意持续学习平台抽象
和业务开发者的低代码不同,这里的平台不会把复杂性藏起来。相反,它会通过模型、约束和规范把复杂性重新暴露出来让你管理。开发者得理解这些抽象背后的设计道理,才能在变化发生时用对平台能力,而不是绕道走。低代码在这里更像一门新的工程语言。如果团队光想着用它写更快,而不愿花时间弄懂架构思想和治理边界,那所谓的长期成本优势根本兑现不了。
前提二:企业得有技术治理的意识和制度保障
因为这类平台的目标是控制长期成本,它一定会引入统一的数据模型、服务边界、权限体系和扩展规范。但这些不会自动生效,得靠制度、流程和角色分工落地,比如:
- 哪些能力用内建模型实现,哪些走扩展
- 限制跨系统、跨模块的依赖方式,避免隐性耦合
- 关键模型和服务的变更有评审和演进规则
如果企业还是'项目做完就散伙',没有对系统整体结构的长期治理,那平台的工程抽象很快就会被侵蚀,退化成另一种快速堆砌。
前提三:不适合完全去中心化的开发模式
平台强调结构稳定和可持续演进,就必须有人对系统整体负责。这要求企业至少在核心系统层面,保留架构责任和平台责任的角色,不能把所有开发彻底下沉、完全分散。如果组织内部对统一技术路线和长期架构约束有抵触,那这类低代码的优势就很难发挥,还会被抱怨'限制灵活性'。

