從發展模式看SaaS服務的昨天、今天和明天
本文從SaaS的發展上分析了各種模式，并從一個全新的角度觀察了Slack火爆的原因。
預先配置(on-premise) 時代
在預先配置時代，市場上只有 Microsoft，SAP 等幾家通過提供了市場、銷售、客戶支持等一整套軟件壟斷了各個細分領域。對用戶來說還沒有 “我自己的軟件棧” 這種說法。
SaaS 先驅
隨著互聯網深入人心，很多企業看到了 SaaS 模式的意義。***批 SaaS 廠商獲得了廣泛認同，他們并沒有提供全套的解決方案，而是提供了細分領域的解決方案，專注在該細分領域中滿足用戶的各種需求。
用戶開始有了更多的選擇。
***次 SaaS 大爆發
隨著 SaaS 的廣泛應用，不同規模的企業都可以選擇 SaaS，而SaaS 的技術門檻也逐漸降低，許多初創企業開始進入一些細分領域 SaaS 市場。和大型 SaaS 廠商相比，這些初創企業往往更專注于細分領域中的一小塊，而且用戶體驗和界面也更加友好。
這個時候，用戶才真正不得不思考他們的 SaaS 軟件棧，以及他們應該怎么選擇。
現在?
在幾個主要的細分領域，都擠滿了各種 SaaS 廠商。從大型廠商到中小型的，甚至微型 SaaS(即大型 SaaS 的一個插件或者擴展)，人們有成百上千種解決方案可以選擇。
SaaS 軟件棧中的軟件越來越多，隨之帶來的問題也多了起來，軟件的相互連接，數據遷移，棧的管理，工作流集成，自定義用戶體驗等問題逐漸困擾著用戶。
為了解決這些問題，一些新的混合產品和方法自然而然誕生了。
細分領域的 SaaS 中心(SaaS Hubs)：它們專注于單個細分領域，把該細分領域的 SaaS 軟件棧中的不同軟件進行集中管理。
例子：市場營銷領域的 Lytics，客戶支持領域的 elev.io
分拆的 API：他們將 API 分層進行打包，而不是將整個產品進行打包，這樣用戶可以根據需求自定義自己的用戶體驗。
這對于構建內部產品，或者補充現有 SaaS 軟件棧來說，是一個有趣的方法。我曾寫過一篇關于這類產品的更詳細的文章。
例子：市場營銷領域的 Clearbits 和 客戶支持領域的 supportive.io
客戶數據層(Customer Data layer)：segment.io 是一個收集、管理、發送用戶分析數據的單一中心(hub)。它是這樣運作的，你將所有客戶數據通過 javascript 標簽 發送給 segment.io，segment.io 將數據發送回你在用的某個 SaaS 軟件。通過將你的客戶數據集中到單一的層，你可以無縫地遷移數據，連接不同細分領域的兩個軟件。
命令和提醒層(Command & notification layer)：當在你的 SaaS 軟件棧中有許多應用時，你需要一個層來保證不用每次登陸就能接收到不同應用的提醒。 Slack 就是這樣一個提醒層，你可以將你的 SaaS 軟件接入 Slack 來直接獲得提醒。Slack 還允許你直接在界面中執行命令，比如執行“/hangout” 命令會啟動 Google hangout 程序。
附加說明
整合層(Transversal layer)
是的，我相信 segment.com 是對 SaaS 生態系統來說一個重要的產品(Slack 已經很大了)
是的，我相信更多附加的層還會出現，哪些層呢?很難預測，我也不知道( 探索，單點登錄，安全?)
給 SaaS 廠商的結論
對 SaaS 廠商來說提供對相關的整合層之間的集成很重要(比如 segment 或者 Slack 集成)
你可能不喜歡客戶可以點兩下就從你的產品遷移到你的競爭對手產品中，但是客戶并不這么想。如果你不允許客戶這樣做，客戶可能一開始就不會選擇你。
SaaS 中心 (SaaS Hubs)
這些中心可以僅僅是界面中心(elev.io 就是這樣子) 或者提供了深度集成功能，就像 Lytics。中心的概念非常寬泛，人們可能同時用到很多個中心。
這些中心同樣連接到整合層。Lytics 和 elev.io 同樣有 segment.com 集成。
隨著 SaaS 軟件棧繼續增長，還會有很多問題浮現出來，也會有越來越多的混合產品來解決這些問題，所以我估計未來幾年一切都會發生變化。
原文鏈接：SaaS服務的前世今生以及未來
