還記得早期的Dreamweaver嗎？為了提高網(wǎng)頁的開發(fā)效率，Dreamweaver提供了可視化拖拽的能力來生成網(wǎng)頁代碼?？梢姡痛a、無代碼的探索和發(fā)展其實很早就開始了。

近年來，“低代碼”這個關(guān)鍵詞突然又熱了起來，相關(guān)創(chuàng)業(yè)公司如春筍般涌現(xiàn)。突然爆火的背后其實仍然是企業(yè)數(shù)字化轉(zhuǎn)型的驅(qū)動，在海量軟件開發(fā)需求下，現(xiàn)有軟件生產(chǎn)力已經(jīng)難以應(yīng)對，低代碼技術(shù)則是一種破局之道。

關(guān)于低代碼

什么是低代碼？

通過和專業(yè)的代碼開發(fā)做對比，低代碼、零代碼本質(zhì)是提供了一種更抽象的“開發(fā)語言”。通過圖1能看到，低代碼、零代碼是建立在一種“建模語言”之上的，相對匯編、高級開發(fā)語言，建模語言的抽象程度更高，所以對開發(fā)者的門檻更低，只要熟悉圖形的含義，就可以通過可視化的方式拖拽出符合業(yè)務(wù)邏輯的程序。BPMN是一種比較成熟的流程建模語言，專門用于業(yè)務(wù)流程領(lǐng)域的業(yè)務(wù)場景構(gòu)建。這也是為什么很多低代碼產(chǎn)品能夠在“偏流程管理型”的應(yīng)用場景中獲得成功的原因，除了市場有需求之外，技術(shù)層面有成熟的理論支撐也很重要。

還有一種做法是基于大量基礎(chǔ)場景組件的積累，然后通過搭積木的方式來實現(xiàn)場景構(gòu)建的低代碼平臺，筆者認(rèn)為這種方式成功的概率很低。組件再豐富也難以應(yīng)對千變?nèi)f化的業(yè)務(wù)場景，只有具備用“語言”來描述場景的能力，才能真正做到以不變應(yīng)萬變。所以，以當(dāng)前建模語言的成熟度來看，流程管理域的業(yè)務(wù)場景才更適合發(fā)揮低代碼技術(shù)的應(yīng)用價值。

圖1

為什么要低代碼？

企業(yè)完成核心業(yè)務(wù)流程的數(shù)字化之后，下一步可能會聚焦到內(nèi)部運營效率的提升，內(nèi)部運營管理的效率同樣是組織的一種核心競爭力。而內(nèi)部運營支撐系統(tǒng)又不及業(yè)務(wù)系統(tǒng)那么重要，不可能為此花費過多的軟件開發(fā)投入，也無法簡單引入一套功能豐富的系統(tǒng)（如：ERP、OA）就可以解決問題，很多邊緣的、零碎的個性化管理場景是難以覆蓋，導(dǎo)致開發(fā)需求急劇上升，IT部門如果仍然以傳統(tǒng)的開發(fā)方式，不管是自研還是引入外部開發(fā)團隊，其生產(chǎn)力都遠遠無法滿足這些頻繁變化的、零散個性化的需求。因此低代碼的價值就凸顯出來了，其很重要的一點是實現(xiàn)全民開發(fā)，即人人都是開發(fā)者。如果能真正運營起來，其軟件的生產(chǎn)力可以是指數(shù)級上升的。

流程建模語言

既然低代碼的核心是建模語言，那么，我們以最常見的流程建模來看看什么是建模語言。此外，ITSM承載的是運維、運營的流程管理體系，其核心也是流程類的業(yè)務(wù)場景居多。因此，我們可以聚焦到流程領(lǐng)域再深入看看，進一步理解低代碼的底層邏輯，也便于后續(xù)理解低代碼在ITSM中的應(yīng)用。

