为何都在谈低代码?快速了解低代码技术在 ITSM 中的应用
直达原文:【ITSM系列】为何都在谈低代码?快速了解低代码技术在ITSM中的应用
还记得早期的 Dreamweaver 吗?为了提高网页的开发效率,Dreamweaver 提供了可视化拖拽的能力来生成网页代码。可见,低代码、无代码的探索和发展其实很早就开始了。
近年来,“低代码”这个关键词突然又热了起来,相关创业公司如春笋般涌现。突然爆火的背后其实仍然是企业数字化转型的驱动,在海量软件开发需求下,现有软件生产力已经难以应对,低代码技术则是一种破局之道。
关于低代码
什么是低代码?
通过和专业的代码开发做对比,低代码、零代码本质是提供了一种更抽象的“开发语言”。通过图 1 能看到,低代码、零代码是建立在一种“建模语言”之上的,相对汇编、高级开发语言,建模语言的抽象程度更高,所以对开发者的门槛更低,只要熟悉图形的含义,就可以通过可视化的方式拖拽出符合业务逻辑的程序。BPMN 是一种比较成熟的流程建模语言,专门用于业务流程领域的业务场景构建。这也是为什么很多低代码产品能够在“偏流程管理型”的应用场景中获得成功的原因,除了市场有需求之外,技术层面有成熟的理论支撑也很重要。
还有一种做法是基于大量基础场景组件的积累,然后通过搭积木的方式来实现场景构建的低代码平台,笔者认为这种方式成功的概率很低。组件再丰富也难以应对千变万化的业务场景,只有具备用“语言”来描述场景的能力,才能真正做到以不变应万变。所以,以当前建模语言的成熟度来看,流程管理域的业务场景才更适合发挥低代码技术的应用价值。
![](https://static001.geekbang.org/infoq/54/5456f6401c11ad0f1dcc9ae1eb7745dd.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 1
为什么要低代码?
企业完成核心业务流程的数字化之后,下一步可能会聚焦到内部运营效率的提升,内部运营管理的效率同样是组织的一种核心竞争力。而内部运营支撑系统又不及业务系统那么重要,不可能为此花费过多的软件开发投入,也无法简单引入一套功能丰富的系统(如:ERP、OA)就可以解决问题,很多边缘的、零碎的个性化管理场景是难以覆盖,导致开发需求急剧上升,IT 部门如果仍然以传统的开发方式,不管是自研还是引入外部开发团队,其生产力都远远无法满足这些频繁变化的、零散个性化的需求。因此低代码的价值就凸显出来了,其很重要的一点是实现全民开发,即人人都是开发者。如果能真正运营起来,其软件的生产力可以是指数级上升的。
流程建模语言
既然低代码的核心是建模语言,那么,我们以最常见的流程建模来看看什么是建模语言。此外,ITSM 承载的是运维、运营的流程管理体系,其核心也是流程类的业务场景居多。因此,我们可以聚焦到流程领域再深入看看,进一步理解低代码的底层逻辑,也便于后续理解低代码在 ITSM 中的应用。
在流程管理领域中使用最广泛的建模语言莫过于 OMG 发布的 BPMN/DMN/CMMN 等标准,各种主流的开源流程引擎、规则引擎,如:Activiti、JBPM 等,都是基于这些标准进行设计的。
![](https://static001.geekbang.org/infoq/49/497a62f8da77c54525109f63cf58b377.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 2
当然,这些引擎也不是百分百实现了前面三个标准,和其发展的重心和年限有关。
BPMN
在管理机制的设计中,有一个很重要的点就是“工作流”的设计。通常来说,管理流程越成熟,工作流越固化,即某个工作不再需要太多的创造性了,只要按固定的工作流一步一步去完成,就能得到好的工作结果。BPMN 的标准就非常适合此类情况,即用于描述可预定义的、固定顺序的工作流。
![](https://static001.geekbang.org/infoq/23/23b64f0f3450de32d9cb6234735db4cf.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 3 固化工作流
BPMN 语言中关键要素包括活动、网关和事件,通过这些对象符号来描述一个标准的工作流程。(如对更详细图形符号感兴趣,可查阅官方资料,这里不做更详细地展开。)
CMMN
工作的流程完全固化是一种比较理想的情况,实际管理过程中,成熟度都是从混乱发展到可定义级别的,在还没找到适合组织的最佳工作实践的情况下,更多还是靠人的主观能动性来解决问题。例如:当某个运维事件的发生,通常依赖于成熟的工程师临时做出判断,并拆解出几个关键任务来进行处理,分别由谁来执行,顺序是如何的。这种不确定的、无法预定义的工作过程就难以用 BPMN 来建模描述了,而 CMMN 的标准则更加适合此类场景。
![](https://static001.geekbang.org/infoq/7b/7bbcd2efe58b78e088dab62b794e158d.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 4 CMMN 场景案例
DMN
管理过程中还有一个很重要的活动就是决策,不同的决策结果会影响后续的工作流程。例如:某个变更是否要执行,就需要人为判断变更的风险程度来决定后续的处理策略。针对此类决策的活动场景,最佳实践则是通过 DMN 标准来进行描述。通过下图对比可以直观看出在决策场景中用与不用 DMN 的区别。
![](https://static001.geekbang.org/infoq/f0/f0633bd34fcb0a895c6c3a1f09b78351.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 5
最佳实践
如前面章节所述,在流程建模过程中,不同的标准适用于不同的场景。那具体到一个完整流程的设计,应该如何判断选择怎样的标准组合呢?同样行业中也提供了最佳实践的参考原则:
![](https://static001.geekbang.org/infoq/08/0819190af928c4b3c40073cda70e8584.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 6 最佳实践
业务流程中使用了一系列的网关,这个时候可以考虑使用 DMN 决策引擎代替。
业务流程中使用了大量的事件,则可以优先考虑使用 CMMN。
业务流程中有一系列的加签、自由流程,则优先考虑使用 CMMN。
CMMN 中如果案例内的元素都是有严格的执行顺序,则优先考虑使用 BPMN 标准。
低代码引擎设计
引擎模块体系
要通过低代码完整地实现一个管理类应用的闭环构建,通常需要五大引擎能力进行配合。
![](https://static001.geekbang.org/infoq/17/1708596eef0c1528f568da9c805e2f1f.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 7
引擎功能设计
如下是各引擎模块的定位、功能设计参考。
![](https://static001.geekbang.org/infoq/16/16388e46e1396461f082de467e37193a.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 8
低代码在 ITSM 中的应用
运维工单构建
![](https://static001.geekbang.org/infoq/3b/3ba66d7912ca3f048d7b326dff8d834b.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 9
最能反映运维管理的业务逻辑的是运维工单的设计,细节到一个事件优先级的定义、问题类别的定义等,都能对运维工作产生影响,甚至影响到是否满足监管合规。因此,即使过了建设期,在运营期间也可能对已定义好的表单进行细微调整,此时 ITSM 表单的灵活性就非常重要。基于表单引擎可以对运维工单进行可视化建模,包括表单字段的定义、表单字段数据来源的定义、表单字段之间交互规则的定义、表单字段之间数据联动规则的定义等,以应对表单频繁变化的场景。常见的应用场景如下:
承载事件/问题/变更等流程表单的自定义;
承载场景化流程表单的自定义,如:资源申请、权限申请等。
运维工作流构建
![](https://static001.geekbang.org/infoq/d4/d4a4902e330ded41cad35a7f0aefb33e.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 10
运维工作流反映的是运维工作的协同过程。在运维管理中,不仅仅是人与人的协同,还可能人与系统、系统与系统间的协同。基于工作流引擎可以对运维工作进行端到端协同层面建模,包括工作流中活动的定义、分支的定义、审批的定义、事件的定义等。在 ITSM 中的应用场景如下:
审批场景:多级审批、多人审批、加签审批等;
协作场景:事件处理的一线、二线之间的升级流转、工单转派、任务分配等;
集成场景:工作流与自动化作业流的端到端打通。
运维管理策略构建
![](https://static001.geekbang.org/infoq/86/865b2b93b6a3b19f3846fd0c3ffb43c1.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 11
在实际的运维工作中,还存在大量的管理策略规则,比如:事件处理的分派策略、优先级矩阵、风险评估、审批策略等。这些看似简单的逻辑,对效率和成本影响可不容忽视,因为通常属于一种高频的活动,例如:服务台人员一天可能需要执行上百次分派的动作。基于规则引擎,通过决策表、决策树等方式,可以灵活地将规则进行固化,代替人工操作。
运维度量报表构建
![](https://static001.geekbang.org/infoq/1e/1ea62dee23ccd2ea1c3ea2fc6b6a8373.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 12
度量是运维管理持续改进的前提,一是度量指标的设计,二是获取准确的度量数据。同样,度量报表并不是一成不变的设计,而是随着管理的成熟度变化而变化,不同阶段、不同管理者的要求也会带来新的变化。例如:流程运行的初期,我们更关注的是流程有没有推广起来,因此更聚焦工单数量相关的度量指标。随着流程逐步运行成熟,我们开始关注工作的成效,如关单率、平均处理时效等。管理要求进一步提升之后,还可能需要度量 SLA 的达成情况。基于轻量的报表引擎,可以灵活动态响应此类度量要求,通过数据接入、度量维度定义、度量指标定义、仪表盘编排等能力快速沟通运维度量报表。
运维工作台构建
![](https://static001.geekbang.org/infoq/15/15e69d80b2506f0fcb2485efd0386701.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
图 13
ITSM 面向的用户广泛,不仅有运维工程师,还有终端普通用户、运维领导等。不同角色关注的重心不一样,为了提供更好的体验,面向用户的视图可能是千人千面的,基于视图引擎,可以定义不同的视图内容、视图排版、视图样式等,以满足交互和视觉层面的个性化诉求。
总结
低代码本质上还是一种“开发语言”,而不是组件的堆砌和拼装。流程管理领域的低代码技术相对成熟,有完善的建模语言作为支撑。因此,低代码技术可以在 ITSM 领域较好的发挥其价值,以应对流程数量的激增、管理要求的频繁变化等,更好地助力 IT 服务管理的数字化建设。
评论