据部分研究者指出，市场初期阶段往往由集成解决方案主导——即由同一供应商从头到尾打造的产品。 这种现象的成因通常在于可靠性和性能。换言之，在市场发展初期，由多家制造商组件构成的产品往往不如集成产品可靠，性能也稍逊一筹。但这引发了一个耐人寻味的问题：在市场演进的哪个阶段，模块化会超越集成化？换句话说，转折点究竟在哪里？
手写代码解决方案的问题
对于企业软件公司而言，这个临界点尤为关键，特别是针对点解决方案——这类软件应用本质上是填补核心业务系统间空白的桥梁，通常专注于解决特定问题。 然而，随着分散的市场力量不断推动各业务单元对点解决方案提出日益多样化的需求，软件供应商手动编写通用解决方案变得愈发困难。事实上，如今要手动编写出能满足单个客户大部分需求的解决方案已非易事，更遑论覆盖市场中相当大的细分领域。 当然，为特定客户定制的解决方案是例外。但考虑到手动编写复杂点解决方案所需的时间（可能长达数月），这类系统在交付前就可能出现问题——现实商业世界中业务流程的快速演变正是导致这种情况的根源。
低代码的演进
在我所处的特定IT领域，孤岛式点解决方案的黄金时代已然终结。如今客户需要的是能与现有投资系统无缝集成的解决方案。这一现实催生了新型快速应用开发平台的崛起，Forrester将其称为 低代码。在2014年6月的报告中，Forrester将低代码领域划分为三大板块：通用应用平台、网页内容平台以及业务流程平台（BPM）。在我看来，最后这一类尤为重要——毕竟工作流在企业环境中的核心地位不言而喻。
包装应用程序的BPM
若问AgilePoint首席执行官杰西·夏（Jesse Shiah）——这位被Forrester评为低代码BPM领域领导者的人物——关于公司技术的演进历程，他可能会将AgilePoint称为"SaaS工厂"。 换言之，Shiah如今将自家BPM平台视为第三方软件供应商的基石——他们不仅能够，更应当在此基础上为客户构建点解决方案。原因何在？Shiah指出，采用C#或Java手工编码可能耗时18个月的点解决方案，使用AgilePoint平台仅需6至10周即可完成。 我认为其他低代码BPM供应商（如K2、Nintex、Bizagi和Micropact）的领导者也会表达类似观点。更重要的是，创建调用其他系统的封装应用程序（复合应用程序）正是BPM系统的设计初衷，也是其真正擅长的领域。
临界点就在当下
就在几年前，手工编码的点解决方案通常仍是最佳选择。但如今在低代码平台环境中设计的解决方案，已能提供用户所期待的全部性能。此外，低代码解决方案还能整合顶尖组件，例如 HotDocs云服务用于文档组装 用于文档组装、NetDocuments用于 文档管理，以及任何具有公开API的网络服务。
除了能够快速构建系统以及可集成多种顶尖组件之外，采用低代码方法还意味着无需重新构建整个系统即可升级或替换单个系统组件。同样，低代码BPM方法有助于避免在关键组件上陷入供应商锁定困境。
编者按 本文最初发表于 HotDocs.com.2024 年 6 月，Mitratech 收购了高级文档自动化平台 HotDocs。此后，我们对内容进行了更新，以纳入与我们的产品、法规变化和合规性相一致的信息。
