破解SAAS

许多人在研究SAAS，尤其是做传统管理软件的。看着阿里软件，看着Google Office，看着Salesforce，眼馋了。

但是，我经常问他们一个问题，你们研究SAAS的什么？很多人却讲不明白，看个热闹，大呼别人过瘾，自己却没有自己动手的开始。

许多人对SAAS有误区。说SAAS就是给中小企业用的，说SAAS就是CRM，还有的说SAAS只能做些边缘应用，如OA什么的。有的说SAAS在EAI方面不行，有的说SAAS在定制方面不行。这些都是看现状看表面得出的结果。

SaaS是Software-as-a-service（软件即服务）的简称。软件即服务。这才是SAAS。我要接下来的讨论就是在这个大背景下讨论的。如果你不认同软件即服务这个讨论的大背景，请离场，该文章对于你会浪费你的时间。

软件即服务，不仅仅简单的把软件放到网上，采用租赁的收费模式这么简单。如果是这样，现在的网站，现在的B/S软件，过去的ASP模式就是SAAS。

先让我们回顾一下ASP的历史，这个貌似SAAS的家伙。

我们传统做管理软件，先调研，再设计，再开发，再测试，然后市场宣传，然后销售打单，销售方案编写、销售投标陈述、销售演示，然后实施安装、培训、推动上线，需求定制，最后是技术支持服务。如果远程搞不定，还需要及时赶到现场。为了让客户续服务费，如果他们不交服务费，我们就不给他们提供技术支持。如果这个软件不太多的需要后续服务，我们就在用户数、并发量、数据量、时间期限上给客户加限制，逼迫他们给我们续费。如果他们来个反破解，我们就继续道高一尺魔高一丈。

于是，发明了ASP（Application Service Provider ）。应用托管提供商。客户你不用投入硬件（现在硬件换代这么快，你买上两年就旧了，不值得），不用维护（你想一个最起码的系统维护人员，每月1000元的工资，1年还1万2呢），而且我们有强大的安全防护（你自己不专业，很有漏洞，我们有安全专家），我们还有海量数据硬盘和高速的带宽。

客户想：这是好事啊。一尝试，发现不对，我的数据需要放到你的服务器上，你把我的客户档案卖了怎么办？你手下的员工不老实把我企业的信息透露给我的竞争对手怎么办？我知道你老板肯定诚信没问题，但谁能保证你的基层员工没问题呢？我又不能惩罚你的员工。如果是我自己的员工把我自己服务器上的资料泄密了，我自己的人我有的是招治他。

于是，ASP炒作了一段时间黯然下去。那已经是99-2000年的事情了。那时候互联网上网的企业也少，在网上找客户的企业也少，在网上做广告的企业也少。电子商务、支付宝、IM软件，都还起步。网速也慢，开发工具也简单，没有像如今的AJAX这么自然的UI感受。

听说过ASP这段历史的读者，是最容易产生SAAS和ASP之间到底存在哪些差异的疑问。认为SAAS就是换汤不换药，起了个新名词继续忽悠人，就如同Web2.0，AJAX之类，都是新名词旧技术，把杂七杂八纠集一起，揉揉然后给你包装一个新概念继续卖钱。甚至国内有些厂商为了争SAAS这个头名状，说我们99年就SAAS了。

但是SAAS真的是换汤不换药的ASP么？

让我们好好看看这两个词：

SAAS 软件即服务。

ASP 应用托管提供。

一个强调的是服务，一个强调的是托管。

我在前面大量的博文在讲Open API、WebService、Json、Javascript API、Open ID，讲组件容器、SCA/SDO、SOA、中间件、虚拟机、云存储、分布式文件系统、分布式关系数据存储、分布式关系数据查询、LINQ、GQL、Flash 3DUI。其实我都一直围绕着软件即服务在研究和探索。

