MaryK.Pratt

編譯 楊勇

業(yè)務部門經常獨自開發(fā)移動應用程序，只有在出現(xiàn)問題時才轉而求助IT部門。圍繞業(yè)務部門及其移動應用程序需求更好地進行治理可以幫助緩解最糟糕的“痛點”。

當獨立藍十字公司在2012年發(fā)布第一個移動應用程序時，它同時也迎合了當時的技術趨勢，影子IT從此長存下來。

這是因為該應用程序來自公司的市場部門——沒有IT部門的任何參與。

和大多數(shù)影子IT項目一樣，營銷和IT部門來回推諉這一應用程序帶來的問題。

當應用程序首次亮相時，位于費城的非營利健康保險公司的企業(yè)架構總監(jiān)Ken Russo說，患者使用這一應用程序，以移動的方式訪問獨立藍十字公司的會員網(wǎng)站，這實現(xiàn)了營銷的目標，即在移動領域獲得一席之地，但是從一開始就存在問題。

該應用程序是由營銷部門雇用外部機構開發(fā)的，它依靠屏幕抓取技術與網(wǎng)站連接。所以每次公司門戶網(wǎng)站出現(xiàn)變化（實際經常會變化），這一應用程序就沒法用了。營銷部門首先會去找供應商解決問題，然后才找IT部門尋求幫助。

Russo說：“解決方案非常脆弱。它需要供應商不停地進行維護，成本高得難以接受。此外，在一個平臺上解決了的問題在其他平臺上不一定能解決。我們需要更好的方法?！?/p>

有了這種經歷后，公司領導決定采用更好的方法。Russo被授予新的角色和職位——消費者和移動解決方案交付總監(jiān)，負責制定移動應用的技術戰(zhàn)略。他決定采用一種流程，包括使用Kony移動應用程序開發(fā)平臺，使應用程序能夠按照業(yè)務部門的要求盡快完成。

企業(yè)著急在移動領域占有一席之地，導致業(yè)務部門自己開發(fā)和部署應用程序，這意味著IT部門正面臨一個全新的影子IT時代。事實上，研究公司Gartner預測，到2020年，企業(yè)內部使用的70%的移動應用程序是在沒有IT部門參與情況下開發(fā)或采用的。

事實上，這么多移動應用程序的開發(fā)與IT部門無關，對于一個不停地處理關鍵任務而過度勞累的技術部門而言，這似乎是好事。但這種情況還是讓技術部門面臨更頭疼的問題。事實上，外部開發(fā)可能導致大量的問題落在IT部門身上——就像Russo所經歷的那樣。

差勁的移動應用程序帶來的問題不止是浪費IT部門的時間。分析師說，如果沒有正確的配置和集成，這樣的應用程序可能會帶來基礎設施安全風險。同樣，這樣的應用程序無法全面的保護數(shù)據(jù)不被盜取或者丟失，從而使數(shù)據(jù)面臨風險。如果（a）不同部門針對相同的服務簽訂了合同，（b）業(yè)務承辦方在啟動自己的應用程序時沒有考慮維護需求和集成要求，（c）他們開發(fā)和部署質量低劣的應用程序，然后返回來找IT部門解決問題，或者（d）上述所有，這些都會增加企業(yè)的成本，降低了企業(yè)的效率。

Gartner分析師Jason Wong說：“業(yè)務部門想要開發(fā)應用程序，這可能是好事，表明企業(yè)具有前瞻性的思維，使用移動手段進行創(chuàng)新，實現(xiàn)業(yè)務轉型。但是IT部門必須參與?！?/p>

Greenwich Associates是金融行業(yè)的市場情報和咨詢服務提供商，其全球首席信息官兼總經理Isaac Sacolick對此深有感觸。

Sacolick說，雖然聘請供應商開發(fā)移動應用程序很容易，但是，當應用程序開發(fā)遇到復雜的問題時，業(yè)務部門通常不具備正確處理問題的能力。他說，業(yè)務部門可能沒有全面考慮用戶體驗、安全要求、數(shù)據(jù)需求、與企業(yè)后端系統(tǒng)的網(wǎng)絡連接，以及持續(xù)維護等問題。此外，他們可能缺乏評估供應商的技能或者經驗，在開發(fā)項目的合同條款上也可能會措辭不當。

應對差勁的應用程序開發(fā)

然而，Sacolick和其他人不認為首席信息官應該，甚至可以阻止業(yè)務部門從事移動應用程序開發(fā)。相反，IT部門應該支持這方面的工作，這樣才有可能實現(xiàn)更好、更安全的應用程序。

Gartner分析師Katherine Lord說：“首席信息官應接受這一點，因為這可能帶來競爭優(yōu)勢。首席信息官不應該將其視為威脅或者認為業(yè)務部門爭奪職能。讓業(yè)務部門去干沒什么問題?！?/p>

Sacolick說，首席信息官應該考慮部署低代碼移動應用開發(fā)平臺，在后端系統(tǒng)中創(chuàng)建標準API，以便今后的程序員使用，并根據(jù)需要找到外部開發(fā)合作伙伴，與之建立協(xié)議。

