還記得早期的Dreamweaver嗎？為了提高網頁的開發效率，Dreamweaver提供了可視化拖拽的能力來生成網頁代碼。可見，低代碼、無代碼的探索和發展其實很早就開始了。
近年來，“低代碼”這個關鍵詞突然又熱了起來，相關創業公司如春筍般涌現。突然爆火的背后其實仍然是企業數字化轉型的驅動，在海量軟件開發需求下，現有軟件生產力已經難以應對，低代碼技術則是一種破局之道。
關于低代碼
什么是低代碼？
通過和專業的代碼開發做對比，低代碼、零代碼本質是提供了一種更抽象的“開發語言”。通過圖1能看到，低代碼、零代碼是建立在一種“建模語言”之上的，相對匯編、高級開發語言，建模語言的抽象程度更高，所以對開發者的門檻更低，只要熟悉圖形的含義，就可以通過可視化的方式拖拽出符合業務邏輯的程序。BPMN是一種比較成熟的流程建模語言，專門用于業務流程領域的業務場景構建。這也是為什么很多低代碼產品能夠在“偏流程管理型”的應用場景中獲得成功的原因，除了市場有需求之外，技術層面有成熟的理論支撐也很重要。
還有一種做法是基于大量基礎場景組件的積累，然后通過搭積木的方式來實現場景構建的低代碼平臺，筆者認為這種方式成功的概率很低。組件再豐富也難以應對千變萬化的業務場景，只有具備用“語言”來描述場景的能力，才能真正做到以不變應萬變。所以，以當前建模語言的成熟度來看，流程管理域的業務場景才更適合發揮低代碼技術的應用價值。
圖1
為什么要低代碼？
企業完成核心業務流程的數字化之后，下一步可能會聚焦到內部運營效率的提升，內部運營管理的效率同樣是組織的一種核心競爭力。而內部運營支撐系統又不及業務系統那么重要，不可能為此花費過多的軟件開發投入，也無法簡單引入一套功能豐富的系統（如：ERP、OA）就可以解決問題，很多邊緣的、零碎的個性化管理場景是難以覆蓋，導致開發需求急劇上升，IT部門如果仍然以傳統的開發方式，不管是自研還是引入外部開發團隊，其生產力都遠遠無法滿足這些頻繁變化的、零散個性化的需求。因此低代碼的價值就凸顯出來了，其很重要的一點是實現全民開發，即人人都是開發者。如果能真正運營起來，其軟件的生產力可以是指數級上升的。
流程建模語言
既然低代碼的核心是建模語言，那么，我們以最常見的流程建模來看看什么是建模語言。此外，ITSM承載的是運維、運營的流程管理體系，其核心也是流程類的業務場景居多。因此，我們可以聚焦到流程領域再深入看看，進一步理解低代碼的底層邏輯，也便于后續理解低代碼在ITSM中的應用。
在流程管理領域中使用最廣泛的建模語言莫過于OMG發布的BPMN/DMN/CMMN等標準，各種主流的開源流程引擎、規則引擎，如：Activiti、JBPM等，都是基于這些標準進行設計的。
圖2
當然，這些引擎也不是百分百實現了前面三個標準，和其發展的重心和年限有關。
1、BPMN
在管理機制的設計中，有一個很重要的點就是“工作流”的設計。通常來說，管理流程越成熟，工作流越固化，即某個工作不再需要太多的創造性了，只要按固定的工作流一步一步去完成，就能得到好的工作結果。BPMN的標準就非常適合此類情況，即用于描述可預定義的、固定順序的工作流。
圖3 固化工作流
BPMN語言中關鍵要素包括活動、網關和事件，通過這些對象符號來描述一個標準的工作流程。（如對更詳細圖形符號感興趣，可查閱官方資料，這里不做更詳細地展開。）
2、CMMN
工作的流程完全固化是一種比較理想的情況，實際管理過程中，成熟度都是從混亂發展到可定義級別的，在還沒找到適合組織的最佳工作實踐的情況下，更多還是靠人的主觀能動性來解決問題。例如：當某個運維事件的發生，通常依賴于成熟的工程師臨時做出判斷，并拆解出幾個關鍵任務來進行處理，分別由誰來執行，順序是如何的。這種不確定的、無法預定義的工作過程就難以用BPMN來建模描述了，而CMMN的標準則更加適合此類場景。
圖4 CMMN場景案例
3、DMN
管理過程中還有一個很重要的活動就是決策，不同的決策結果會影響后續的工作流程。例如：某個變更是否要執行，就需要人為判斷變更的風險程度來決定后續的處理策略。針對此類決策的活動場景，最佳實踐則是通過DMN標準來進行描述。通過下圖對比可以直觀看出在決策場景中用與不用DMN的區別。
圖5
4、最佳實踐
如前面章節所述，在流程建模過程中，不同的標準適用于不同的場景。那具體到一個完整流程的設計，應該如何判斷選擇怎樣的標準組合呢？同樣行業中也提供了最佳實踐的參考原則：
圖6 最佳實踐
- 業務流程中使用了一系列的網關，這個時候可以考慮使用DMN決策引擎代替。
- 業務流程中使用了大量的事件，則可以優先考慮使用CMMN。
- 業務流程中有一系列的加簽、自由流程，則優先考慮使用CMMN。
- CMMN中如果案例內的元素都是有嚴格的執行順序，則優先考慮使用BPMN標準。
低代碼引擎設計
引擎模塊體系
要通過低代碼完整地實現一個管理類應用的閉環構建，通常需要五大引擎能力進行配合。
圖7
引擎功能設計
如下是各引擎模塊的定位、功能設計參考。
圖8
低代碼在ITSM中的應用
運維工單構建
圖9
最能反映運維管理的業務邏輯的是運維工單的設計，細節到一個事件優先級的定義、問題類別的定義等，都能對運維工作產生影響，甚至影響到是否滿足監管合規。因此，即使過了建設期，在運營期間也可能對已定義好的表單進行細微調整，此時ITSM表單的靈活性就非常重要。基于表單引擎可以對運維工單進行可視化建模，包括表單字段的定義、表單字段數據來源的定義、表單字段之間交互規則的定義、表單字段之間數據聯動規則的定義等，以應對表單頻繁變化的場景。常見的應用場景如下：
- 承載事件/問題/變更等流程表單的自定義；
- 承載場景化流程表單的自定義，如：資源申請、權限申請等。
運維工作流構建
圖10
運維工作流反映的是運維工作的協同過程。在運維管理中，不僅僅是人與人的協同，還可能人與系統、系統與系統間的協同。基于工作流引擎可以對運維工作進行端到端協同層面建模，包括工作流中活動的定義、分支的定義、審批的定義、事件的定義等。在ITSM中的應用場景如下：
- 審批場景：多級審批、多人審批、加簽審批等；
- 協作場景：事件處理的一線、二線之間的升級流轉、工單轉派、任務分配等；
- 集成場景：工作流與自動化作業流的端到端打通。
運維管理策略構建
圖11
在實際的運維工作中，還存在大量的管理策略規則，比如：事件處理的分派策略、優先級矩陣、風險評估、審批策略等。這些看似簡單的邏輯，對效率和成本影響可不容忽視，因為通常屬于一種高頻的活動，例如：服務臺人員一天可能需要執行上百次分派的動作。基于規則引擎，通過決策表、決策樹等方式，可以靈活地將規則進行固化，代替人工操作。
運維度量報表構建
圖12
度量是運維管理持續改進的前提，一是度量指標的設計，二是獲取準確的度量數據。同樣，度量報表并不是一成不變的設計，而是隨著管理的成熟度變化而變化，不同階段、不同管理者的要求也會帶來新的變化。例如：流程運行的初期，我們更關注的是流程有沒有推廣起來，因此更聚焦工單數量相關的度量指標。隨著流程逐步運行成熟，我們開始關注工作的成效，如關單率、平均處理時效等。管理要求進一步提升之后，還可能需要度量SLA的達成情況。基于輕量的報表引擎，可以靈活動態響應此類度量要求，通過數據接入、度量維度定義、度量指標定義、儀表盤編排等能力快速溝通運維度量報表。
運維工作臺構建
圖13
ITSM面向的用戶廣泛，不僅有運維工程師，還有終端普通用戶、運維領導等。不同角色關注的重心不一樣，為了提供更好的體驗，面向用戶的視圖可能是千人千面的，基于視圖引擎，可以定義不同的視圖內容、視圖排版、視圖樣式等，以滿足交互和視覺層面的個性化訴求。
總結
低代碼本質上還是一種“開發語言”，而不是組件的堆砌和拼裝。流程管理領域的低代碼技術相對成熟，有完善的建模語言作為支撐。因此，低代碼技術可以在ITSM領域較好的發揮其價值，以應對流程數量的激增、管理要求的頻繁變化等，更好地助力IT服務管理的數字化建設。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