我一路从企业管理软件走来，经历了函数、对象、组件，如今面临着面向服务。我从研究Corba，到Com+、EJB，到如今的SCA/SDO。我也经历了企业EAI、消息中间件、异构应用集成、数据大集中。我也经历了海量数据、企业级存储、企业级灾难恢复、企业级不间断运行。我也组建了咨询、市场、销售、教育、支持、开发、测试、文案、售前这样的组织模式。我也经历了从报表设计器到UI设计器到工作流设计器都自行开发。我也经历了传统管理软件盈利瓶颈困惑、收费困难、盗版问题、和互联网网站公司日进斗金3年上市市值超过联想的困惑。

我一直在思考，什么样的盈利模式能够持续的收费，大规模的销售。而非现在的收费模式和销售模式。

我也一直在思考，如果真的实现大规模的销售，那么必然用户数据海量，而且并发访问剧烈，这个产品的技术架构应该是如何的？

我不断跟踪着业务动态，希望能得到借鉴。但是我看过800CRM、看过xtools，我没有感觉到革命。

首先给我冲击的阿里的支付宝，开放了WebService，允许外站来调用。然后是Google开放了API，让大家在自己的网站或软件中利用Google的软件接口得到自己想要的功能。然后就是MapABC开放了API，让大家在自己的应用中搜索地图和产生标记。然后Amazon也开发了S3服务，让大家用于关系数据的存储和查询。然后就是业界开放之潮不断，SOHU博客也开放了（博客是个人门户不能小觑），豆瓣也开放软件服务了，允许大家查阅书籍资料。

它们是Open的，它们是SOA的，它们是API的，它们可以嵌入到任何你的应用中，它们是可以服务全球的，你根本无法想象这些软件服务到底最终会有多少人调用，会有多少用户在并发访问。

我深深的感觉到，这就是我想要的SAAS。它从收费模式、开发方法、技术架构方法、实现方法、基础设施、软件生态链、快速交付满足客户需求各个方面都对过去传统管理软件和ASP实行了颠覆。

想想，你提供了一个提醒软件服务，我提供了一个费用报销服务，他提供了一个工作流服务，另外的人提供了报表服务。想想，把这些都整合在一起，会怎样呢？

这就是趋势。

看看我们现在的模式：能做的都做了，从CRM、OA，到进销存、财务、费用报销、考勤请假工资计算。我们无其不能，无其不做。我们N个开发组在加班、N拨项目组在全国出差实施培训、N个小姑娘在客服接电话。我们是一个麻雀虽小五脏俱全的“巨无霸”。

这种模式从盈利模式到开发组织到技术架构，都是不符合未来趋势的，我们负重前进，我们势必无法像互联网企业一样快速成长。

全球的SAAS市场我并不想在这里大鸣大放。我也仅仅工作在企业管理软件行当，我要思考的也仅仅是在这个全球都SAAS潮流的大背景下，我们传统管理软件厂商应该如何拥抱未来，跟随时代大潮而腾飞（许多人无法成功，就是没有踏准时代的脉搏，而不是运气不好这么简单。想想80年代的万元户和特区下海，90年代的关系经济，2000年后的知识经济）。

所以我对SAAS在管理软件行当的研究分为这几个方面：
1 SAAS的在管理软件应用的切入点、目标客户群、盈利模式、市场容量、发展周期、收费模式、周期每阶段预期收入、竞争环境。

2 SAAS的运行技术基础。SAAS不仅仅只是片面理解的一套可以存储多个客户单位数据的B/S软件。如果你要应对上亿次的访问，几亿用户的并发和数据存储，你的运行基础设施一定是一个可信平台。在稍后我会给大家讲讲我理解的可信平台。

3SAAS的业务架构平台。我们既要提供一套可以不用代码就能简单定制的业务平台，也要提供WebService API接口，以使代码能够切入进行复杂定制。而且能够部署、运行，而且是安全的沙箱，而不能部署的是恶意代码。而且每个定制是隔离的，不能互相影响的。

