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

[[138160]]

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

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

SaaS ALM的兼容關鍵性

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

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

考慮SaaS ALM廠商

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

• 我當前的ALM承諾是什么?
• 我主要的中間件是什么?
• 在接下來的幾年內我是否會期待任何重大的開發改變?

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

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

移動SaaS ALM技巧

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

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

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

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

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

處理SaaS ALM成本問題

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

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

原文鏈接;http://www.searchcloudcomputing.com.cn/showcontent_89552.htm