构建插件式的应用程序框架(七)－－－－基本服务

听所SaaS(Software as a Service)的概念很久了，一直没有很好的关注过。10月的程序员杂志几乎是以SaaS为专题的，趁国庆长假仔细翻了翻，些许感想记下来。

SaaS的本质

我认为SaaS的现状从本质上并没有超出其前任概念ASP(Application Service Provider)的地方，MS文档《抓住长尾市场的架构战略》中提出的四级SaaS成熟度模型把第一级称为ASP过于牵强，仿佛ASP概念时代的供应商和从业者从来没有考虑过或提供可配置性的、可扩展性的、多用户的、负载均衡的系统似的。所以我觉得目前二者并无本质区别，属于同一概念，换了个说法而已。其本质都是“软件部署为托管服务，通过因特网存取”。

ASP之死

ASP概念兴起有10年了，感兴趣的人并不少，一直没有成功的原因究竟是什么？目前主流观点无外乎亮点：一是客户对托管服务的信任度，二是软件的功能性。

我觉得对托管服务的信任度是大问题，但也不是主要问题。对供应商的不信任包含几个方面：对不知名的小供应商的长久存在性怀疑、对供应商对企业商业机密数据保护的怀疑、对系统可靠性的怀疑。其实这些怀疑多是针对不知名的小供应商的，知名的大企业在这方面应该是能够让客户放心的。

而软件的功能性可能是最大的原因。这其中包含几个方面：一是软件供应商提供的系统是不是市场最需要的系统；二是对于市场需要的系统，供应商提供的软件功能是否满足不同企业的需求；三是针对软件系统的服务是否到位。这三方面具体展开都是大问题，后面将专门讨论这几点。

SaaS适合做什么

这也就是市场需要什么的SaaS系统的问题。什么样的客户需要具备Saas特征的软件系统？SaaS的特征是托管服务、因特网模式、统一版本无定制化开发、按用户数或月租方式收费。

统一版本无定制化开发这一点就决定了SaaS系统应是针对相对通用型的简单业务或标准化的复杂业务或工具型软件。例如最成功的电子邮件系统就是典型的工具型软件，salesforce.com做的CRM（其实只是销售自动化SMA部分）属于通用型简单业务。标准化的复杂业务如财务管理，从业务角度是适合SaaS的，但是财务数据的特殊性决定了在现阶段绝大多数企业尚不能接收托管管理的方式。

SaaS还应是网络化的协作型的应用，以区别于非网络化的单机版软件。因为运营SaaS型应用相对单机版软件并无优势，供应商付出的成本不会更少，客户也不能从中获取额外的功能性。而网络化的、协作型应用决定了单机模式是不可行的，客户必须付出额外的硬件成本和管理成本才能消费得起网络版应用，这才是SaaS的优势所在。所以，类似于Google的在线字处理和电子表格这样的SaaS我是不看好的，因为一旦在收费服务后实在看不出它相对MS Office的优势所在。

如何保证SaaS应用相比传统应用的成本优势呢？对于客户，它的价格必须保证在功能性损失极小的前提下有较大的成本节约；对于供应商，该应用的目标市场必须要有足够多的潜在客户以保证供应商能给出最低的有诱惑力的报价。

综上，满足条件的SaaS特征是：中小型企业或大企业的小型应用需求；通用型的简单业务或标准化的复杂业务或工具型软件；网络化的协作型软件；免费或价格相对低廉。

SaaS如何适应不同企业个性化功能

 在确定要为什么样的客户提供什么类型的软件之后，我们需要考虑如何满足不同客户的个性化需求。前面一节已经界定了软件类型为通用型的简单业务或标准化的复杂业务或工具型软件，这一前提需保证软件系统本身不存在根本性的个性化功能，个性化只是表单字段的增减、报表列的增减、页面布局的调整等表象上的东西，而不是新需求的定制开发。

关于多用户结构下可定制性表单的数据库设计，这在MS文档《多用户数据体系结构》中有些参考，基本上现有表单可定制的应用系统都是这么做的。

SaaS如何提供及时到位的服务

这是一个较容易忽视的问题。企业应用说到底还是人在用，是为实现企业管理目的而存在的，这和类似于电子邮件这样的个人应用有较大的区别。服务也不仅是培训这么简单，为实现管理目的还可能包括管理制度的制定、与管理流程的配置和优化、最佳管理实践的指导等事务。这些事务往往不是企业独立可以完成的，尤其是小企业。所以，类似salesforce一样挂一个大而全的帮助文件不是放之四海而皆准的服务方式，SaaS服务离不开人的参与。

SaaS的前景

目前，SaaS的宏观环境相对ASP出生时要好多了，各大厂商如Amazon、Google、MS、阿里巴巴等都具备了足够的品牌和平台资源，这为第三方托管扫清了障碍，使ISV、托管方的职责和分工更加明确，便于充分发挥自身优势。

技术上，Web方式是主流，但不一定是唯一的模式，对客户来讲，安装一个能自动升级的客户端也并不是完全不能接受的，否则网络游戏是怎么活下去的呢？因此，ISV应更多的考虑软件的功能性，而不要受制于Web方式的局限。

此外，我认为现有的HTTP、HTML和浏览器标准是阻碍互联网应用发展的最大毒瘤。在软硬件技术日新月异的今天，这些标准多年来无甚提升，一堆大小公司在鄙陋的浏览器标准下用HTML、脚本、CSS模拟各种树、菜单、对话框、拖拽等UI特性，不仅重复的制造着轮子还美其名曰Ajax并为此沾沾自喜，真是可笑。其实，大佬们为什么不坐下来谈谈浏览器的标准问题呢？这么多年过去了，浏览器已经从最初的网页链接，扩展为互联网应用、企业应用的统一客户端平台，其作用已经发生了根本性变化。固守HTML、CSS、JS的解析执行在若干年以后看来是荒唐的，标准本来就是人制定的，需要的时候就应当扩充。比如菜单、树、拖拽、suggest特性这些完全可以像表格Table、输入框Input一样成为标准的浏览器控件或特性，要求所有的浏览器都去实现它，能省却多少麻烦，扭转多少关注度啊。