4SAAS的开发模式。SAAS的开发，上一条我们就已经说到了，需要打造一个开发链。我们维护业务平台，维护合作伙伴，而应用定制，却必须由合作伙伴来完成。所以，如何设计、如何开发、如何测试、如何部署、如何版本管理、如何培训教育、如何支持服务大家必须统一。而且团队配合，需要有group、wiki、blog、mail、IM、office online来协作，并且必要的时候还需要配合代码搜索。这也就是为什么google大力发展Gmail、Gtalk、Project Hosting、code search、office online、blog、group forum、SVN。其实Google要搭建的就是SAAS平台和SAAS生态链。你看Google不仅给我们提供了分布式全球存储基础设施（商业称“云存储、云计算”）、各种应用，而且提供了应用API，而且最近还提供了App Engine，而且还提供了代码社区。

管理软件的SAAS的应用切入点非常重要。你是面对ISV来盈利呢，还是面对最终客户呢？你是想通过软件收费（按流量、按带宽、按存储量、按用户数、按时间年限、按模块数来收费。还有收培训费、支持服务费）呢，还是通过广告来收费呢？还是想挂羊头卖狗肉，利用人气来做其它销售和市场活动呢？（看看Google。Google既提供了应用，也提供了应用接口。既能让最终用户直接使用，也能让ISV调用开发嵌入到ISV自己的应用中。应用既向最终用户收使用费，也向ISV收接口使用费，还要在应用中挂广告收广告费）。如果大家联想到阿里软件有多少软件功能被嵌入阿里巴巴网站和淘宝网站的服务，估计大家按照这个思路下去会想出更多的办法。

应用想好了，就该想在什么基础设施上实现他。我刚才就讲到：你无法估量你的应用会被多少网站调用，会被多少用户使用。你做的应用再也不是给那一个个的客户使用了（你想想过去你做的管理软件，充其量就是一个大型集团上万人访问，但是在互联网上，几亿人的访问都有可能），你需要为你的应用好好设计一下可以供互联网调用的应用平台。

讲到云计算模式的SAAS平台，我们需要提一下可信平台。一说可信，大家首先想到的是数据安全和应用使用安全。但可信平台不仅仅只是安全单方面，它应该包括以下几方面：
1 7x24x365不间断，不会因为节点失效而间断
2 安全访问
3 永久存储。首先是存储不失效数据不丢失，第二是存储服务不失效。
4 允许异构硬件、异构操作系统的接入
5 随地访问，没有世界地区差异造成的访问限制或速度限制或功能限制或存储限制

我的企业业务要随时随地能处理，你不能因为你的服务器有问题了，你的电信机房有问题了，你的南北电信隔离有问题，而使我使用受限制。
而且我的数据是安全的，不能告诉我你的服务器硬盘有问题某段数据丢了。
我的操作也是安全的。互联网上有许多黑客和黑客软件，我可不想让黑客知道了我的登陆密码。现在，网上银行很多人都被窃取了银行账号丢了钱。

许多人认为Google最强大的是Google的搜索和Google的关联广告，还羡慕Goolge有钱能建电厂能发卫星能购买无线频段，能有大资金并购Youtube。其实，Google最大的核心就是多年运营搭建了这个可信计算环境。这是目前唯一的一个互联网上的可信海量计算环境。没有稳定的基础，我们怎敢还相信上层的应用呢？谁还敢把数据存放在上面呢？

而我们的国内SAAS厂商，还在用传统的做中大型管理软件的做法在做计算环境，集群、不间断电源、企业存储设备、企业备份设备。这些传统做法支撑一家大型企业应用运行没有问题，但是要服务全球，服务全球企业，这个计算环境显然是无法快速的、低成本的扩展的。最后很可能形成一个瓶颈，不是上小型机，就是把企业分配到不同的服务器集群上。就跟现在做网络游戏一样。我们无法轻松的堆砌上万台PC甚至几十万台服务器来扩展计算环境。当然，如果你想做的SAAS，只想服务国内，甚至国内小企业，甚至是国内某行业的小企业，那就另当别论。不同目标，当然技术架构层面会发生质变，而不是裁减的量变。