在流程管理領(lǐng)域中使用最廣泛的建模語言莫過于OMG發(fā)布的BPMN/DMN/CMMN等標(biāo)準(zhǔn)，各種主流的開源流程引擎、規(guī)則引擎，如：Activiti、JBPM等，都是基于這些標(biāo)準(zhǔn)進行設(shè)計的。

圖2

當(dāng)然，這些引擎也不是百分百實現(xiàn)了前面三個標(biāo)準(zhǔn)，和其發(fā)展的重心和年限有關(guān)。

1、BPMN

在管理機制的設(shè)計中，有一個很重要的點就是“工作流”的設(shè)計。通常來說，管理流程越成熟，工作流越固化，即某個工作不再需要太多的創(chuàng)造性了，只要按固定的工作流一步一步去完成，就能得到好的工作結(jié)果。BPMN的標(biāo)準(zhǔn)就非常適合此類情況，即用于描述可預(yù)定義的、固定順序的工作流。

圖3 固化工作流

BPMN語言中關(guān)鍵要素包括活動、網(wǎng)關(guān)和事件，通過這些對象符號來描述一個標(biāo)準(zhǔn)的工作流程。（如對更詳細圖形符號感興趣，可查閱官方資料，這里不做更詳細地展開。）

2、CMMN

工作的流程完全固化是一種比較理想的情況，實際管理過程中，成熟度都是從混亂發(fā)展到可定義級別的，在還沒找到適合組織的最佳工作實踐的情況下，更多還是靠人的主觀能動性來解決問題。例如：當(dāng)某個運維事件的發(fā)生，通常依賴于成熟的工程師臨時做出判斷，并拆解出幾個關(guān)鍵任務(wù)來進行處理，分別由誰來執(zhí)行，順序是如何的。這種不確定的、無法預(yù)定義的工作過程就難以用BPMN來建模描述了，而CMMN的標(biāo)準(zhǔn)則更加適合此類場景。

圖4 CMMN場景案例

3、DMN

管理過程中還有一個很重要的活動就是決策，不同的決策結(jié)果會影響后續(xù)的工作流程。例如：某個變更是否要執(zhí)行，就需要人為判斷變更的風(fēng)險程度來決定后續(xù)的處理策略。針對此類決策的活動場景，最佳實踐則是通過DMN標(biāo)準(zhǔn)來進行描述。通過下圖對比可以直觀看出在決策場景中用與不用DMN的區(qū)別。

圖5

4、最佳實踐

如前面章節(jié)所述，在流程建模過程中，不同的標(biāo)準(zhǔn)適用于不同的場景。那具體到一個完整流程的設(shè)計，應(yīng)該如何判斷選擇怎樣的標(biāo)準(zhǔn)組合呢？同樣行業(yè)中也提供了最佳實踐的參考原則：

圖6 最佳實踐

• 業(yè)務(wù)流程中使用了一系列的網(wǎng)關(guān)，這個時候可以考慮使用DMN決策引擎代替。
• 業(yè)務(wù)流程中使用了大量的事件，則可以優(yōu)先考慮使用CMMN。
• 業(yè)務(wù)流程中有一系列的加簽、自由流程，則優(yōu)先考慮使用CMMN。
• CMMN中如果案例內(nèi)的元素都是有嚴(yán)格的執(zhí)行順序，則優(yōu)先考慮使用BPMN標(biāo)準(zhǔn)。

低代碼引擎設(shè)計

引擎模塊體系

要通過低代碼完整地實現(xiàn)一個管理類應(yīng)用的閉環(huán)構(gòu)建，通常需要五大引擎能力進行配合。

圖7

引擎功能設(shè)計

如下是各引擎模塊的定位、功能設(shè)計參考。

圖8

低代碼在ITSM中的應(yīng)用

運維工單構(gòu)建

圖9

