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

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

關于低代碼

什么是低代碼？

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

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

圖1

為什么要低代碼？

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

流程建模語言

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

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

圖2

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

1、BPMN

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

圖3 固化工作流

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

2、CMMN

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

圖4 CMMN場景案例

3、DMN

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

圖5

4、最佳實踐

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

圖6 最佳實踐

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

低代碼引擎設計

引擎模塊體系

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

圖7

引擎功能設計

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

圖8

低代碼在ITSM中的應用

運維工單構建

圖9

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

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

運維工作流構建

圖10

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

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

運維管理策略構建

圖11

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

運維度量報表構建

圖12

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

運維工作臺構建

圖13

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

總結

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