有了可信的平台，才能放心的构建基于之上的业务架构平台。传统的业务架构平台，我上一篇文章也已经讲过。但是在SAAS环境下，业务架构平台是不一样的。SAAS的业务架构平台必须能做到以下两点:
1数据隔离
2业务隔离

为了完成这两方面的隔离。最好的处理方法是物理隔离，给每个企业都建立一套运行环境和数据库。这是最安全的隔离。但是这种方法有一个突出问题，就是统一的BUG补丁或功能耐升级，怎么给全部企业升级，并且升级了还不影响定制业务。我也在思考和学习Google的Project Hosting的方法。这也就是为什么虚拟软件平台如VMWare之类这么流行的原因。

SAAS管理软件平台还需要良好的定制性。现在的传统业务基础平台，用一个词：密不透风来形容最形象不过了。不让代码插入，复杂的定制又处理不了。如果能处理，复杂程度真不如用代码三下五除二的搞定。业务平台本来是为了快速开发，最后却阻碍了快速开发，这种业务平台是错误的思路。今天听说Google App Engine和Salesforce整合了，我想这就是潮流。这种架构实现模式可以给现在仍在传统业务开发平台道路上奋斗的朋友以启发。

现在，全球都在讲Open API。Google几乎开放了它所有应用的接口，而且Google App Engine也很容易让你定制的代码能够很好的部署和运行在平台上。这才是一个良好的业务架构平台。如果大家搭建SAAS平台，还在照抄过去的平台架构思路，还是会走到现在传统平台的死胡同里的。现在的传统业务平台已经如困兽一般，但是我还是看到许多人前赴后继，声称百变金刚，信心百倍的宣传，浪费了人才和时光。我想起了微软亚洲工程院院长张宏江说的一段话表达的意思，原话我记不住了，但大致意思是这样的：这个应用在美国10多年前就已经很成熟了，你现在才想到并认为是自己的创新是错误的，你的视野应该去看看国际上一流人在做什么。

有了符合潮流的设计，就要组织开发实现落地。我们国内的开发组织发展时间非常的短。直到现在还有95%的软件公司都是单人单枪在讨生活，根本无法谈到开发组织。但是互联网的出现、资本的介入，让我们看到了开发组织。

97年我还在羡慕求伯君、鲍岳桥这些第一代中国程序员。2001年，我才研读设计模式、软件工程、UML、RUP。但是很快，外包公司、网络游戏公司、网站门户公司，给了我们实践的一课。他们都是大规模团队组织开发。他们的开发模式都值的我们学习。

尤其门户网站公司，他们快速应用开发、测试、发布、大规模计算环境部署，都是我们做传统管理软件人需要学习的。

还有，现在的开源协作组织，我看国内也有很多成功的案例，如HuiHoo组织。他们在项目需求管理、BUG管理、进度管理、版本管理、代码合并、代码更新、团队沟通，都有很好的模式经验，都值得我们学习。（关于轻型开发组织模式，我在我的一篇博文详细谈过：软件开发组织的web2.0模式）

在上个月参加CSDN的软件技术英雄大会的时候，有人问我怎么没听过你们公司。我说传统管理软件厂商，一般都是闷声发大财，一般不和业界交流。甚至用友，要在工作时间断网。

其实，这是蛮尴尬的。我们作为传统管理软件厂商，我们真的成了老古董。未来的计算模式、未来的盈利模式、未来的业务架构、未来的开发模式，我们都不去学习先进，我们还在用我们使用了10多年的传统开发组织模式来进行着，我们的盈利模式也是传统的，我们的业务功能模型也是陈旧的。我们总是在5000万以下徘徊，如果想上市，想突破1个亿、10个亿、100亿的销售，我们必须和时代接轨。我们现在真的很象一个老古董，慢慢被潮流扫到一边，成为历史的叹息。

就是这个原因，所以我在网上消失很久后又重返业界，希望能和符合潮流的技术模式、盈利模式、业务架构、开发模式一起工作一起探讨。