软件即服务(SaaS)应用需要追踪其支持的员工，但是不一定能成功实现。具体到企业而言，移动SaaS应用会因为下面的这些原因改变，可能的原因依次是：规定治理应用改变、移动设备策略改变、员工活动改变以及移动OS特性改变。由于存在如此多的可变因素，要保持移动SaaS应用的敏捷性，没有完美的战略可言，但是选择正确的SaaS提供商，为移动用例定制化SaaS服务或者甚至是构建自己的SaaS都有一定辅助作用。
评估SaaS敏捷性
不管来自哪里的驱动力迫使移动应用用户和其SaaS提供商改变，SaaS提供商都应该能够响应影响应用的监管变化，这也是用户决定进入应用追踪市场的关键指标。问题在于每一个SaaS评估员都需要询问的是，应用如何快速适应监管导致的不变化。这种响应是按月衡量的，必然会导致调节的问题，这也暗示着提供商并不能快速变更应用。同样的惯性可能会影响SaaS提供商对于其他变更需求的响应能力，因此选择不同的提供商会更加明智。
在评估一个提供商时，应该小心审阅提供商针对SaaS的应用程序接口(API)。API非常关键，因为用户由于自带设备(BYOD)策略的变化，在手机上的SaaS就面临着问题，手机OS变化或者工作实践的变化，因为用户通常会直接从SaaS提供商那里购买服务使用。这些应用通常都有其特定的平台，所以更换平台也造成了一些挑战，用户本身不能做出这种改变。最显著的解决方案就是避免通过提供商提供的移动应用来消费SaaS，可以通过其他方式实现，如为企业内部的SaaS服务开发移动SaaS，或者用基于浏览器的服务，替换掉基于应用的SaaS。
通过这些机制支持敏捷移动SaaS应用最重要的技术问题在于SaaS提供商暴露了API。大多数IT专家都知道RESTful API更易于工作，尤其是那些更熟悉Web开发的团队做开发更容易。理想上，SaaS提供商应该提供RESTful API、SOA/SOAP API和应用选择，但是对于最佳的敏捷，RESTful API很关键;其他选择可能并不适用于所有的移动设备。
DIY SaaS应用 确保敏捷性
针对RESTful SaaS API开发内部应用轻而易举就能实现，实际上，大多数多平台开发工具对于移动设备现在都可用，支持这种类型的接口。在大多数案例中，这些平台之一会提供编写你自己的移动应用的最佳选择，从而增加应用敏捷性，但是为了确保新的平台或者平台变化能够快速的被支持，就要知道旧平台和变更的平台如何释放数据，通过工具提供商来调整适应。为了减少风险，可能需要调整BYOD策略，如果你采用构建自己的应用路线，就要限制支持的不同平台的数量;如果不是这样的，可能就需要选择浏览器的方法。这种方法的风险在于你的组织的应用开发就会成为改变的障碍，并不是SaaS提供商。
好的JavaScript和HTML5实践可以在GUI中提供灵活性，在SaaS API中使用改变，就算是变更增加了新功能或者领域都能实现。这项工作实现的关键在于浏览器的选择。并不是所有的浏览器都能够很好的支持脚本和新的HTML特性或者版本，因此如果应用敏捷性很重要，选择最灵活的浏览器就很关键，要支持你的BYOD策略许可的平台范围。查看一下发布历史，关注一下如何增加新的性能，因为过去的版本通常是一个浏览器提供商如何更好响应未来变化的指标。
在大多数案例中，可以在SaaS提供商常规的接口中扩大你自己的云托管应用元素。实际上，你要做的是为SaaS提供商的服务编写一个前端，合并提供商和自己所有的一些功能。这种新的SaaS层可能托管在SaaS提供商自己的服务或者在不同的云上。要注意隔离和检测问题;移动用户并没有实际的使用SaaS服务，因此可能很难通过额外的层追踪问题。
IaaS或PaaS比SaaS更敏捷?
当所有上述的都失败时，需要应用敏捷性的用户可以通过在基础架构即服务(IaaS)或者平台即服务(PaaS)托管应用，从而替换掉SaaS服务。托管的独立软件包其用户看上去就像SaaS，大部分是因为所有云应用在客户看来就像是SaaS。因此，IT人员可以在云端部署任何合适的软件包，为移动员工创建虚拟或者“Self-SaaS”。第三方应用可能还存在敏捷性问题，但是有更多的提供商可以选择，很多提供商会提供自定是GUI。如果开源包可用，你也可以自己来调整。
哪一个敏捷战略最佳：自主研发应用、基于浏览器的应用还是自主研发SaaS?用户认为尽管通过RESTful API实现的基于浏览器的自定制SAAS服务可以支持变更需求，但是也揭示了公司的短板。围绕基于浏览器的构建访问移动应用，自定制的水平令人吃惊，这种方法消除了适应变更的延迟。这种方法可以最先使用，随后再根据情况引入其他类型的自定制。
