为何都在谈低代码？快速了解低代码技术在ITSM中的应用

为何都在谈低代码？快速了解低代码技术在ITSM中的应用

本文来自腾讯蓝鲸智云社区用户: CanWay

还记得早期的Dreamweaver吗？为了提高网页的开发效率，Dreamweaver提供了可视化拖拽的能力来生成网页代码。可见，低代码、无代码的探索和发展其实很早就开始了。

近年来，“低代码”这个关键词突然又热了起来，相关创业公司如春笋般涌现。突然爆火的背后其实仍然是企业数字化转型的驱动，在海量软件开发需求下，现有软件生产力已经难以应对，低代码技术则是一种破局之道。

关于低代码

通过和专业的代码开发做对比，低代码、零代码本质是提供了一种更抽象的“开发语言”。通过图1能看到，低代码、零代码是建立在一种“建模语言”之上的，相对汇编、高级开发语言，建模语言的抽象程度更高，所以对开发者的门槛更低，只要熟悉图形的含义，就可以通过可视化的方式拖拽出符合业务逻辑的程序。BPM是一种比较成熟的流程建模语言，专门用于业务流程领域的业务场景构建。这也是为什么很多低代码产品能够在“偏流程管理型”的应用场景中获得成功的原因，除了市场有需求之外，技术层面有成熟的理论支撑也很重要。

还有一种做法是基于大量基础场景组件的积累，然后通过搭积木的方式来实现场景构建的低代码平台，笔者认为这种方式成功的概率很低。组件再丰富也难以应对千变万化的业务场景，只有具备用“语言”来描述场景的能力，才能真正做到以不变应万变。所以，以当前建模语言的成熟度来看，流程管理域的业务场景才更适合发挥低代码技术的应用价值。

图1

企业完成核心业务流程的数字化之后，下一步可能会聚焦到内部运营效率的提升，内部运营管理的效率同样是组织的一种核心竞争力。而内部运营支撑系统又不及业务系统那么重要，不可能为此花费过多的软件开发投入，也无法简单引入一套功能丰富的系统（如：ERP、OA）就可以解决问题，很多边缘的、零碎的个性化管理场景是难以覆盖，导致开发需求急剧上升，IT部门如果仍然以传统的开发方式，不管是自研还是引入外部开发团队，其生产力都远远无法满足这些频繁变化的、零散个性化的需求。因此低代码的价值就凸显出来了，其很重要的一点是实现全民开发，即人人都是开发者。如果能真正运营起来，其软件的生产力可以是指数级上升的。

既然低代码的核心是建模语言，那么，我们以最常见的流程建模来看看什么是建模语言。此外，ITSM承载的是运维、运营的流程管理体系，其核心也是流程类的业务场景居多。因此，我们可以聚焦到流程领域再深入看看，进一步理解低代码的底层逻辑，也便于后续理解低代码在ITSM中的应用。

在流程管理领域中使用最广泛的建模语言莫过于OMG发布的BPM/DM/CMM等标准，各种主流的开源流程引擎、规则引擎，如：Activiti、JBPM等，都是基于这些标准进行设计的。

图2

当然，这些引擎也不是百分百实现了前面三个标准，和其发展的重心和年限有关。

1、BPM

在管理机制的设计中，有一个很重要的点就是“工作流”的设计。通常来说，管理流程越成熟，工作流越固化，即某个工作不再需要太多的创造性了，只要按固定的工作流一步一步去完成，就能得到好的工作结果。BPM的标准就非常适合此类情况，即用于描述可预定义的、固定顺序的工作流。

图 固化工作流

BPM语言中关键要素包括活动、网关和事件，通过这些对象符号来描述一个标准的工作流程。（如对更详细图形符号感兴趣，可查阅官方资料，这里不做更详细地展开。）

2、CMM

工作的流程完全固化是一种比较理想的情况，实际管理过程中，成熟度都是从混乱发展到可定义级别的，在还没到适合组织的最佳工作实践的情况下，更多还是靠人的主观能动性来解决问题。例如：当某个运维事件的发生，通常依赖于成熟的工程师临时做出判断，并拆解出几个关键任务来进行处理，分别由谁来执行，顺序是如何的。这种不确定的、无法预定义的工作过程就难以用BPM来建模描述了，而CMM的标准则更加适合此类场景。

图4 CMM场景案例

