天天看點

如何為移動應用SaaS ALM選擇正解的方法和工具

了解為什麼在你設計移動、靈活和雲應用時,應該要将saas alm政策列入考量。

如何為移動應用SaaS ALM選擇正解的方法和工具

應用程式設計上的三大趨勢是雲、移動平台和業務靈活性。毫不意外的是,這些趨勢将在應用生命周期管理中合而為一,演化成為一個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政策。在前期多注意才能確定你的方法能夠成功。

本文作者:談翔

來源:51cto