許多人對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炒作了一段時間黯然下去——那已經是1999-2000年的事情了。那時候互聯網上網的企業也少，在網上找客戶的企業也少，在網上做廣告的企業也少。電子商務、支付寶、IM軟件，都還起步。網速也慢，開發工具也簡單，沒有像如今的AJAX這么自然的UI感受。

    聽說過ASP這段歷史的讀者，是最容易產生SAAS和ASP之間到底存在哪些差異的疑問。認為SAAS就是換湯不換藥，起了個新名詞繼續忽悠人，就如同Web2.0、AJAX之類，都是新名詞舊技術，把雜七雜八糾集一起，揉揉然后給你包裝一個新概念繼續賣錢。甚至國內有些廠商為了爭SAAS這個頭名狀，說我們1999年就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潮流的大背景下，我們傳統管理軟件廠商應該如何擁抱未來，跟隨時代大潮而騰飛（許多人無法成功，就是沒有踏準時代的脈搏，而不是運氣不好這么簡單。想想1980年代的萬元戶和特區下海，1990年代的關系經濟，2000年后的知識經濟）。

    所以我對SAAS在管理軟件行當的研究分為這幾個方面：

    1. SAAS的在管理軟件應用的切入點、目標客戶群、盈利模式、市場容量、發展周期、收費模式、周期每階段預期收入、競爭環境。

    2. SAAS的運行技術基礎。SAAS不僅僅只是片面理解的一套可以存儲多個客戶單位數據的B/S軟件。如果你要應對上億次的訪問，幾億用戶的并發和數據存儲，你的運行基礎設施一定是一個可信平臺。

    3.SAAS的業務架構平臺。我們既要提供一套可以不用代碼就能簡單定制的業務平臺，也要提供WebService API接口，以使代碼能夠切入進行復雜定制。而且能夠部署、運行，而且是安全的沙箱，而不能部署的是惡意代碼。而且每個定制是隔離的，不能互相影響的。

    4.SAAS的開發模式。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%的軟件公司都是單人單槍在討生活，根本無法談到開發組織。但是互聯網的出現、資本的介入，讓我們看到了開發組織。

    1997年，我還在羨慕求伯君、鮑岳橋這些第一代中國程序員。2001年，我才研讀設計模式、軟件工程、UML、RUP。但是很快，外包公司、網絡游戲公司、網站門戶公司，給了我們實踐的一課。他們都是大規模團隊組織開發，他們的開發模式都值的我們學習。

    尤其門戶網站公司，他們快速應用開發、測試、發布、大規模計算環境部署，都是我們做傳統管理軟件人需要學習的。還有，現在的開源協作組織，我看國內也有很多成功的案例，如HuiHoo組織。他們在項目需求管理、BUG管理、進度管理、版本管理、代碼合并、代碼更新、團隊溝通，都有很好的模式經驗，都值得我們學習。

    在參加CSDN的軟件技術英雄大會的時候，有人問我怎么沒聽過你們公司。我說傳統管理軟件廠商，一般都是悶聲發大財，一般不和業界交流。甚至在用友公司，要在工作時間斷網。

    其實，這是蠻尷尬的。我們作為傳統管理軟件廠商，我們真的成了老古董。未來的計算模式、未來的盈利模式、未來的業務架構、未來的開發模式，我們都不去學習先進，我們還在用我們使用了10多年的傳統開發組織模式來進行著，我們的盈利模式也是傳統的，我們的業務功能模型也是陳舊的。我們總是在5000萬以下徘徊，如果想上市，想突破1個億、10個億、100億的銷售，我們必須和時代接軌。我們現在真的很像一個老古董，慢慢被潮流掃到一邊，成為歷史的嘆息。

    就是這個原因，所以我在網上消失很久后又重返業界，希望能和符合潮流的技術模式、盈利模式、業務架構、開發模式一起工作一起探討。

    后記

    其實我蠻擔心中國未來5年后的管理軟件行當的。要么仍然像現在一樣完善功能升級或者用其他的開發語言重寫一版然后去賣，去一家家安裝服務器，去維護支持，茍延殘喘。要么真正轉型成為軟件即服務，做好自己核心一塊，成為互聯網的一部分，為全球其他需要該軟件服務的客戶或ISV提供軟件服務。要么寄居在現在這幾大云計算環境提供商上，如IBM的藍云、Google的云計算環境，利用他們的云平臺開發。非常類似過去寄居在Delphi上的那些控件商。

    要么....。不知道了，可能死了。