了解為什么在你設(shè)計移動、敏捷和云應(yīng)用時，應(yīng)該要將SaaS ALM策略列入考量。

應(yīng)用程序設(shè)計上的三大趨勢是云、移動平臺和業(yè)務(wù)敏捷性。毫不意外的是，這些趨勢將在應(yīng)用生命周期管理中合而為一，演化成為一個ALM的云/SaaS模型。每個開發(fā)者和架構(gòu)師都應(yīng)該考慮基于SaaS的ALM，但要做出正確的選擇需要有系統(tǒng)性的方法。有必要先搞清楚你是否是SaaS ALM的候選者。如果是的話，則要先評估你現(xiàn)有的應(yīng)用中間件和ALM策略，然后權(quán)衡你所有的應(yīng)用驅(qū)動的重要性，最后依照你的需求選擇正確的方法和工具。

SaaS是一種ALM的交付模型，而不是功能分類。大部分用戶都應(yīng)該在早期就確定他們是否適合基于SaaS的ALM，然后才開始選擇ALM的工具。在 SaaS交付的ALM工具中要問的主要問題是，應(yīng)用的變更速度和管理的應(yīng)用數(shù)目有多少?如果你是個有大量應(yīng)用變更的大型機構(gòu)，你可能要考慮使用傳統(tǒng)的托管 ALM方式。但是，基于SaaS的ALM也有助于遷移到一個新的ALM策略，所以值得考慮以下提到的問題來了解SaaS ALM是否可以幫你采用最佳的移動或敏捷應(yīng)用的ALM策略。你以后可以隨時轉(zhuǎn)成內(nèi)部選項。

SaaS ALM的兼容關(guān)鍵性

兼容性是ALM問題中的第一個關(guān)鍵要素。以移動應(yīng)用來說，要全面的了解整個應(yīng)用而不是只關(guān)注你覺得是“移動”的部分是很重要的。大部分移動應(yīng)用都是基于一個前端/后端的模型，應(yīng)用的邏輯和數(shù)據(jù)訪問都放在后端的部分，而前端則提供GUI。而所有這些都由一個中間件模型支持，例如Java或.NET。對于移動應(yīng)用來說，你也可能有個后端即服務(wù)工具或另外一個旨在支持多個移動平臺和BYOD的移動應(yīng)用開發(fā)工具。你應(yīng)該要確定你的ALM策略支持你的應(yīng)用中間件承諾，以及你支持你現(xiàn)有的ALM工具，除非移動性提供了一個令人信服的理由讓你不得不重新考慮。

如果應(yīng)用改變的來源絕大多數(shù)是功能性的，一個后端元素的業(yè)務(wù)流程，或移動設(shè)備導(dǎo)致前端的改變，你可能要考慮將前端和后端元素切割成分別的ALM“應(yīng)用”。由于變化的速度能幫助決定一個SaaS模型是否有效，這可能會打開一個或兩個通向SaaS ALM的應(yīng)用領(lǐng)域。

考慮SaaS ALM廠商

如果你有個更廣的ALM和移動問題要處理，下一步是要問三個問題：

我當(dāng)前的ALM承諾是什么?

我主要的中間件是什么?

在接下來的幾年內(nèi)我是否會期待任何重大的開發(fā)改變?

如果你的主中間件供應(yīng)商正提供你現(xiàn)在的ALM，而你預(yù)計自己沒有近期的改變的話，你也許應(yīng)該維持現(xiàn)狀。

ALM和中間件供應(yīng)商之間的不匹配并不少見，但根據(jù)用戶的反饋，支持變得越來越困難。大部分公司最好的選擇是將ALM融合到能滿足他們中間件承諾的單一平臺上。尋找一個與你的中間件兼容的敏捷ALM框架。

移動SaaS ALM技巧

移動ALM的最大挑戰(zhàn)，多半來自于整體上需要上更多適應(yīng)性和動態(tài)性的業(yè)務(wù)過程變化和移動性之間的交集。敏捷性是這兩種驅(qū)動力都必須要考慮的一個因素，而創(chuàng)造出一種“ALM筒倉”的風(fēng)險也很大。但是，即便未來的應(yīng)用都可能保持著前端/后端的取向，因為將應(yīng)用邏輯與表現(xiàn)層的改變隔離開來真的會很有幫助。如果你將這個模型作為目標(biāo)的話，必然有足夠的信心可以管理從標(biāo)準(zhǔn)應(yīng)用中分離出來的移動ALM。

即使這樣，你是否應(yīng)該試著選擇一個移動專用的ALM SaaS工具還尚不明朗。業(yè)界的趨勢似乎是很明顯的向反方向前進;使得移動的動態(tài)性成為敏捷ALM中需要解決的一個問題。最佳的途徑似乎是選擇一個有著SaaS交付選項的敏捷ALM工具，然后根據(jù)你的需求做出調(diào)整。

選擇什么工具呢?大部分用戶的第一選擇應(yīng)該是他們主要中間件供應(yīng)商所提供的ALM工具，如果那些供應(yīng)商已經(jīng)有相當(dāng)和諧的中間件部署到位的話。 HP，IBM，微軟和Oracle的敏捷ALM工具被認(rèn)為是非常有效的，并獲得了用戶和評論人士的高度評價。在前述的幾家中，HP和Oracle最常被人提及擁有最廣泛的中間件技術(shù)支持，而其中HP又有最積極的SaaS交付支持。

在移動應(yīng)用上進行干凈的前/后端應(yīng)用分離的價值已經(jīng)說過了。由于前端ALM的問題多半是技術(shù)上的，而后端問題通常與業(yè)務(wù)活動有關(guān)，分離可以減少整體的 ALM工作和范圍，甚至可以讓你在有需要的時候使用單獨的工具。關(guān)鍵是確保你的前端工具與后端程序的公用接口是一致的，這樣兩個ALM的領(lǐng)域才能以堅實的規(guī)范連接起來。不然的話，會產(chǎn)生相互依賴關(guān)系無法正確測試的風(fēng)險，而這會導(dǎo)致你的ALM流程無效。

移動ALM的另一個建議是，對于推送通知和互動性支持的方式要特別小心。面向Web的前端通常是創(chuàng)建成期望用戶發(fā)起的交互而不是通知。我們很容易會在測試中不小心忽略這個，然后忘了驗證應(yīng)用發(fā)送未經(jīng)請求的消息的能力。

處理SaaS ALM成本問題

基于SaaS模型的ALM的一大問題是成本。了解SaaS定價模型會如何影響整體ALM成本是很重要的，以及注意在什么地方SaaS許可會特別引發(fā)成本的大量增加。你的測試數(shù)據(jù)會儲存在那里?ALM測試階段將會如何影響定價?你必須做好轉(zhuǎn)回自主托管模型的準(zhǔn)備，如果你發(fā)現(xiàn)你的應(yīng)用改變在未來很可能會讓你暴露在過度成本風(fēng)險之下。

不要過度思考這些。ALM，首先來說，應(yīng)該要是個整合的過程，由整體業(yè)務(wù)目標(biāo)在背后驅(qū)動。將ALM細(xì)分到多個工具和自主托管和SaaS交付模型之間是OK的，但最終的結(jié)果必須是一個在可接受成本下的響應(yīng)式ALM策略。在前期多注意才能確保你的方法能夠成功。