Forrester Research將低代碼開發(fā)平臺定義為能夠以最少的手動編碼實現(xiàn)快速應用開發(fā)和交付的平臺。在2014年的一份報告中，F(xiàn)orrester說，這樣的平臺允許IT部門支持業(yè)務部門人員構建可持續(xù)、易于維護的應用程序。

巴黎圣母大學ND移動應用程序項目經理Matt Willmore認為API是一個好方法。Willmore說，在大學里，學生已經使用公開可用的數(shù)據(jù)來為各種任務開發(fā)移動應用程序。他們采取抓取或者解析方法來完成任務，但Willmore說他想創(chuàng)建公開的API來支持學生的移動開發(fā)工作。

需要：明確的標準，良好的管理

無論首席信息官選擇給業(yè)務部門用戶授權去開發(fā)，還是繼續(xù)在IT部門內部進行開發(fā)，分析師認為IT領導應針對移動應用制定明確的標準，并展開最佳實踐的交流。

Gartner的Wong說，在開發(fā)移動應用程序時，應確定使用什么樣的工具、流程和標準，這樣IT部門從技術角度可以確保應用程序能夠可持續(xù)發(fā)展，而且符合企業(yè)的戰(zhàn)略和安全要求。

Wong說：“IT部門應制定一套架構以及一套標準、政策和管理方法，以幫助促進移動應用程序開發(fā)的分散化和民主化，而不要使之成為瓶頸問題?！?/p>

圣母大學的Willmore正在朝這個方向邁進。他說：“我們要做的一件事情是給學生越來越多的資源讓他們去開發(fā)。我們不想限制他們，所以我們組織了黑客馬拉松和周末活動，與學生們交流，并為學生制定了開發(fā)框架?！?/p>

Willmore解釋說：“之前，[一個應用程序]會被放到我們這里，這意味著由我們?yōu)槠涮峁┲С?；現(xiàn)在，我們?yōu)樗麄兘⒖蚣?，讓他們在整個大學層面上進行開發(fā)。當需要支持的時候，那么我們已經將其置于我們的框架中了?！?

Lord說，溝通是使這種計劃成功的關鍵所在。IT領導們必須與整個企業(yè)中的專業(yè)人士建立聯(lián)系，讓高管、經理們和員工知道移動應用開發(fā)政策和過程，以及IT部門可以為他們提供幫助這一事實。她補充說，這意味著要分配適當?shù)膯T工時間來實現(xiàn)這一切。

Lord說：“這需要協(xié)作。不能只是由IT部門控制[開發(fā)]，或者由業(yè)務部門控制?！?/p>

這是獨立藍十字公司的Russo所采取的方法。他統(tǒng)一了公司的移動工作。他部署了Kony的應用程序開發(fā)平臺，在IT部門中引入了敏捷開發(fā)方法，以便更好地響應業(yè)務部門的請求，并創(chuàng)建了一個由IT部門和業(yè)務部門工作人員組成的團隊，執(zhí)行移動發(fā)展戰(zhàn)略。

他說，這些步驟使得公司能夠針對重點關注的問題制定指南，包括用戶體驗和數(shù)據(jù)保護，2012年底公司推出了首款IT部門認可的移動應用程序——旗艦產品IBX。

Russo說，當業(yè)務部門想要實現(xiàn)移動應用時，他們現(xiàn)在來到IT部門，IT部門幫助確定他們是只需要向IBX添加一項功能，還是去開發(fā)新的應用程序，以及什么技術最能滿足他們的需求。

Russo承認，在一定程度上，這是一種老式的管理方法，解決了差勁的移動應用程序帶來的非常現(xiàn)代的“痛點”問題。

他說：“您建立了關系，而企業(yè)建立了對您的信任。經過四年的努力，我們獲得了很好的聲譽，所以當移動領域有需要時，他們知道來找我們?！?/p>

保持數(shù)據(jù)安全

德勤咨詢集團內部服務線德勤數(shù)字的數(shù)字體驗實踐主管Steve Soechtig說，一旦企業(yè)已經制定了一些關于標準化的指南，并在企業(yè)內廣而告之以確保業(yè)務部門了解這些指南，那么IT部門隨后應該建立一個穩(wěn)定的服務層，允許訪問數(shù)據(jù)，提供會話服務。

“如果他們能夠創(chuàng)建所有開發(fā)可以訪問的公共服務層，那么他們可以保留控制。即使他們不直接控制開發(fā)，他們也控制著真正重要的東西：數(shù)據(jù)的安全性和完整性?！?/p>

他解釋說，服務層是一個技術抽象層，它從前端移動或者Web應用程序中屏蔽了所有后端系統(tǒng)。

他說：“理想情況下，移動或者Web應用程序可以調用服務層來檢索數(shù)據(jù)或者發(fā)布事物?！盨oechtig說，強大的服務層還包括標準服務，例如安全、負載平衡和其他基本功能。

Mary K. Pratt是《計算機世界》的特約撰稿人。她在馬薩諸塞州。

原文網(wǎng)址：http：//www.computerworld.com/article/3178745/mobile-apps/how-cios-cope-when-mobile-app-development-goes-rogue.html