、DM

管理过程中还有一个很重要的活动就是决策，不同的决策结果会影响后续的工作流程。例如：某个变更是否要执行，就需要人为判断变更的风险程度来决定后续的处理策略。针对此类决策的活动场景，最佳实践则是通过DM标准来进行描述。通过下图对比可以直观看出在决策场景中用与不用DM的区别。

图5

4、最佳实践

如前面章节所述，在流程建模过程中，不同的标准适用于不同的场景。那具体到一个完整流程的设计，应该如何判断选择怎样的标准组合呢？同样行业中也提供了最佳实践的参考原则：

图6 最佳实践

• 业务流程中使用了一系列的网关，这个时候可以考虑使用DM决策引擎代替。
• 业务流程中使用了大量的事件，则可以优先考虑使用CMM。
• 业务流程中有一系列的加签、自由流程，则优先考虑使用CMM。
• CMM中如果案例内的元素都是有严格的执行顺序，则优先考虑使用BPM标准。

引擎模块体系

要通过低代码完整地实现一个管理类应用的闭环构建，通常需要五大引擎能力进行配合。

图7

引擎功能设计

如下是各引擎模块的定位、功能设计参考。

图8

低代码在ITSM中的应用

图9

最能反映运维管理的业务逻辑的是运维工单的设计，细节到一个事件优先级的定义、问题类别的定义等，都能对运维工作产生影响，甚至影响到是否满足监管合规。因此，即使过了建设期，在运营期间也可能对已定义好的表单进行细微调整，此时ITSM表单的灵活性就非常重要。基于表单引擎可以对运维工单进行可视化建模，包括表单字段的定义、表单字段数据来源的定义、表单字段之间交互规则的定义、表单字段之间数据联动规则的定义等，以应对表单频繁变化的场景。常见的应用场景如下：

• 承载事件/问题/变更等流程表单的自定义；
• 承载场景化流程表单的自定义，如：资源申请、权限申请等。

图10

运维工作流反映的是运维工作的协同过程。在运维管理中，不仅仅是人与人的协同，还可能人与系统、系统与系统间的协同。基于工作流引擎可以对运维工作进行端到端协同层面建模，包括工作流中活动的定义、分支的定义、审批的定义、事件的定义等。在ITSM中的应用场景如下：

• 审批场景：多级审批、多人审批、加签审批等；
• 协作场景：事件处理的一线、二线之间的升级流转、工单转派、任务分配等；
• 集成场景：工作流与自动化作业流的端到端打通。运维管理策略构建在这里插入图片描述

图11

在实际的运维工作中，还存在大量的管理策略规则，比如：事件处理的分派策略、优先级矩阵、风险评估、审批策略等。这些看似简单的逻辑，对效率和成本影响可不容忽视，因为通常属于一种高频的活动，例如：服务台人员一天可能需要执行上百次分派的动作。基于规则引擎，通过决策表、决策树等方式，可以灵活地将规则进行固化，代替人工操作。

图12

度量是运维管理持续改进的前提，一是度量指标的设计，二是获取准确的度量数据。同样，度量报表并不是一成不变的设计，而是随着管理的成熟度变化而变化，不同阶段、不同管理者的要求也会带来新的变化。例如：流程运行的初期，我们更关注的是流程有没有推广起来，因此更聚焦工单数量相关的度量指标。随着流程逐步运行成熟，我们开始关注工作的成效，如关单率、平均处理时效等。管理要求进一步提升之后，还可能需要度量SLA的达成情况。基于轻量的报表引擎，可以灵活动态响应此类度量要求，通过数据接入、度量维度定义、度量指标定义、仪表盘编排等能力快速沟通运维度量报表。

图1

ITSM面向的用户广泛，不仅有运维工程师，还有终端普通用户、运维领导等。不同角关注的重心不一样，为了提供更好的体验，面向用户的视图可能是千人千面的，基于视图引擎，可以定义不同的视图内容、视图排版、视图样式等，以满足交互和视觉层面的个性化诉求。

总结

低代码本质上还是一种“开发语言”，而不是组件的堆砌和拼装。流程管理领域的低代码技术相对成熟，有完善的建模语言作为支撑。因此，低代码技术可以在ITSM领域较好的发挥其价值，以应对流程数量的激增、管理要求的频繁变化等，更好地助力IT服务管理的数字化建设。