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

[[138160]]

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

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

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

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

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

考慮SaaS ALM廠商

如果你有個(gè)更廣的ALM和移動(dòng)問題要處理，下一步是要問三個(gè)問題：

• 我當(dāng)前的ALM承諾是什么?
• 我主要的中間件是什么?
• 在接下來的幾年內(nèi)我是否會(huì)期待任何重大的開發(fā)改變?

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

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

移動(dòng)SaaS ALM技巧

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

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

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

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

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

處理SaaS ALM成本問題

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

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

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