最能反映運維管理的業(yè)務(wù)邏輯的是運維工單的設(shè)計，細節(jié)到一個事件優(yōu)先級的定義、問題類別的定義等，都能對運維工作產(chǎn)生影響，甚至影響到是否滿足監(jiān)管合規(guī)。因此，即使過了建設(shè)期，在運營期間也可能對已定義好的表單進行細微調(diào)整，此時ITSM表單的靈活性就非常重要?；诒韱我婵梢詫\維工單進行可視化建模，包括表單字段的定義、表單字段數(shù)據(jù)來源的定義、表單字段之間交互規(guī)則的定義、表單字段之間數(shù)據(jù)聯(lián)動規(guī)則的定義等，以應(yīng)對表單頻繁變化的場景。常見的應(yīng)用場景如下：

• 承載事件/問題/變更等流程表單的自定義；
• 承載場景化流程表單的自定義，如：資源申請、權(quán)限申請等。

運維工作流構(gòu)建

圖10

運維工作流反映的是運維工作的協(xié)同過程。在運維管理中，不僅僅是人與人的協(xié)同，還可能人與系統(tǒng)、系統(tǒng)與系統(tǒng)間的協(xié)同?；?span id="0w8w0ww" class="candidate-entity-word" data-gid="15430054">工作流引擎可以對運維工作進行端到端協(xié)同層面建模，包括工作流中活動的定義、分支的定義、審批的定義、事件的定義等。在ITSM中的應(yīng)用場景如下：

• 審批場景：多級審批、多人審批、加簽審批等；
• 協(xié)作場景：事件處理的一線、二線之間的升級流轉(zhuǎn)、工單轉(zhuǎn)派、任務(wù)分配等；
• 集成場景：工作流與自動化作業(yè)流的端到端打通。

運維管理策略構(gòu)建

圖11

在實際的運維工作中，還存在大量的管理策略規(guī)則，比如：事件處理的分派策略、優(yōu)先級矩陣、風(fēng)險評估、審批策略等。這些看似簡單的邏輯，對效率和成本影響可不容忽視，因為通常屬于一種高頻的活動，例如：服務(wù)臺人員一天可能需要執(zhí)行上百次分派的動作?；谝?guī)則引擎，通過決策表、決策樹等方式，可以靈活地將規(guī)則進行固化，代替人工操作。

運維度量報表構(gòu)建

圖12

度量是運維管理持續(xù)改進的前提，一是度量指標(biāo)的設(shè)計，二是獲取準(zhǔn)確的度量數(shù)據(jù)。同樣，度量報表并不是一成不變的設(shè)計，而是隨著管理的成熟度變化而變化，不同階段、不同管理者的要求也會帶來新的變化。例如：流程運行的初期，我們更關(guān)注的是流程有沒有推廣起來，因此更聚焦工單數(shù)量相關(guān)的度量指標(biāo)。隨著流程逐步運行成熟，我們開始關(guān)注工作的成效，如關(guān)單率、平均處理時效等。管理要求進一步提升之后，還可能需要度量SLA的達成情況?；谳p量的報表引擎，可以靈活動態(tài)響應(yīng)此類度量要求，通過數(shù)據(jù)接入、度量維度定義、度量指標(biāo)定義、儀表盤編排等能力快速溝通運維度量報表。

運維工作臺構(gòu)建

圖13

ITSM面向的用戶廣泛，不僅有運維工程師，還有終端普通用戶、運維領(lǐng)導(dǎo)等。不同角色關(guān)注的重心不一樣，為了提供更好的體驗，面向用戶的視圖可能是千人千面的，基于視圖引擎，可以定義不同的視圖內(nèi)容、視圖排版、視圖樣式等，以滿足交互和視覺層面的個性化訴求。

總結(jié)

低代碼本質(zhì)上還是一種“開發(fā)語言”，而不是組件的堆砌和拼裝。流程管理領(lǐng)域的低代碼技術(shù)相對成熟，有完善的建模語言作為支撐。因此，低代碼技術(shù)可以在ITSM領(lǐng)域較好的發(fā)揮其價值，以應(yīng)對流程數(shù)量的激增、管理要求的頻繁變化等，更好地助力IT服務(wù)管理的數(shù)字化建設(shè)。