企業持續擴大使用「平民開發人員(citizen developer)」,以加速實現商業流程的數位化和自動化。不過,低程式碼及無程式碼工具有其陷阱,值得注意,加以避免。
文/Bob Violino‧譯/曾祥信
許多企業開始部署更多低程式碼(low-code)工具和流程,盼能提升軟體開發效率,並協助實現商業數位化。運用這項技術的成功關鍵,在於避免常見錯誤。
研調公司 Gartner 預測,到 2021 年,全球低程式碼開發的市場總值將達到 138 億美元,比 2020 年增長 23%。Gartner 表示,全球疫情期間,遠端開發工作的激增促使更多公司引入低程式碼技術。
Gartner 公司指出,雖然低程式碼軟體開發並非嶄新概念,但是「數位顛覆(digital disruption)、超自動化(hyperautomation)與可組合式業務(composable business)的興起」,這些趨勢的匯集效應,促使低程式碼工具開始湧現,需求與日俱增。Gartner 預測,以低程式碼作為社會和技術領域軟體開發的趨勢,將會持續大幅成長。
[ 2022年度CIO大調查報告下載 ]
這項技術的市場,包括低程式碼應用軟體平台、智能商業流程管理套件(BPMS)、機器人流程自動化(RPA)、以及平民自動化與開發平台。
Gartner 表示,商業數位化進展加速,迫使 IT 領導者必須顯著提升應用程式的交付速度,而低程式碼工具正是解決之道。此外,數位轉型使得客製化軟體程式的需求上升,引燃了 IT 部門以外平民開發人員的崛起,也因此導致低程式碼工具的增加。
然而,低程式碼產品與流程的部署伴隨許多錯誤陷阱,企業組織必須有所意識,才能避免錯誤,或盡可能減少它們對開發營運的衝擊。
錯誤 1:拋棄基本的軟體開發實踐原則
Elastic 資訊安全長 Mandy Andress 說道:「我自己遇過最大的問題,是由於對低程式碼策略的誤解。很多組織採用低程式碼策略,是為了節省金錢或加快開發速度,但是唯有在瞭解低程式碼策略能夠改善什麼成本的前提下,才有可能達到這些目標」。
Andress 表示,低程式碼策略可幫助經驗較少的開發人員建立進階軟體功能,進而降低專案所需的開發人員成本。另一項好處是加快開發速度,尤其是如果不同應用程式可重複使用相同的軟體元件。
[ 加入 CIO Taiwan 官方 LINE 與 Facebook ,與全球CIO同步獲取精華見解 ]
Andress 說:「最常被企業忽略的,是更廣泛的商業和治理流程,這些流程得以確保開發出來的應用程式滿足商業需求。組織應自問:商業需求是什麼?我們必須實現哪些關鍵的業務控制能力,比方職責分離?」。
在前一份工作中,組織的應用程式缺少關鍵業務控制,因此 Andress 被找去協助低程式碼專案。在審視他們的工作後,她發現應用程式缺少重要的業務規則,她說:「因為團隊認為在低程式碼開發過程中,沒有必要遵循他們定義的軟體開發生命週期(software development lifecycle,SDLC),而且也沒有徹底記錄並檢閱商業需求」。
Andress 表示:「重新開發該應用程式所耗費的時間,是原本正常開發時間的三倍,徹底抵消了團隊採取低程式碼開發方法所省下的成本」。
錯誤 2:技能不相符
低程式碼工具的好處之一,是減少完成專案所需的經驗豐富開發人員,但這並不表示團隊完全不需要技能熟練的專家。
LexisNexis Legal & Professional 是一間專門提供法律和消費者資料服務的公司,其副總裁兼自動化長 Vinay Mummigatti 說道:「負責低程式碼開發的團隊,必須非常精通他們使用的低程式碼平台,具備適當的產品認證,有足夠知識判斷該做和不該做的事情」。
Mummigatti 表示:「根據我的經驗,指派擅長撰寫特製化且密集程式碼的軟體工程師去開發低程式碼解決方案是一種錯誤。這類工程師最常撰寫的軟體是包含數千行程式碼的高度客製化應用程式,這類程式的維護和擴展都不容易。這不是低程式碼平台的強項所在」。
例如,LexisNexis 的 J2EE 工程團隊接受交叉培訓,學習在低程式碼自動化平台上實現「合法訂單處理」應用程式,Mummigatti 說道。「開發團隊沒有遵循低程式碼平台供應商建議的最佳實踐作法去使用平台內建的功能,而只是使用平台作為後端引擎,安排工作流程,然後針對所有軟體功能撰寫複雜的程式碼」,他如此說道。
Mummigatti 表示,這些客製化程式碼導致專案的時間和金錢成本增加為原本估計的三倍,更糟的是,帶來嚴重的效能與維護性問題,最終迫使他們必須仰賴供應商的專業服務團隊,徹底重寫整套應用程式。
錯誤 3:缺乏業務主導的軟體交付
Mummigatti 表示,低程式碼平台的存在,最主要是讓業務社群的平民開發人員也能快速地開發並交付應用程式。將業務用戶摒除在決策過程之外,絕非好主意。
Mummigatti 說:「我們看到的一項致命錯誤是沒有讓業務用戶在專案初期就參與其中。使用低程式碼和模型驅動的開發平台時,從一開始就讓業務用戶參與是成功的關鍵。否則,將會導致重大的重新開發,以及預算和時程的落差」。
低程式碼專案需要業務和 IT 團隊的緊密合作。Mummigatti 舉的例子是一套幫助客戶熟悉產品的平台,他們在幾乎沒有業務部門參與下完成設計和開發工作。當這套平台發佈時,業務用戶拒絕使用其流程邏輯、決策規則、報表功能和使用者界面,因為它們會帶來錯綜複雜的營運改變管理。
Mummigatti 說:「正確的作法是,讓業務用戶從第一個 sprint 開發週期就開始參與,低程式碼平台提供視覺化功能,讓業務用戶能清楚看到流程模型的設計方式、業務邏輯的定義方式、如何創造使用者界面和表單、以及資料元素在每個步驟之中如何轉換。這種作法可以創造出「完全符合企業想像」的應用程式」。
錯誤 4:未能改變公司文化和結構
研究公司 Info-Tech Research Group 資深研究分析師 Andrew Kum-Seun 表示:「在執行正確的前提下,低程式碼和無程式碼技術,是由傳統開發模式轉換到業務管理應用軟體與平民開發模式的絕佳工具」。
Kum-Seun 說:「許多組織忽略一件事,那就是要促使這種新環境的形成,需要公司文化、軟體和風險所有權結構、以及 IT 營運模型的重大轉變。不幸的是,傳統軟體開發實踐方法、各自運作的業務和 IT 團隊、和低落的企業系統品質,侷限了低程式碼和無程式碼技術的真正潛力,且增加軟體實作與長期維護的成本」。
Kum-Seun 說:「IT 團隊必須由營運者及解決方案實現者的角色,轉換為值得信賴的合作夥伴、指導者及平台支援者等角色。業務團隊必須對他們的軟體實作與開發決策負責,並讓其他團隊清楚知道他們對企業環境做出的改變。畢竟,唯有在我們願意改進合作方式,以善用低程式碼和無程式碼技術的功能時,這些技術的真正價值才會展現出來」。
錯誤 5:設定太有野心的計劃,工具無法支援
低程式碼平台是加強軟體開發的寶貴工具,但它們並不完美。
Mummigatti 說:「使用低程式碼平台的另一項致命錯誤,是沒有考慮到其技術限制。在某些專案裡,LexisNexis Legal & Professional 試圖擴展其低程式碼平台,去處理龐大資料量且交易密集的應用程式,這類應用程式還必須擁有故障復原功能或是能批次處理大量資料」。
Mummigatti 表示:「我們發現,在涉及到整合型資料,或是跨越多個系統或複雜資料結構的服務安排時,低程式碼平台難以勝任工作,也無法擴展規模」。該公司試圖用低程式碼平台實現抵押處理與反洗錢應用程式,這些程式必須批次處理來自交易處理應用程式的文件和資料,而且資料量極為龐大。
他們發現,在這兩種應用程式情境下,低程式碼平台無法提供他們所需的速度和品質。應用程式甚至會在流程處理過程中故障。Mummigatti 說:「在低程式碼平台中,我們無法確保應用程式能以批次模式處理大量資料。這是重大的營運和監管挑戰,對客戶體驗影響甚鉅」。
錯誤 6:部署太多工具
任何好的事物也要適量,太多不見得是好事。這道理適用於低程式碼和無程式碼工具,特別是當這些技術無法妥善協同運作時。
軟體公司 Nutanix 面臨了這種問題,資訊長 Wendy Pfeiffer 形容他們的處境好比「巴別塔(Tower of Babel)」。她說:「當你用不同語言實現太多工具時,你的團隊將永遠無法達到絕佳的自動化水準」。
Pfeiffer 表示:「就我的團隊而言,在我們訓練每個團隊成員使用同一套工具之後,我們的自動化營運才真正有了進展。三年前,我們只有約 15% 的服務能夠自主執行。如今,這個數字已接近 85%,改進的過程中,許多起始步驟都是由從未寫過自動化程式碼、但過去是 IT 營運專家的團隊成員所建立的」。
Kum-Seun 說,此外,實現低程式碼技術可能不像供應商宣傳的那麼簡單。他說:「低程式碼技術真正的好處在於,它能夠利用及整合企業應用程式、資料倉儲和系統裡的各種服務和資料。然而,許多組織受限於舊有系統架構,缺乏共用的資料定義,加上應用程式背負著技術債(technical debt)」。
Kum-Seun 說:「應用程式編程介面閘道器(API gateway)、資料湖泊、雲端平台與其他整合工具,可以幫助改善企業系統與低程式碼技術的相容性。但是,這些工具無法解決基本的架構與資料管理難題」。
錯誤 7:維持糟糕的流程
Pfeiffer 表示,低程式碼工具潛力無窮。她說:「透過一點訓練,IT 團隊每個成員都有能力將特定工作流程裡的關鍵環節予以自動化,進而提高工作準確度和效率。但是自動化不是萬靈丹,一個糟糕的流程,即使透過機器快速準確地執行,依然是糟糕的流程」。
Pfeiffer 說:「沒有什麼特殊的「機器魔法」可將糟糕的手動流程轉變成絕妙流程。首要步驟,我的團隊必須用淺顯易懂的語言寫出想要轉為自動化的流程。看到待完成工作的具體描述,可突顯出問題,帶領我們改進工作流程」。
一旦文件準備好,團隊就可透過低程式碼工具將對應的流程轉化為程式碼。
Pfeiffer 建議,自動化最好是漸進地實施。她說:「IT 團隊往往認為,他們必須把一個複雜流程從頭到尾徹底地自動化,自動化才能發揮效用。我和我的團隊從經驗中學到,將精力專注在流程中最容易出錯的步驟上(同時也是最需要重做的步驟),是體驗這些工具好處的真正關鍵」。
(本文授權非營利轉載,請註明出處:CIO Taiwan)