了解为什么在你设计移动、敏捷和云应用时，应该要将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