三. 选择适合的成熟度等级

    综上所述，符合最高的第四级的成熟度模型的SaaS系统似乎永远是SaaS系统设计的终极目标，但实践证明这并非永远正确。一般来说，将SaaS系统的成熟度看成一个两头具同等重要性的杠杆也许更为恰当，杠杆的一头是独立（Isolated）的数据和代码，而另一头则是共享（Shared）的数据和代码。

    选择何种程度的成熟度模型取决于SaaS服务供应商所支持的商业模式、系统模型和运营需求，以及其它基于客户业务需求的一些考虑，而且以上各种因素之间往往还会有微妙的联系： 

    商业模式----独立的数据模式是否符合财务考量。为了获得经济和管理上的好处而采取数据共享往往意味着SaaS服务供应商可以因此节约相当一部分的管理成本。但在有些情况下，客户可能会对此有不同的需求，比如说，尽管SaaS服务供应商可以保证客户的机密数据即使与其它客户的数据存放在一个数据库内但绝对不会外泄，客户仍然可能受强有力的法律或文化上的限制，从而抵制或干脆拒绝使用任何基于多个客户使用共享服务来访问同一个应用结构的SaaS软件服务。当然从商业模式的角度来看更重要的是，一旦计划运营基于这一商业模式的SaaS系统，SaaS服务供应商必须证明该应用如何能在当前采用的成熟度模型基础上保证业务顺利发展且实现盈利。 

    系统模型----应用是否能在单一逻辑实例下运行，是否能将以前基于桌面或传统的服务器-客户端的应用改造成为基于互联网的SaaS系统，这些需求往往从根本上就与要求单一实例和元数据为主的SaaS模式开发不相适应。因此基于财务考量，投入相当的人力物力来将当前系统转换到一个完全符合SaaS成熟度模型的系统往往是一个得不偿失的选择。而当你选择一切重新开始，设计和建造一个基于网络的SaaS应用时，往往会感到拥有更多的自由的开发空间。 

    运营模式----SaaS服务提供商如何保证客户服务条款（SLA：Service Level Agreement）得到执行，如何慎重的评估包含在已经与客户签署的SLA中的诸如系统当机时间、服务选项以及灾难恢复等条款，以及如何在当前这样一个多个独立客户共享访问单一实例的SaaS架构下实现这些服务条款永远SaaS系统运营维护中的一大挑战。